lkml.org 
[lkml]   [2007]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 05/42] Unionfs: documentation for any known issues
    Date
    Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu>
    ---
    Documentation/filesystems/unionfs/issues.txt | 24 ++++++++++++++++++++++++
    1 files changed, 24 insertions(+), 0 deletions(-)
    create mode 100644 Documentation/filesystems/unionfs/issues.txt

    diff --git a/Documentation/filesystems/unionfs/issues.txt b/Documentation/filesystems/unionfs/issues.txt
    new file mode 100644
    index 0000000..9db1d70
    --- /dev/null
    +++ b/Documentation/filesystems/unionfs/issues.txt
    @@ -0,0 +1,24 @@
    +KNOWN Unionfs 2.1 ISSUES:
    +=========================
    +
    +1. Unionfs should not use lookup_one_len() on the underlying f/s as it
    + confuses NFSv4. Currently, unionfs_lookup() passes lookup intents to the
    + lower file-system, this eliminates part of the problem. The remaining
    + calls to lookup_one_len may need to be changed to pass an intent. We are
    + currently introducing VFS changes to fs/namei.c's do_path_lookup() to
    + allow proper file lookup and opening in stackable file systems.
    +
    +2. Lockdep (a debugging feature) isn't aware of stacking, and so it
    + incorrectly complains about locking problems. The problem boils down to
    + this: Lockdep considers all objects of a certain type to be in the same
    + class, for example, all inodes. Lockdep doesn't like to see a lock held
    + on two inodes within the same task, and warns that it could lead to a
    + deadlock. However, stackable file systems do precisely that: they lock
    + an upper object, and then a lower object, in a strict order to avoid
    + locking problems; in addition, Unionfs, as a fan-out file system, may
    + have to lock several lower inodes. We are currently looking into Lockdep
    + to see how to make it aware of stackable file systems. In the meantime,
    + if you get any warnings from Lockdep, you can safely ignore them (or feel
    + free to report them to the Unionfs maintainers, just to be sure).
    +
    +For more information, see <http://unionfs.filesystems.org/>.
    --
    1.5.2.2


    \
     
     \ /
      Last update: 2007-12-10 03:49    [W:7.953 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site