On Mon, Jul 21, 2003 at 04:34:43PM -0800, Ethan Benson wrote:
> My question on #3 is whether we want this behavior in XFS? my current
> patch does NOT implement it. My opinion is that the only flag this
> really makes sense for is sync, since setting the sync flag on a
inherited sync is very useful. iirc it was introduced because some
mail servers assume everything is a BSD with UFS and rename is always
synchronous, otherwise they have potential crash recovery issues.
You just set sync on the spool and everything ends up safely synchronous.
AFAIK the XFS transaction manager does not guarantee the the transaction
is committed before the rename returns, so it would be needed even on XFS.
However XFS seems to be default to osyncisdsync, and for the mail server use
case you need O_SYNC, not O_DSYNC.
Maybe it would be useful to define a new bit for both cases?
> of this. I am definitely not convinced its a sensible idea for
> append-only since it ends up allowing non-privileged users to create
> append-only files, which is not normally permitted. Also
> automatically setting the append-only flag on a newly created file
Agreed. I assume ext2/reiser do also not inherit it, right?
> I have a (somewhat hideous) test program to check as many things as i
> could think of to ensure immutable/append-only are properly enforced,
> the only thing lacking in it is tests of all the XFS ioctls, perhaps
> someone familiar with xfs ioctls could add these, currently the
> libhandle open/write tests are done. You can find this test program
> at http://penguinppc.org/~eb/t_immutable.c
I would suggest to submit that program to LTP. I'm sure they would
appreciate more test cases and it would help making all the linux
file systems behave similar in this area.
-Andi
|