Date: Thu, 12 Jun 1997 10:27:52 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: winter@jurai.net (Matthew N. Dodd) Cc: csubl@csv.warwick.ac.uk, freebsd-hackers@FreeBSD.ORG Subject: Re: user-mode nfs daemon Message-ID: <199706121727.KAA09204@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.95q.970612083351.12954H-100000@sasami.jurai.net> from "Matthew N. Dodd" at Jun 12, 97 08:41:48 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Most compressed file formats have a table of contents. Your filesystem > layer wouldn't have to do anything with the file until the data would be > accessed. I'm sure that the code could be fast-pathed to avoid > performance problems for normal non arhive-file operations. > > Conceptually it sounds fairly straightforard if my understanding of what > an be done at the VFS layer. As I've got no kernel hacking skills I > really can't do more than say how nifty such things would be. > > *grin* > > I do know that I'll never use a command line archiver tool on my Win95 box > again. Abstracting compressed files as directories is a completly logical > and intuitive thing to do from a user point of view. Users don't care > about such things, they only want access to the data. > > Terry, since you seem to have an opinion on such things, what is your > view? For the sake of discussion... John Heidemann sent me a copy of a compressing FS stacking layer that two of his students wrote, with the provision that I not redistribute the code (I actually got much of the VFS code into the 4.3BSD Net/2 release before the CSRG 4.4BSD-Lite release, on these same terms). My view is that the Heidemann code was kludged into the 4.4-Lite code base in response to the USL/UCB conesnt agreement (which removed 6 file components affecting 5 major kernel subsystems, in the vain hope that it would prevent 4.4BSD-Lite based systems from competing against SVR4). In other words, it was a last-minute nose-thumbing at USL, rather than a well considered and architected coding effort. Naturally there has been hell to pay for this largely political act, ever since. Welcome to the club. My view is that this kludging has never been corrected, but that the powers-that-be are so enamored with the idea that the code from CSRG is somehow blessed because of its origins, that they are afraid to change it, without establishing a prior full conceptual understanding of the existing code in a core team member. The problem with this provision is that the existing code is conceptually flawed in a number of ways, which means that it's impossible to get a consistent overview (quite logically, because it's not consistent). As a sidebar, I was able to get the compression stacking layer to work without problems, after I corrected the interfaces on my own machine, with the help of direct email exchanges with John Heidemann (my corrections are a lot more radical than the minor layering patches I have posted, which are minimalist ways of achieving some of the same ends). The 4.4BSD-Lite2 release was an additional pain in the ass, in that it compounded the kludges in a number of places. Unfortunately, I could not contribute 4.4BSD-Lite fixes back to CSRG directly for inclusion in Lite2, as I did not have the requisite SVR4 license to get a working 4.4BSD-Heavy machine running, and FreeBSD relative patches were not very practical for them. So my guess is that if you made your VFS layer in your FreeBSD kernel look like John Heidemann's thesis obviously intended it to look, you'd probably be successful; but don't expect to be able to do this within the existing framework of FreeBSD. Regards, 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?199706121727.KAA09204>