mtdblock caching and syncing

[Miles Nordin]

>>>>> "dg" == Doug Graham <dgraham at nortel.com> writes:

    dg> I would assume that [hard drives] don't leave dirty data in
    dg> their cache for an unbounded period of time.

ZFS always, ext3 mounted with barrier=1 (or by default in SLES only)
and only when not using LVM2, and HFS+ on Mac OS X when using their
bullshit fcntl F_FULLSYNC API, all at least claim to issue SYNC CACHE
commands to the drives and wait for the drive to write to platter.
It's also possible for people who care to turn off the write cache in
their drives.  For drives connected to RAID controllers that have a
battery-backed write cache, I've hard of database-oriented sysadmins
who actually do this as a best-practice not a freak experiment---in
general, at least for SCSI drives, DBA's are likely to be aware of and
control their drives' write cache settings.  There is some FUD about
drives existing that ignore the SYNC CACHE command (but not SCSI
drives), but so far the people I've seen spreading this FUD refuse to
name the specific drives, so they are likely to be really old drives,
or even just made-up excuses from developers of buggy filesystems and
block layers.

Anyway, the point is, mtdblock is behind the curve here, yes.  and for
hard drive-backed filesystems the situation will probably get even
better soon.  And finally, devices which use FLASH tend to get their
cords yanked more often so IMHO it matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20090423/c184a9b9/attachment.bin>