Re: Journaling pointless with today's hard disks?

[Andreas Dilger <adilger@turbolabs.com>]

On Nov 26, 2001  15:35 -0500, Rob Landley wrote:
> The drive should block when it's fed sectors living on more than 2 tracks.  
> Don't bother having the drive implement an elevator algorithm: the OS already 
> has one.  Just don't cache sectors living on more than 2 tracks at a time: 
> treat it as a "cache full" situation and BLOCK.

The other thing that concerns a journaling fs is write ordering.  If you
can _guarantee_ that an entire track (or whatever) can be written to disk
in _all_ cases, then it is OK to reorder write requests within that track
AS LONG AS YOU DON'T REORDER WRITES WHERE YOU SKIP BLOCKS THAT ARE NOT
GUARANTEED TO COMPLETE.

Generally, in Linux, ext3 will wait on all of the journal transaction
blocks to be written before it writes a commit record, which is its way
of guaranteeing that everything before the commit is valid.  If you start
write cacheing the transaction blocks, return, and then write the commit
record to disk before the other transaction blocks are written, this is
SEVERELY BROKEN.  If it was guaranteed that the commit record would hit
the platters at the same time as the other journal transaction blocks,
that would be the minimum acceptable behaviour.

Obviously a working TCQ or write barrier would also allow you to optimize
all writes before the commit block is written, but that should be an
_enhancement_ above the basic write operations, only available if you
start using this feature.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/