Messages in this thread | | | Date | Fri, 25 Aug 2000 02:22:34 -0700 (PDT) | From | Clayton Weaver <> | Subject | Re: [OT] Re: abstract file (support multi-part) |
| |
[] > If so, then you open bar using the native API call ZwOpenFile. - The [] This ^^^^^^^^^^ is the basic problem with any kind of multi-part storage object support in kernel space. Because different multi-part storage objects implemented by different native filesystems have different allowed and/or required components besides the actual data, we need different open/read/write/ link/unlink/rename/fcntl/stat/close/et_al calls for each different set of components (where more than one part of a multi-part file gets operated on with a single system call).
For every new native multi-part object filesystem or even new version, the specification of these multi-part objects is subject to change, requiring for each such change a new set of functions that knows the nature of the components of a particular kind of multi-part storage object. Allowing such proliferation of required support functions at the whim of vendors of other operating systems and the otherwise unenlightened is bogus design at it's worst, imho.
When VFS only supports a single model, where everything that looks like a file is a single data channel file, and any association between files beyond what unix already provides is a user space application or support library concern, then the proliferation of multi-part storage object implementations at the demand of applications can take whatever shape it wants, because it is not a kernel problem. It's merely up to the application to be sure it has support coded someplace for it's "meta storage objects" that cluster multiple discrete unix filesystem objects together as parts of a user-defined multi-part abstract storage object.
With single data channel files, Linux only needs one set of system calls in VFS. With multi-part files, we need one set of system calls in VFS for every different kind of multi-part storage object model.
We can virtualize the "multi-" instead of single partness of it, but that doesn't solve the "which parts are we using with this particular filesystem" issues. The backend only does part of the job, VFS still needs to know what to ask for. When we more-or-less need a different VFS for each multi-part storage object filesystem type, we effectively throw away what made VFS advantageous in the first place. We would be coding a backend storage object model dependency into VFS.
That's my final opinion on this: it could be done, by writing a different VFS for each storage object model that doesn't fit the unix model, but it seems silly for the kernel to have to deal with all of these different storage object models itself. Since when do applications tell an operating system what kind of filesystem model it must have?
Maybe they lose a little bit of backing store locality, big deal, it's a good trade for only having one much simpler VFS in the kernel instead of a dozen of them, each with it's own quirks and bugs (imho, of course; feel free to write an alt-VFS for HFS or NFSv3 or NTFS or whatever if you have the time for it).
Regards,
Clayton Weaver <mailto:cgweav@eskimo.com> (Seattle)
"Everybody's ignorant, just in different subjects." Will Rogers
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |