Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2007/5/28, Alasdair G Kergon <agk@xxxxxxxxxx>:
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
> 1/ A BIO_RW_BARRIER request should never fail with -EOPNOTSUP.

The device-mapper position has always been that we require

>  a zero-length BIO_RW_BARRIER

(i.e. containing no data to read or write - or emulated, possibly
device-specific)

before we can provide full barrier support.
  (Consider multiple active paths - each must see barrier.)


Couldn't the same be ac hived by doing a sort of suspend, issuing the
barrier request, calling flush to all mapped devices and then wait for
in-flight I/O to go to zero? This certainly has the aspect of
performance degradation (but that seem to be a generic problem with
barriers not being specific enough).

Until every device supports barriers -EOPNOTSUP support is required.
  (Consider reconfiguration of stacks of devices - barrier support is a
   dynamic block device property that can switch between available and
   unavailable at any time.)

Is only an issue if not doing barrier handling in dm. In that case the
support in the devices is helpful but not required.

For something else: Alasdair, I am not a hundred percent sure about
that but I think that just passing the barrier flag on to mapped
devices might in some (maybe they are rare) cases cause a layer above
to think all data is on-disk while this isn't necessarily true (see my
previous post). What do you think?

Stefan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux