lkml.org 
[lkml]   [2000]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 12:38    [W:2.770 / U:0.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site