xfs
[Top] [All Lists]

Re: [PATCH] Implement immutable/append-only flags in XFS #3

To: linux-xfs@xxxxxxxxxxx
Subject: Re: [PATCH] Implement immutable/append-only flags in XFS #3
From: Ethan Benson <erbenson@xxxxxxxxxx>
Date: Tue, 29 Jul 2003 23:16:31 -0800
In-reply-to: <20030729154740.GD7435@xxxxxxxxxxxxx>
Mail-copies-to: nobody
Mail-followup-to: linux-xfs@xxxxxxxxxxx
References: <20030722003443.GA13188@xxxxxxxxxxxxxxx> <20030729154740.GD7435@xxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.3.28i
On Tue, Jul 29, 2003 at 05:47:40PM +0200, Andi Kleen wrote:
> 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.

yes.  sync on a directory otherwise doesn't do anything AFAICT.

note that 2.6 introduces a new flag specifically for making a
directory syncronous, i don't know the details of how it works, or
what it does, or what XFS would need to do to support it.

i am not sure exactly where to put code to inherit any of these flags however...

> 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?

ill let the XFS guys comment on this.

> > 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?

ext2 inherits ALL the bits.  they just copy the entire flag field to
the new inode, unless its a symlink.  if you create a device node in
an append-only directory you will need to use debugfs to get rid of
it.  (i pointed this out on linux-kernel, but nobody cares).

this is even more foolish since some ext2 flags are used to report
error conditions with the compression patches.

this wasn't immediatly noticable prior to 2.4.21 since ext2 failed to
notify the VFS about the flags (except sync), so you wouldn't see
things like append-only enforced until the filesystem was remounted,
or the inode re-read from disk.

> > 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.

sure.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgpvEdmQfyFMs.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>