Subject: RE: UFS ACLs and Extended attributes
To: Jason Thorpe <thorpej@shagadelic.org>
From: Gordon Waidhofer <gww@traakan.com>
List: tech-kern
Date: 09/06/2005 17:41:36
> > Explain the linkage of NFSv4 to "both". An attempt to vindicate
> > Euclid from every flaw proved non-Euclidian geometry. Prove me
> > wrong -- it just might convince you.
>
> A file system that fundamentally only supports subfiles could tell
> the VFS layer "I don't support extattrs" by any number of
> mechanisms. The VFS layer could then simulate extattrs using
> specially-named subfiles. This is not all that different from how
> extattrs are currently "supported" on UFS1 file systems (I will admit
> that the code that does this is a work-in-progress that needs to be
> greatly improved upon -- but it's a start!)
And if there was no argument to win, would you *REALLY* think
that was a good idea?
To be fair, I'm quite pleased today. That there is the notion
of "we should have both" is a kind of concession. It practically
admits that the BSD/Linux model of "named thingy" is inadequate.
If it was adequate, nobody would suggest both.
NetBSD has no significant investment or deployment of what
is (effectively) admittedly inadequate. So why do it? That's
not a rehtorical question. Really. Why? It just muddies the
field.
Here's "adequate":
subf_fd = openat ("afile", "sub", X_ATTR);
for (i = 0; i < 1000000; i++) {
write (subf_fd, "x", 1);
fsync (subf_fd);
if (i%1234 == 0) {
lseek (subf_fd, 5678, SEEK_CUR);
}
}
This will work on Solaris native, Solaris->Solaris NFSv4,
Solaris->NetApp NFSv4, and you can throw NT into that mix.
That's the ones I know about. There are undoubtedly others
by now.
They are using the NFSv4 OPENATTR("afile") operation
followed by LOOKUP("sub"). So, how would BSD APIs translate
to the NFSv4 operations? How would the NFSv4 operations translate
to the VOPs? How would a BSD server satisfy the loop above?
Both is not necessary. Just have a way to add bona-fide
attributes (like ACLs) internal to the underlying file
systems. Use getxattr() API (ala Linux) to manipulate the
new bona-fide attributes. No need to expose the storage
mechanism for attributes to the API.
And we haven't even talked about tar(1) yet.
I'm simply suggesting that subfiles should be the
objective. APIs to BSD/Linux style EAs should be
a non-objective. Nobody will ever miss them.
The poor bugger who has to reconcile this stuff with NFSv4
would be quite glad they are omitted.
Regards,
-gww