Poor floppy performance in kernel 2.4.10

Poor floppy performance in kernel 2.4.10

Post by Alain Knaf » Mon, 29 Oct 2001 04:30:11

>> And "mapping" itself seems to point to i_data of the device's inode
>> structure (not the device entry's inode, but the device's itself).

>> Which means that if the inode is put (all references to the block
>> device closed), and later the same major/minor is reopened, it may

>Stop here.  bdev->bd_inode is destroyed only when bdev is destroyed.
>If we make block_device long-living (i.e. they stay around until all
>pages are evicted from cache _or_ device gets unregistered) ->bd_inode
>will follow.

That would be ok with me. Long live block_device! ;-)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Poor floppy performance in kernel 2.4.10

Post by Alain Knaf » Tue, 30 Oct 2001 14:40:08

>> Appended to this mail is the "long live the struct block_device"
>> patch. It includes the stuff covered in the last patch as well. The
>> issue of stopping transfers in progress is not yet addressed.

>Errr .. haven't read the patches.

Please do ;-) Or maybe, rather browse the initial mails of this
thread, which discuss the problem being fixed here, and the reason why
that problem was there in the first place.

Quote:>But are you doing something so that
>the semantics of the action taken after a media check fails can
>be overridden? The current invalidate_inodes is too strong for me,
>since I am proxying a remote device, and I don't want to kill
>_all_ the local file descriptors when the remote media disappears.
>I need to at least continue to send down local ioctls!

>No, no suggestions of an extra control device, please. Simplicity.

Don't worry. This patch does not do anything like that. No extra
control device is introduced. No killing of local file descriptors in
case a remote media disappears. Please read the context of the post
(Subject: Poor floppy performance). The discussion has unfortunately
been stretched over more than a week, with long silences in between
(I've been busy with other stuff in between, and thus had to come back
later, sorry), so the initial messages might be somewhat hard to find,
but they're there in the archives:
http://www.uwsg.iu.edu/hypermail/linux/kernel/, in the week of Oct

All the patch it does is address the following problem: if all file
descriptors pointing to a block device are closed, the cache is
closed, no matter whether the media has been changed or not... This
clearly leads to suboptimal performance, especially with slow devices
such as the floppy.

The reason for this behaviour was threefold
 1. Apparently, for some media, check_media_change is not reliable, so
the VFS people decided not to trust it (don't ask...). Hence the
kill_bdev call, invoked after the last close, to throw away all
 2. Kill_bdev is also needed to stop any read-aheads in progress after
last close (makes sense: if there is no open filedescriptors, those
read-aheads can no longer safely be served, because the device driver
may assume that nobody needs the device any longer and thus
de-allocate critical resources: IRQ, DMA, bounce buffers...)
 3. Cached pages are identified by the pair (inode,index), and the
block device backend inode changes after the last close.

All the can_trust_media_change part does is skip the kill_bdev if the
device driver says "yes, you _can_ trust the answer of
check_media_change" (fix problem #1).

Problem number 2 is not yet addressed, Alex Viro is working on a patch
(probably by having a variant of invalidate_bdev that just stops
transfers in progress, loudly warn about dirty pages, but without
killing clean cached pages)

Number 3 is fixed by making struct block_device "long
lived". Formerly, it only existed as long as there were active open
descriptors using it; now it exists as long as there are frontend
inodes referencing it.

Another related issue (not yet addressed by my patch), is what happens
after rmmod. Right now, with the patch, the cache is so long-lived
that it hangs around even after an rmmod...

Personnally, I don't really like the "check_media_change not trusted"
semantics either... we better handle flaky media change indicators
internally in the driver, especially since the driver may have its own
limited internal caching (DMA bounce buffers, track buffers, ...). But
apparently other people have strong feelings about the issue, having
been burned badly by devices which occasionnally miss a media
change..., and who have chosen to ginore check_media_change
altogether, rather than fix those device drivers...

Quote:>> +
>>  static struct block_device_operations floppy_fops = {
>>        open:                   floppy_open,
>>        release:                floppy_release,
>>        ioctl:                  fd_ioctl,
>>        check_media_change:     check_floppy_change,
>>        revalidate:             floppy_revalidate,
>> +      can_trust_media_change: floppy_can_trust_media_change
>>  };

>and I'd like to have "invalidate" as a method too.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


1. Poor floppy performance in kernel 2.4.10

On Thu, Oct 18, 2001 at 05:42:44PM +0200, you [Kamil Iskra] claimed:

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

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Netscape 4.5 problem downloading binaries from site using apache 1.3

3. VM: 2.4.10 vs. 2.4.10-ac2 and qsort()

4. : can not reboot with NE2000 -- wrong initialize ?

5. Swapping in 2.4.10.SuSE-3 (2.4.10aa1 + some patches).

6. NBS to system clock update

7. PPTP/GRE masquerading in kernel 2.4.18 changed (since kernel 2.4.10)?

8. How to share read-only to one client and read-write to all others?

9. softirq performance fixes, cleanups, 2.4.10.

10. kernel 2.4.10 masquerading (debian)

11. Compiling kernel 2.4.10

12. 2.4.10-pre11: alsaplayer skiping during kernel build (-pre10 did not)

13. kernel 2.4.10 comes up as 2.4.5 ???