mtdblock caching and syncing

[Jamie Lokier]

Miles Nordin wrote:
> >>>>> "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.

Yes, that is all true.

> 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.

There's a lot of discussion about fsync and barriers recently, so yes.
Same for SSDs.

> And finally, devices which use FLASH tend to get their cords yanked
> more often so IMHO it matters.

That is the single most important reason!

-- Jamie