atomic write & T10 standards

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

 



On 07/03/2013 11:00 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 10:56 -0400, Ric Wheeler wrote:
On 07/03/2013 10:38 AM, Chris Mason wrote:
Quoting Ric Wheeler (2013-07-03 10:34:04)
As I was out walking Skeeter this morning, I was thinking a bit about the new
T10 atomic write proposal that Chris spoke about some time back.

Specifically, I think that we would see a value only if the atomic write was
also durable - if not, we need to always issue a SYNCHRONIZE_CACHE command which
would mean it really is not effectively more useful than a normal write?

Did I understand the proposal correctly?  If I did, should we poke the usual T10
posse to nudge them (David Black, Fred Knight, etc?)...
I don't think the atomic writes should be a special case here.  We've
already got the cache flush and fua machinery and should just apply it
on top of the atomic constructs...

-chris

I should have sent this to the linux-scsi list I suppose, but wanted clarity
before embarrassing myself :)
Yes, it is a better to have a wider audience

Adding in linux-scsi....


If we have to use fua/flush after an atomic write, what makes it atomic?  Why
not just use a normal write?

It does not seem to add anything that write + flush/fua does?
It adds the all or nothing that we can use to commit journal entries
without having to worry about atomicity.  The guarantee is that
everything makes it or nothing does.

I still don't see the difference in write + SYNC_CACHE versus atomic write + SYNC_CACHE.

If the write is atomic and not durable, it is not really usable as a hard promise until after we flush it somehow.

In theory, if we got ordered tags working to ensure transaction vs data
ordering, this would mean we wouldn't have to flush at all because the
disk image would always be journal consistent ... a bit like the old
soft update scheme.

James


Why not have the atomic write actually imply that it is atomic and durable for just that command?

Ric

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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux