Re: [2.6.24 patch] let EXT4DEV_FS depend on BROKEN

2008-01-02 Thread Trond Myklebust
On Wed, 2008-01-02 at 23:16 +0200, Adrian Bunk wrote: > On Wed, Jan 02, 2008 at 07:26:29PM +0100, Diego Calleja wrote: > > El Wed, 2 Jan 2008 03:32:18 +0200, Adrian Bunk <[EMAIL PROTECTED]> escribió: > > > > > It might make sense to offer ext4 in -mm and even in early -rc kernels, > > > but I've

Re: [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)

2007-08-07 Thread Trond Myklebust
On Tue, 2007-08-07 at 17:15 -0700, Andrew Morton wrote: > Is there any way in which we can prevent these problems? Say The problem here is that we occasionally DO need to add new flags, and yes, they MAY be security related. The whole reason why we're now having to change the semantics of setatt

Re: [fuse-devel] [PATCH 01/25] VFS: move attr_kill logic from notify_change into helper function

2007-08-06 Thread Trond Myklebust
On Mon, 2007-08-06 at 21:37 +0200, Miklos Szeredi wrote: > > > Your patch is changing the API in a very unsafe way, since there will > > > be no error or warning on an unconverted fs. And that could lead to > > > security holes. > > > > > > If we would rename the setattr method to setattr_new as

Re: [fuse-devel] [PATCH 01/25] VFS: move attr_kill logic from notify_change into helper function

2007-08-06 Thread Trond Myklebust
On Mon, 2007-08-06 at 20:28 +0200, Miklos Szeredi wrote: > Your patch is changing the API in a very unsafe way, since there will > be no error or warning on an unconverted fs. And that could lead to > security holes. > > If we would rename the setattr method to setattr_new as well as > changing

Re: [EXT4 set 4][PATCH 4/5] i_version:ext4 inode version update

2007-07-11 Thread Trond Myklebust
On Wed, 2007-07-11 at 09:47 +0100, Christoph Hellwig wrote: > On Sun, Jul 01, 2007 at 03:37:45AM -0400, Mingming Cao wrote: > > This patch is on top of i_version_update_vfs. > > The i_version field of the inode is set on inode creation and incremented > > when > > the inode is being modified. > >

Re: [EXT4 set 4][PATCH 1/5] i_version:64 bit inode version

2007-07-10 Thread Trond Myklebust
On Wed, 2007-07-11 at 13:21 +1000, Neil Brown wrote: > On Tuesday July 10, [EMAIL PROTECTED] wrote: > > > > Yes, thanks. It doesn't actually tell us why we want to implement > > this attribute and it doesn't tell us what the implications of failing > > to do so are, but I guess we can take that o

Re: [EXT4 set 4][PATCH 1/5] i_version:64 bit inode version

2007-07-03 Thread Trond Myklebust
On Mon, 2007-07-02 at 10:58 -0400, Mingming Cao wrote: > Trond or Bruce, can you please review these patch series and ack if you > agrees? Thanks. > > As to performance concerns that raise before the inode version counter > (at least for ext4) is done inside ext4_mark_inode_dirty), so there is > n

Re: [patch 0/2] i_version update

2007-05-31 Thread Trond Myklebust
On Thu, 2007-05-31 at 10:01 +1000, Neil Brown wrote: > This will provide a change number that normally changes only when the > file changes and doesn't require any extra storage on disk. > The change number will change inappropriately only when the inode has > fallen out of cache and is being relo

Re: [patch 2/2] i_version update - ext4 part

2007-05-30 Thread Trond Myklebust
On Wed, 2007-05-30 at 16:48 -0700, Mingming Cao wrote: > On Tue, 2007-05-29 at 16:58 -0600, Andreas Dilger wrote: > > I don't know what the NFS requirements for the version are. There may > > also be some complaints from others if the i_version is 64 bits because > > this contributes to generic in

Re: [RFC] [patch 0/3] i_version update for ext4

2007-01-24 Thread Trond Myklebust
On Wed, 2007-01-24 at 09:40 -0800, Mingming Cao wrote: > Cordenner jean noel wrote: > > Andreas Dilger a écrit : > > > >> On Jan 23, 2007 18:23 +0100, Cordenner jean noel wrote: > >> > >>> I've updated what was previously the change attribute patch for ext4 > >>> initially posted by Alexandre Rat

Re: rfc: [patch] change attribute for ext3

2006-12-14 Thread Trond Myklebust
On Wed, 2006-12-13 at 20:52 -0500, J. Bruce Fields wrote: > > What kind of requirements does NFSv4 place on the version? Monotonic is > > probably a good bet. > > The only requirement is that it be unique (assuming a file is never > modified 2^64 times). Clients can't compare them except for equ

Re: ext3 merge status

2006-09-27 Thread Trond Myklebust
On Tue, 2006-09-26 at 13:41 -0700, Andrew Morton wrote: > I don't know if we'll be merging the fs-cache code this time around - it's > largely in Trond and Christoph's hands. I'm OK with it going in. Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the

Re: rfc: [patch] change attribute for ext3

2006-09-14 Thread Trond Myklebust
On Thu, 2006-09-14 at 09:46 -0400, Peter Staubach wrote: > Wouldn't the generation count work better than ctime to differentiate > between > instances of files using the same inode number? That way, there wouldn't be > a clock resolution issue. No. This is about distinguishing updates to the met

Re: rfc: [patch] change attribute for ext3

2006-09-13 Thread Trond Myklebust
On Wed, 2006-09-13 at 20:30 +0200, Alexandre Ratchov wrote: > On Wed, Sep 13, 2006 at 02:11:11PM -0400, Trond Myklebust wrote: > > On Wed, 2006-09-13 at 18:42 +0200, Alexandre Ratchov wrote: > > > hello, > > > > > > here is a small patch that adds the &q

Re: rfc: [patch] change attribute for ext3

2006-09-13 Thread Trond Myklebust
On Wed, 2006-09-13 at 18:42 +0200, Alexandre Ratchov wrote: > hello, > > here is a small patch that adds the "change attribute" for ext3 > file-systems; > > the change attribute is a simple counter that is reset to zero on > inode creation and that is incremented every time the inode data is > m