lkml.org 
[lkml]   [2007]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[GIT PULL -mm] Unionfs branch management code
Date
The following patches introduce new branch-management code into Unionfs as
well as fix a number of stability issues and resource leaks. For detailed
announcement, see end of this email.

As before, there is a git repo at:

git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/unionfs.git

(master.kernel.org:/pub/scm/linux/kernel/git/jsipek/unionfs.git)

There are 21 new commits:

Unionfs: Don't inline do_remount_{add,del,mode}_option
Unionfs: Added several BUG_ONs to assert dentry validity
Unionfs: Properly handle stale inodes passed to unionfs_permission
Unionfs: Pass lowernd to lower ->revalidate function
Unionfs: vfsmount reference counting fixes
Unionfs: unionfs_create needs to revalidate the dentry
Unionfs: Decrement totalopens counter on error in unionfs_open
Unionfs: Document unionfs_d_release locking
Unionfs: Remove the older incgen ioctl
Unionfs: Grab the unionfs sb private data lock around branch info users
Unionfs: Rewrite unionfs_d_revalidate
Unionfs: Introduce unionfs_mnt{get,put}
Unionfs: Bulk of branch-management remount code
Unionfs: Introduce branch-id code
Unionfs: Actually verify if dentry's info node is locked
Unionfs: Provide more helpful info on branch leaks during unmount
Unionfs: Rename unionfs_data sbcount field to more appropriate open_files
Unionfs: Proper comment on rwsem field
Unionfs: Documentation updates for branch-management
fs: Export drop_pagecache_sb symbol
fs: Introduce path{get,put}

Thanks,

Josef 'Jeff' Sipek <jsipek@cs.sunysb.edu>

---

Announcement:

We're pleased to announce that we merged new branch-management code into
Unionfs 2.0. Using this code, you can add, remove, and/or change the mode
of branches. We allow multiple branch-management operations at the same
time and they are applied atomically.

The new branch-management interface uses the remount functionality. It is
NOT compatible with the older Unionfs 1.x branch-management interface, which
used ioctl()s. The older interface was not atomic for multiple operations,
and had a fundamental consistency problem with open files being revalidated.
The new remount-based branch-management interface fixes all of that, and
also saves users from having to use another utility (unionctl) to control
their branches: you can now use plain /sbin/mount for all your
branch-management commands. Additionally, we now allow the entire union to
be remounted read-only or read-write. Here are a few examples of how to use
the new interface:

To delete a branch /foo, regardless where it is in the current union:

# mount -t unionfs -o remount,del=/foo none MOUNTPOINT

To insert (add) a branch /foo before /bar:

# mount -t unionfs -o remount,add=/bar:/foo none MOUNTPOINT

To insert (add) a branch /foo (in "rw" mode) at the very beginning (i.e., a
new highest-priority branch), you can use the above syntax, or use a short
hand version as follows:

# mount -t unionfs -o remount,add=/foo none MOUNTPOINT

To change the mode of one existing branch, say /foo, from read-only to
read-write, and change /bar from read-write to read-only:

# mount -t unionfs -o remount,mode=/foo=rw,mode=/bar=ro none MOUNTPOINT


The above are just a few examples. You can mix and match the branch
management commands. For more documentation and examples, see the following
file in the latest patch:

Documentation/filesystems/unionfs/usage.txt

Finally, the patch below includes bug fixes to a number of bugs we've
discovered during our thorough testing of the branch-management code. One
of the challenges in branch management is that it can change the composition
of a live, running file system *while* it has open files and cached objects.
We tested the code as much as possible to ensure that even under intense
multi-threaded workloads, generation number and stale cache entries are
handled properly.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-04-09 16:57    [W:1.758 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site