Re: 2.6.6-mm5

[Matthias Andree <matthias.andree@gmx.de>]

On Sat, 22 May 2004, Andrew Morton wrote:

> - Implementation of request barriers for IDE and SCSI.  The idea here is
>   that a filesystem can tag an IO request as a barrier and the disk will not
>   reorder writes across the barrier.  It provides additional integrity
>   guarantees for the journalling filesystems.  The feature is enabled for
>   reiserfs and ext3.
> 
>   On reiserfs do `mount /dev/hda /wherever -o barrier=flush' or
>   `barrier=none'.
> 
>   On ext3 do `mount ... -o barrier=1' or `barrier=0'.
> 
>   ext3 also supports `mount -o remount,barrier=N'.  I didn't check whether
>   reiserfs supports switching at remount time and nobody tells me these
>   things.

Ah, progress!

What SCSI low level drivers will translate barriers to tags?

Of particular personal egoistic interest for me are, in decreasing order
of importance: sym53c8xx_2 megaraid aic7xxx tmscsim


How will the system handle the Queue Algorithm Modifier? Appearently,
allowing command reordering is a matter of the device, not of the
individual partitions, so the barrier stuff is a property that would
belong into the block driver rather than into partition handling. Upon
mounting, the file system would have to query if the underlying block
device requires write barriers or will execute commands in order
(control mode page, queue algorithm modifier). If I need to operate the
target with "restricted reordering" algorithm for any other partition
that is mounted without barriers or with a barriers-unaware file system,
we won't gain much by all this barrier stuff for the target mustn't
reorder operations anyways.

The potential benefits of Queue Algorithm Modifier "Unrestricted
Reordering allowed" however requires that all file systems inform the
target about their write ordering requirements. IMHO, the barrier
"switch" does not belong into the file systems -- I don't see OTOH how
using these on a device that performs writes in order will matter, so
using these always will probably not harm (it's still useful for testing
probably).

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95