Block layer discard requests [LWN.net]

Block layer discard requests

Posted Aug 14, 2008 11:43 UTC (Thu) by seanyoung (subscriber, #28711)
Parent article: Block layer discard requests

A couple of years ago I did something similar (but not as complete).

http://lwn.net/Articles/162776/

I found that having forget/discard as barrier requests can be very bad for performance. At any
point when a forget/discard is issued, all data is written to flash which would not have been
necessary without the barrier; the dirty blocks could have remained in memory.

All of this can be solved through proper merging though. The rules would become fairly
difficult, I think.

The other issue was that only the in-tree FTL layers could make use of them. CompactFlash ATA
does have an "erase sectors" option but this is not really what you want (pre-erase sectors
such that the next write will succeed without waiting for a flash erase).

to post comments

Block layer discard requests

Posted Aug 18, 2008 22:57 UTC (Mon) by jlokier (guest, #52227) [Link] (2 responses)

They're not _filesystem_ barrier requests: a DISCARD doesn't cause dirty blocks/pages to be
flushed.  Rather, it's a barrier in the request queue, so any write submitted to the request
queue afterwards will not pass the DISCARD.

Block layer discard requests

Posted Aug 19, 2008 9:39 UTC (Tue) by seanyoung (subscriber, #28711) [Link] (1 responses)

You say writes submitted after the discard will not be merged before the barrier. 

So say we have 100 of files being deleted on a FAT filesystem. After each file deletion a
discard (i.e. BARRIER) is submitted. 

Now in stead of writing the FAT table changes once at the end, the FAT table changes must be
written 100 times.

Block layer discard requests

Posted Aug 19, 2008 16:47 UTC (Tue) by jlokier (guest, #52227) [Link]

Writes were never merged by the device request queue anyway.

Merging the FAT table writes happens at a higher level: in the FAT filesystem.  That's not
affected by these changes.  The FAT filesystem will submit a series of DISCARD requests for
each deleted file, interspersed with a smaller number of FAT write requests which merge
multiple changes.

... and Flash ERASE commands

Posted Aug 24, 2008 4:48 UTC (Sun) by HalfMoon (guest, #3211) [Link]

CompactFlash ATA does have an "erase sectors" option but this is not really what you want (pre-erase sectors such that the next write will succeed without waiting for a flash erase).

I've seen a fair number of "raw flash" chips with that same semantic: writes to erased segments are faster. By a factor of about five, so it's well worth leveraging. In some cases that implies using different write procedures though ... so just having a "trim" hook isn't enough, the lowlevel code would need to know whether the area being written was already erased/trimmed.