Re: GFS2 and DLM

[Ingo Molnar]

* Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:

> On Fri, Jun 23, 2006 at 05:29:34PM +0100, Steven Whitehouse wrote:
> > Hi,
> > 
> > On Fri, 2006-06-23 at 16:00 +0100, Christoph Hellwig wrote:
> > > On Tue, Jun 20, 2006 at 01:17:13PM +0100, Steven Whitehouse wrote:
> > > > Hi,
> > > > 
> > > > Linus, Andrew suggested to me to send this pull request to you directly.
> > > > Please consider merging the GFS2 filesystem and DLM from (they are both
> > > > in the same tree for ease of testing):
> > > 
> > > A new normal filesystem (aka everything but procfs) shouldn't implement
> > > ->readlink but use generic_readlink instead.
> > > 
> > 
> > The comment above generic_readlink has this to say:
> > 
> > /*
> >  * A helper for ->readlink().  This should be used *ONLY* for symlinks that
> >  * have ->follow_link() touching nd only in nd_set_link().  Using (or not
> >  * using) it for any given inode is up to filesystem.
> >  */
> > 
> > which appears, at least, to contradict what you are saying. I'll put 
> > it on my list to look at again, but a straight substitution of 
> > generic_readlink() does not work, so I'd prefer to leave it as it is 
> > for the moment,
> 
> The above is the common and preffered case.  The only intree 
> filesystem not doing it is procfs.

i think you might be missing that GFS does cross-node locking in 
readlink too. (OCFS2 does not do it because it apparently does not care 
about cross-node atime correctness here it seems.) So GFS simply cannot 
use generic_readlink()!

i'm all for enhancing vfs_readlink()/generic_readlink() so that local 
locking can be extended if needed, but otherwise this does not seem to 
be a merge showstopper to me. GFS simply implements something that 
no-one implemented until now. (i dont know how XFS's non-GPL binary-only 
clustering module does it, but i'd not be surprised if it defined its 
own readlink implementation too.)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/