> Alexander Viro writes:
> >
> >
> > On Wed, 30 Jun 1999, Hans Reiser wrote:
> >
> > > My point though is that the file system semantics have been static for
> > > 20 years. It is time for them to change. When they change NFS will
> > Could we avoid metaphysics?
> > > break, at least it will if the changes are substantive. For this
> > > reason, to argue that NFS cannot be broken is to argue that there should
> > > be no semantic innovation for file systems. That make the argument
> > > invalid in my eyes.
> >
> > > NFS must be broken.
> >
> > Not in the kernel that runs here. Period. You break it, your patch is not
> > applied on my boxen. If anything like that will make its way into the main
> > tree (e.g. you'll tie Linus and give him one-way trip) be bloody sure that
> > code split *will* follow. If reiserfs will require kernel changes that
> > break NFS (I hope it will not) - though luck for reiserfs. Deal with it.
> > NFS sucks in many, many ways. So does SMTP. So does DNS. So does IP.
> > Unfortunately dropping any of them is not an option, unless you are
> > willing to move into the brave new world where you can't interoperate with
> > anything except the stuff written by vendor foo. We've been there. SNA
> > lost. And one personal note - you've made everything to ensure that I'll
> > treat any code from you as potentially maliciuos. Double audit and all
> > such. Somehow I suspect that I'm not alone in that. After the things that
> > were said I simply don't trust you.
>
> Oh dear, we've gotten into flames, and I am rather to blame in this.
>
> Don't open NFS directories as files, use Stephen's proposed solution.
>
> Stephen wrote:
>
> > Now, what we _could_ do is to provide a user-space library stub for
> > other NFS clients which translates O_DIRECTORY() opens to a file into an
> > open of something like "filename/.%%pseudodir%%", and have an NFS server
> > which detects that pseudoname and munges it into an O_DIRECTORY open on
> > the server side.
> >
> > See? Suddenly we are able to pass these calls over NFS while still
> > doing something useful with local filesystem semantics. That's the sort
> > of thing I would like to see us talking about. Simply dismissing all of
> > existing practice as irrelevant and broken just doesn't get us any
> > further, I'm afraid.
>
> I like it. Now the only thing I would like more is to stop exchanging
> flames and write some code. Of course, if I could resist getting in the
> last word, I might be able to do that....:-)
>
I'm writting code as quickly as I can and I had settled on a similar approach.
The code, hopefully only a day or two away now, should allow any FS to be
used as a 'fork/stream/albod/whatever' as long as we can store away 2 bits
of extra information. I'm afraid to use st_mode bits, but that is probably the
final location for portability.
But eventually there are some issues with maintaining compatibility with
current applications. Given the 'redirection' approach, when an application
opens file 'foo', it expects to get the data in foo. No problem. Now along comes
the admin and wants to set things up diffently and 'cp's foo to another
location. Copy sounds good ... but 'cp' is an application that has opened foo
and hence gets redirected to the 'data stream' - no real copy.
Best I've been able to come up with is similar to Hans' filters. Here I decided
that the 'self' symbol - that is slash-dot - may be used in any path name to
refer to the entire object. So 'cp foo/. bar' works when foo is a flat file or
when a
forked file. Second problem is that the data comming out of foo/. is a directory
heirarchy. Tar may be the way to go for representation, but I haven't looked
to see if it has a way to mark meta-file type. For now I'll probably just dump
out some ascii form and allow a 'portable filter' to be specified for each file.
Since this is test code, I've keep kernel changes (so far) to just some field
definitions in headers and one line of code. But it keeps getting harder
to do kernel-like actions in user space. Fighting with glibc-2.1 (beta?) takes
time. Whoever said 'just use preload' hasn't seen my system!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/