Re: atomic write & T10 standards

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2013-07-03 at 11:04 -0400, Ric Wheeler wrote:
> 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?

I don't understand why you think you need guaranteed durability for
every journal transaction?  That's what causes us performance problems
because we have to pause on every transaction commit.

We require durability for explicit flushes, obviously, but we could
achieve far better performance if we could just let the filesystem
updates stream to the disk and rely on atomic writes making sure the
journal entries were all correct.  The reason we require durability for
journal entries today is to ensure caching effects don't cause the
journal to lie or be corrupt.

James