Date: Fri, 24 Oct 1997 17:15:02 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: michaelh@cet.co.jp (Michael Hancock) Cc: tlambert@primenet.com, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG Subject: Re: zipfs filesystem anyone ? Message-ID: <199710241715.KAA13208@usr08.primenet.com> In-Reply-To: <Pine.SV4.3.95.971024111008.17710C-100000@parkplace.cet.co.jp> from "Michael Hancock" at Oct 24, 97 11:25:59 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > You could do one, but you will have to externalize a hell of a lot > > of code, and provide proxy allocation and freeing mechanisms for > > every place that is non-reflexive. > > Wouldn't you have to externalize a lot of stuff anyway? We'd need some > extra syscalls along the lines of John Heidemann's ook* (Out Of Kernel) > stuff. You can make a fs specific call that serves as a general interface > to marshall fs related operations in and out of the kernel. No. The "ook" stuff is kind of a kludge having to do with the fact that the VM interface consumed by local file systems is not encapsulated by a VFS layer: in other words, for local file systems, the top and bottom of the FS are different. This is actualy broken implementation more than anything else, IMO. Really, you need a clone top/bottom device, best case, or a paired top/bottom device (ala pty's, which should be clone themselves) at worst. The only real pain is extending the number of VOP's, should you need to... and that's going to bite you no matter how you approach it because the BSD VFS init code is broken (it counts the number of VOP's in the statically linked UFS instead of using the struct vnops descriptor count, with placeholders for some "reasonable number" of new VOPs). > Then you can make a semantic-free user layer. Well, you know my opinion: they should all be semantic free, and all implied state should be registered in a graph with all but the final Warshall pass complete, and the graph should be used to implement soft update semantics for all FS layers, everywhere. 8-). > It seems that a lot of NFS related work these days have to do with > adding state. Yes. This has me alarmed. It seems to me that NFS is becoming one kludge on top of another, with things getting tweaked until they appear to work, with no one really looking at the big picture. That's the same objection I have to stuffing VM glue into supposedly null function bodies in nullfs, unionfs, etc. 8-(. > I was looking at this a few months ago after John H. released his layering > code. ??? John H's code has been available since before the 4.4-Lite release; I was playing with it under 4.3 (FreeBSD 1.05)... > It also seems that Poul and John Dyson have started cleaning up some fs > related interface and memory issues, but I haven't had time to examine all > the details. I think John has been addressing real issues, and to be fair, I haven't unpacked my machines yet, so I haven't been able to look at Poul's stuff (the reduction of VOP calls seems sound in principle, but I can't comment for real until I actually look at it). I think the excitement over nullfs "working" has overshadowed a number of important design considerations; but you know that from my posts, so I don't need to repeat them. I don't know how much of the recent twiddling has been "make it work at any cost" as oppossed to real cleanup. I really think the VFS needs to be "dekludgeified" before more new stuff is added. If you make something parallel to something crooked, you end up with two crooked things. There needs to be someone in there with a "T-square" before an entire crooked house is built. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710241715.KAA13208>