[lkml]   [2009]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC Aufs2 #5 28/29] export lookup functions

    Christoph Hellwig:
    > Strong NACK to all these exports, no one has any buesiness looking at
    > these.

    Will you tell me why?
    If you have ever discussed exporting lookup_hash(), then please tell me
    its URL or something.

    lookup_hash is necessary for aufs since,

    (from the mail "Subject: [RFC Aufs2 #5 01/29] aufs documents")
    +Lookup in a Branch
    +Since aufs has a character of sub-VFS (see Introduction), it operates
    +lookup for branches as VFS does. It may be a heavy work. Generally
    +speaking struct nameidata is a bigger structure and includes many
    +information. But almost all lookup operation in aufs is the simplest
    +case, ie. lookup only an entry directly connected to its parent. Digging
    +down the directory hierarchy is unnecessary.
    +VFS has a function lookup_one_len() for that use, but it is not usable
    +for a branch filesystem which requires struct nameidata. So aufs
    +implements a simple lookup wrapper function. When a branch filesystem
    +allows NULL as nameidata, it calls lookup_one_len(). Otherwise it builds
    +a simplest nameidata and calls lookup_hash().
    +Here aufs applies "a principle in NFSD", ie. if the filesystem supports
    +NFS-export, then it has to support NULL as a nameidata parameter for
    +->create(), ->lookup() and ->d_revalidate(). So the lookup wrapper in
    +aufs tests if ->s_export_op in the branch is NULL or not.

    J. R. Okajima

     \ /
      Last update: 2009-04-10 18:51    [W:0.022 / U:4.720 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site