On Thu, Jan 25, 2001 at 11:56:35AM -0700, Thunder from the hill wrote:
> Arkadiusz Miskiewicz wrote:
> >
> > On/Dnia Wed, Jan 24, 2001 at 12:23:03PM -0600, Brad Felmey wrote/napisa?(a)
> > > > I/O support = 0 (default 16-bit)
> > >
> > > hdparm -c1 /dev/hda, or are you running in 16-bit mode on purpose?
> > no purpose. Setting this can only speed up all operations a bit but it doesn't
> > change nothing in vfat <-> vfat copying. It still slows down while copying.
> I noticed the kernel to increase cache and let the buffers break down during long file copies, it seems like this is the wrong way if only copying one large file. This also happens on SMB connections. I don't know if this info is useful.
Hmmm, imho this is a more general problem. Of course kernel does not know
if this is a single copy or data should be cached since it will be used
frequently in the near future. I don't know kernel internals very well
but I think cache is block cache. On higher layer (fs) it would be possible
to check out that we simply read blocks of file linear (which means
something like you mentioned especially on big files). I met similar
problems when I copy a harddisk to another (same type), with simple dd'ing
/dev/hda to /dev/hdb. Even with 192Mbs of RAM, the system goes down to
a very uninteractive state :( This copy task may be implemented on raw devices
to avoid caching nowdays. Please correct me, because these are only feelings
or what :)
-- --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]--[ lgb@supervisor.hu ]-- U have 8 bit comp or chip of them and it's unused or to be sold? Call me! -------[ +36 30 2270823 ]------> LGB <-----[ Linux/UNIX/8bit 4ever ]----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 31 2001 - 21:00:22 EST