Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
Consider USB sticks, commonly accessed via SCSI emulation.
They don't need a scheduler policy, yet from the PoV of Linux they look like normal disks.
FLASH drives do need a scheduler policy
Posted Sep 29, 2004 18:12 UTC (Wed) by BrucePerens (guest, #2510)
Posted Sep 29, 2004 18:17 UTC (Wed) by corbet (editor, #1)
Posted Sep 29, 2004 18:40 UTC (Wed) by smurf (subscriber, #17840)
The downside is that this is excessively unsafe WRT data integrity.
If that's a problem, use a better filesystem than FAT (MP3 sticks, digital cameras, ad nauseam).
Posted Sep 30, 2004 7:45 UTC (Thu) by axboe (subscriber, #904)
Posted Oct 1, 2004 0:45 UTC (Fri) by dmaxwell (guest, #14010)
I have to use FAT32 if I want to employ my stick as a universal device.
Posted Oct 1, 2004 6:29 UTC (Fri) by axboe (subscriber, #904)
And FAT32 is fine to use on a flash stick.
Posted Oct 1, 2004 16:51 UTC (Fri) by BrucePerens (guest, #2510)
Yes, that's true. However, it can be fixed, if the filesystem communicates either a write barrier (write this block before any blocks I send down after it) or ordering information (write block X before block Y, order of block Z doesn't matter). Once it is so easy to work on I/O scheduling, the need for this will become so evident that there is no question that it will be done.
Posted Oct 3, 2004 9:48 UTC (Sun) by axboe (subscriber, #904)
We already have write barriers, and it doesn't solve the entire problem. It will make any given fs more flash friendly indeed, but it's still quite a bit away from a fs specifically designed to minimize drive wear.
Your last sentence doesn't make sense.
Posted Oct 3, 2004 12:06 UTC (Sun) by BrucePerens (guest, #2510)
OK. I think one of the BSDs goes a bit further than write barriers in communicating time information. But I see your point that this can not go all of the way in reducing FLASH wear.
Posted Oct 1, 2004 1:50 UTC (Fri) by BrucePerens (guest, #2510)
I understand that to the I/O scheduler, a block is just a block. But I feel that the filesystem should be a higher layer than whatever understands the time constraints of the media. What is necessary is for the filesystem to communicate to the lower levels when order is important. If the I/O scheduler knows that there are 100 blocks that should not go out to the stick without changing the superblock and the directory at the same time, it can handle I/O buffering for USB sticks sensibly. This is why now that we are getting versatile I/O scheduling, some sort of tagged-queueing-like scheme will now become important in the filesystem layer.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds