Re: [PATCH] 3/5: Device-mapper: snapshots

[Daniel Phillips]

On Saturday 03 July 2004 02:04, Jeff Garzik wrote:
> Daniel Phillips wrote:
> > It is designed to be crash-safe:
> >
> >   - Each snapshot exception is logged to disk by overwriting the last
> > sector of a grow-only list of snapshot exceptions.
> >
> >   - Write completion is not handed back up the chain until:
> >
> >       - the data to be overwritten has been copied to a new exception
> >       - the new exception has been logged to the snapshot store as above
> >
> > As far as I can see, the concept is leak-proof, except for being
> > sensitive to random garbage in the last few sector writes.  I suspect
> > that doesn't happen on modern disk drives.  If it does, I hope somebody
> > will shout.
> >
> > I am not sure what you mean about barriers, perhaps you were thinking of
> > synchronous waiting.  This snapshot driver does wait for completions, but
> > it pipelines the waits so throughput is not affected much (snapshot
> > overhead is dominated by copyouts).
>
> Barriers as discussed on lkml ensure your data is committed to stable
> storage, not simply completed requests.  In SCSI this means ordered
> tags, FUA, or cache flushing.  Ditto ATA (cache flushing, mostly).

I meant, I didn't know why he thought barriers might apply in this case, but 
now that you mention it, yes we risk the same bugs with certain hardware as, 
say, a journal commit does.  We need to do something about that at some 
point.  (I see that the barrier patch hasn't made it to mainline yet, and 
actually, that's good because it needs to be looked at critically.)

Anyway (reading Andi's mind) it seems the snapshot durability strategy just 
wasn't obvious on a light reading.  It certainly wasn't obvious to me without 
clarification from Joe Thornber, from whose fertile imagination this clever 
hack apparently sprang.  Yes, these details need to be documented.

Regards,

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