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]
