lkml.org 
[lkml]   [2007]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
    Date
    } -----Original Message-----
    } From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
    } owner@vger.kernel.org] On Behalf Of Jens Axboe
    } Sent: Saturday, June 02, 2007 10:35 AM
    } To: Tejun Heo
    } Cc: David Chinner; david@lang.hm; Phillip Susi; Neil Brown; linux-
    } fsdevel@vger.kernel.org; linux-kernel@vger.kernel.org; dm-
    } devel@redhat.com; linux-raid@vger.kernel.org; Stefan Bader; Andreas Dilger
    } Subject: Re: [RFD] BIO_RW_BARRIER - what it means for devices,
    } filesystems, and dm/md.
    }
    } On Sat, Jun 02 2007, Tejun Heo wrote:
    } > Hello,
    } >
    } > Jens Axboe wrote:
    } > >> Would that be very different from issuing barrier and not waiting for
    } > >> its completion? For ATA and SCSI, we'll have to flush write back
    } cache
    } > >> anyway, so I don't see how we can get performance advantage by
    } > >> implementing separate WRITE_ORDERED. I think zero-length barrier
    } > >> (haven't looked at the code yet, still recovering from jet lag :-)
    } can
    } > >> serve as genuine barrier without the extra write tho.
    } > >
    } > > As always, it depends :-)
    } > >
    } > > If you are doing pure flush barriers, then there's no difference.
    } Unless
    } > > you only guarantee ordering wrt previously submitted requests, in
    } which
    } > > case you can eliminate the post flush.
    } > >
    } > > If you are doing ordered tags, then just setting the ordered bit is
    } > > enough. That is different from the barrier in that we don't need a
    } flush
    } > > of FUA bit set.
    } >
    } > Hmmm... I'm feeling dense. Zero-length barrier also requires only one
    } > flush to separate requests before and after it (haven't looked at the
    } > code yet, will soon). Can you enlighten me?
    }
    } Yeah, that's what the zero-length barrier implementation I posted does.
    } Not sure if you have a question beyond that, if so fire away :-)
    }
    } --
    } Jens Axboe

    I must admit I have only read some of the barrier related posts, so this
    issue may have been covered. If so, sorry.

    What I have read seems to be related to a single disk. What if a logical
    disk is used (md, LVM, ...)? If a barrier is issued to a logical disk and
    that driver issues barriers to all related devices (logical or physical),
    all the devices MUST honor the barrier together. If 1 device crosses the
    barrier before another reaches the barrier, corruption should be assumed.
    It seems to me each block device that represents more than 2 other devices
    must do a flush at a barrier so that all devices will cross the barrier at
    the same time.

    Guy

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-06-03 01:01    [W:8.318 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site