What I mean is that the barrier semantic is implicit even with no ZIL at all. In ZFS, if event A happens before event B, and you lose power, then what you'll see on disk is either nothing, A, or both A and B. Never just B. It is impossible for us not to have at least barrier semantics.
Jeff On Apr 2, 2010, at Friday, April 2 9:47 AM, Neil Perrin wrote: > Jeff, > > We also ignore fsyncs when the zil is disabled, so there is no barrier. > That was why I thought you were proposing a new option. > I think disabled reflects the zil_disable semantics accurately. > > Neil. > > On 04/01/10 23:56, Jeff Bonwick wrote: >> Yeah, I'm just suggesting "barrier" as a name rather than "disable". >> It's a more accurate description of the semantic ZFS provides >> when zil_commit() is a no-op. >> >> Jeff >> >> On Apr 1, 2010, at 10:03 PM, Neil Perrin wrote: >> >>> On 04/01/10 19:31, Jeff Bonwick wrote: >>>> Yes. It should be inherited. >>> >>> Ok, that seems to be the consensus and I'm also fine with it. >>> >>> >>>> >>>> For the property values, I'd prefer: >>>> >>>> "standard" - we honor the standard (posix) semantics, without saying >>>> posix. >>> >>> - Seems a reasonable name. >>> >>>> >>>> "always" - make every system call synchronous. >>>> >>>> "barrier" - treat fsync() only as a write barrier, which ensures that all >>>> previous >>>> writes/updates will be on stable storage before any subsequent updates. >>> >>> Are there cases where an admin might want an applications fsyncs to be >>> honored but >>> O_DSYNC/O_SYNC/O_RSYNC to be ignored? >>> >>> Are you suggesting this new barrier option replaces disable or is in >>> addition to it? >>> I think we still need to provide a disable option that is equivalent to >>> zil_disable >>> and ignores all sync operation including fsync. >>> >>>> >>>> Jeff >>>> >>>> On Apr 1, 2010, at 10:33 AM, Darren J Moffat wrote: >>>> >>>>> On 01/04/2010 18:28, Neil Perrin wrote: >>>>>> We've flip-flopped on whether it should be inherited. It's currently >>>>>> coded as inherited, and I know Robert believes it should stay that way. >>>>>> Anyway, it was generally felt by the zfs group that sync=disabled >>>>>> was sufficiently dangerous to require explicit setting on each dataset. >>>>>> I would be ok with it being inherited. >>>>> >>>>> I agree that it is dangerous but I'm not sure that the change in >>>>> semantics means it shouldn't be inherited. On the other hand I can't >>>>> think of any other equivalently "dangerous" (to applications view of the >>>>> world) per dataset property. >>>>> >>>>> -- >>>>> Darren J Moffat >>>> >>> >> > _______________________________________________ opensolaris-arc mailing list [email protected]
