[lkml]   [2001]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Poor floppy performance in kernel 2.4.10
On Thu, Oct 18, 2001 at 05:42:44PM +0200, you [Kamil Iskra] claimed:
> On Thu, 18 Oct 2001, Andreas Dilger wrote:
> > > The behaviour is as if no caching was done,
> > > there is a slowdown by a factor of two.
> > I think this is a result of the "blockdev in pagecache" change added in
> > 2.4.10. One of the byproducts of this change is that if a block device
> > is closed (no other openers) then all of the pages from this device are
> > dropped from the cache. In the case of a floppy drive, this is very
> > important, as you don't want to be cacheing data from one floppy after
> > you have inserted a new floppy.
> >
> > In contrast, if you mounted the floppy instead of using mtools, it would
> > probably have good performance for small files as well.
> That's very interesting. It would explain why it takes 2 seconds _every_
> time you invoke "mdir", whereas before the invocations after the first one
> were more or less instantenous. And indeed, as you say, mounting a floppy
> does result in a good performance.
> However, it does not explain why the first invocation is two times slower
> (it's 1 sec with kernel 2.4.9 and 2 secs with 2.4.10, the effect is even
> more visible for mcopy of a small file, like 30KB). I strace'd mdir and
> it's opening /dev/fd0 just once, at the beginning, and closing it at the
> end.

That's propably beacause it syncs the writes on close().

Perhaps you could try the trick Linus suggested in another thread, namely:

sleep 1000 < /dev/fd0 &

<do whatever>

kill %1

That keeps one (dummy) reference to the floppy device open until you're done
using it.

-- v --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:08    [W:0.073 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site