Re: bug in nfs in 2.6.18-rc5?
- From: Trond Myklebust <trond.myklebust@xxxxxxxxxx>
- Date: Thu, 31 Aug 2006 12:03:50 -0400
On Thu, 2006-08-31 at 10:54 -0400, Shaya Potter wrote:
__lookup_hash() ends up calling the underlying fs's lookup op, i.e.
nfs_lookup()
nfs_lookup() calls nfs_reval_fsid(nd->mnt, dir, &fhandle, &fattr);
see the bug? :)
This doesn't seem like a unionfs bug, as one should be able to call
lookup_one_len() on an NFS fs.
Did someone start handing out these promises when I wasn't looking?
AFAICS, lookup_one_len() should only be used by the filesystem itself,
or by services like nfsd that have intimate knowledge of the
filesystem's inner workings.
The reason why NFS would like to insist on that nameidata is that we
need to be able to create mountpoints on the fly when we cross from one
filesystem on the server to another. Otherwise, we cannot offer the type
of guarantees that POSIX applications expect, such as the ability to
provide unique permanent inode numbers.
If we're to provide the ability for unionfs to use lookup_one_len() on
NFS, then we will have to error out whenever we hit a case where we
should be creating a new mountpoint. Is that acceptable?
Cheers,
Trond
-
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/
- Follow-Ups:
- Re: bug in nfs in 2.6.18-rc5?
- From: Christoph Hellwig
- Re: bug in nfs in 2.6.18-rc5?
- From: Shaya Potter
- Re: bug in nfs in 2.6.18-rc5?
- References:
- bug in nfs in 2.6.18-rc5?
- From: Shaya Potter
- bug in nfs in 2.6.18-rc5?
- Prev by Date: Re: [PATCH 7/8] Implement smp_processor_id() with the PDA.
- Next by Date: Re: cpu_init is called during resume
- Previous by thread: Re: bug in nfs in 2.6.18-rc5?
- Next by thread: Re: bug in nfs in 2.6.18-rc5?
- Index(es):
Relevant Pages
|