Danny, one more for your collection :) Should be the really last problem known to me.
It fixes ridiculously slow read from IDE devices in some cases. The reason was as usual very simple and is not supermount bug. File read-ahead code never explicitly unplugs device queue after submitting requests. Supermount checks for media change on every operation (except read/write) and query_disk_change blocked until queue was unplugged, i.e. tq_disk was run. This happened either on next non-readahead IO request (not neccessarily for the same device, it explains why supermount appeared to work normally during high disk IO activity) or during next kupdated run that by default happens every 5 seconds. This gives you those 4-5 second delays for every file. The worst case was read-ahead of many files immediately followed by close. In this case every close blocked for several seconds. And this is exactly what happens when you run rpm - it scans all package headers and waits several seconds between each file :) The fix is to ensure that device IO is enabled before we are going to sleep waiting for request. It should not break anything as far as I can tell, SCSI layer does the same (so SCSI devices should not suffer from this problem at all). Arguably this should happen in file read-ahead code and comments there even suggest that it was intended but I do not feel myself confident enough to touch the very heart of IO subsystem. cheers -andrey
2.4.20-2mdk.slow-supermount-on-IDE.patch
Description: Binary data
