On Fri, Aug 09, 2002 at 02:22:49PM +0200, Andreas Gruenbacher wrote:
I read this as `Why are you not returning the permissions nfsd should see in
struct, which the inode->getattr IOP fills?'. Please correct me if this is
not what you wanted to say.
I meant adding an acl field to struct kstat that is supposed to be filled
by ->getattr.
The usual callers of getattr should see the unmasked permissions; it's only
nfsd that needs this special treatment, and only on filesystems that have
ACLs enabled. The getattr IOP is used by others as well.
So why the is a new IOP better in that respect?
If you had adding an extra field to struct kstat in mind, this just seems too
intrusive to me for solving the nfsd problem. The problem will go away in the
future when all NFSv3 clients are using the ACCESS RPC, anyway. It's just a
hack right now.
So you want to add two inode operations for a hack that is only needed to
support old NFS clients? Do you have any profiling data that shows major
overhead when going through the xattr layer?
On Friday 09 August 2002 14:32, Christoph Hellwig wrote:
On Fri, Aug 09, 2002 at 02:22:49PM +0200, Andreas Gruenbacher wrote:
quoted
I read this as `Why are you not returning the permissions nfsd should see
in struct, which the inode->getattr IOP fills?'. Please correct me if
this is not what you wanted to say.
I meant adding an acl field to struct kstat that is supposed to be filled
by ->getattr.
I see. That's problematic on most filesystems, because retrieving the ACL from
disk is pretty expensive, and often is not needed. For things like stat() it
is not needed, for example.
quoted
The usual callers of getattr should see the unmasked permissions; it's
only nfsd that needs this special treatment, and only on filesystems that
have ACLs enabled. The getattr IOP is used by others as well.
So why is the a new IOP better in that respect?
Only nfsd needs to pay the runtime cost.
quoted
If you had adding an extra field to struct kstat in mind, this just seems
too intrusive to me for solving the nfsd problem. The problem will go
away in the future when all NFSv3 clients are using the ACCESS RPC,
anyway. It's just a hack right now.
So you want to add two inode operations for a hack that is only needed to
support old NFS clients?
It will be needed for NFSv2 and NFSv3, until all NFSv3 clients support the
ACCESS RPC properly. The ACCESS RPC patch for the client side in the current
kernel still has some performance issues. The hack won't go away anytime
soon, but a lot fewer people will be affected by the underlying problem in a
year or so.
I also think the inode operations are a good thing to keep independent of the
nfsd issue.
Do you have any profiling data that shows major overhead when going through
the xattr layer?
No, this would be tricky to measure. The interface requires copying around
ACLs, and endianness conversions on big endian machines; it's simply
inappropriate for that task.
--Andreas.
------------------------------------------------------------------
Andreas Gruenbacher SuSE Linux AG
mailto:agruen@suse.de Deutschherrnstr. 15-19
http://www.suse.de/ D-90429 Nuernberg, Germany