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

Phillip Susi wrote:

Hrm... I may have misunderstood the perspective you were talking from. Yes, when the bio is completed it must be on the media, but the filesystem should issue both requests, and then really not care when they complete. That is to say, the filesystem should not wait for block A to finish before issuing block B; it should issue both, and use barriers to make sure they hit the disk in the correct order.

Actually now that I think about it, that wasn't correct. The request CAN be completed before the data has hit the medium. The barrier just constrains the ordering of the writes, but they can still sit in the disk write back cache for some time.

Stefan Bader wrote:

That would be the exactly how I understand Documentation/block/barrier.txt:

"In other words, I/O barrier requests have the following two properties.
1. Request ordering
...
2. Forced flushing to physical medium"

"So, I/O barriers need to guarantee that requests actually get written

to non-volatile medium in order."

I think you misinterpret this, and it probably could be worded a bit better. The barrier request is about constraining the order. The forced flushing is one means to implement that constraint. The other alternative mentioned there is to use ordered tags. The key part there is "requests actually get written to non-volatile medium _in order_", not "before the request completes", which would be synchronous IO.

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

---

• Follow-Ups:
  • Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
    • From: Jens Axboe <[email protected]>

• References:
  • [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
    • From: Neil Brown <[email protected]>
  • Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
    • From: Neil Brown <[email protected]>
  • Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
    • From: David Chinner <[email protected]>
  • Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
    • From: Phillip Susi <[email protected]>
  • Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
    • From: David Chinner <[email protected]>
  • Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
    • From: Phillip Susi <[email protected]>

• Prev by Date: Re: [PATCH] drivers/block/ub.c: use list_for_each_entry()
• Next by Date: Re: [patch 1/9] Conditional Calls - Architecture Independent Code
• Previous by thread: Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
• Next by thread: Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]