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]
