Bill Todd <billtodd at (no spam) metrocast.net> writes:
That disks write data out of order when write-back caching is enabled
does not seem at all surprising, since that's one of the main potential
benefits of having write-back caching enabled.

Yes. But some people seem to imagine that this is a very small effect
that can be ignored without ill effects on the consistency of the
on-disk data of a file system; this attitude is exemplified by having
barrier=1 disabled by default in the ext3 file system in Linux.

The test demonstrates that the reordering can happen over several
seconds.

the program ran
significantly slower (about 6MB/s transfer rate) than what the drive
is capable of (>70MB/s)

Bill Todd <billtodd at (no spam) metrocast.net> writes:
Anton Ertl wrote:
Bill Todd <billtodd at (no spam) metrocast.net> writes:
That disks write data out of order when write-back caching is enabled
does not seem at all surprising, since that's one of the main potential
benefits of having write-back caching enabled.
Yes. But some people seem to imagine that this is a very small effect
that can be ignored without ill effects on the consistency of the
on-disk data of a file system; this attitude is exemplified by having
barrier=1 disabled by default in the ext3 file system in Linux.

The test demonstrates that the reordering can happen over several
seconds.
That indeed seems to be quite a long time - but then it wasn't so long
ago that Unix systems would by default allow writes to languish for as
much as 30 seconds (with no particular guarantees about ordering when
they actually got destaged) so I can't really fault the disk vendors for
this: as has always been the case, if you want ordering guarantees, you
need to take explicit steps to ensure them.

Yes, nowadays you can have them without turning off write caching
completely, so it's entirely reasonable.

There are file systems like ext3 with data=ordered or data=journal or
BSD FFS with soft updates that do give guarantees about ordering. But
in order to implement these guarantees they must take the explicit
steps, and ext3 does not do that by default.

the program ran
significantly slower (about 6MB/s transfer rate) than what the drive
is capable of (>70MB/s)
Interesting: it implies that the disk was destaging a few blocks every
rev rather than waiting for a track to fill up (what are track sizes on
those 400 GB disks - 0.5 MB or so?)

At 70MB/s and 7200rpm=120/s the track size is at least
70(MB/s)/120(/s)=0.583MB.

the head for the next platter or moving it to the next cylinder also
costs a little time on each revolution.

My guess (inspired by you) is that it destaged 3064KB at a time. The
slow transfer rate is probably a result of doing synchronous writes to
the disk buffers; the write would only report completion when the data
has arrived in the disk's buffers, and only then the next write would
start and weave its way through the various subsystems.

write the blocks roughly in the order of age, and block 0 is rarely
the oldest one it sees because it gets overwritten by younger
instances all the time.

Have you tested disks to see whether they indeed destaged single large
transfers out of order (as many claim to when the write is at least a
large percentage of a track in size)?

No. How would you test that?

writes. Journaling file systems need guarantees about the order of
journal writes as well as journal writes relative to the writes the
journal entries describe.

writes. Journaling file systems need guarantees about the order of
journal writes as well as journal writes relative to the writes the
journal entries describe.

Usually, the update is first written to the journal (and must reach the =
hard disk media) and only then is reflected in the actual metadata.

In this case, it is enough to only use FUA (or some similar thing =
emulated on ATA, for instance, drive's cache flush after each such =
write) on journal writes.