On Wed, Mar 30, 2011 at 7:30 AM, David Howells <[email protected]> wrote:
> Valerie Aurora <[email protected]> wrote:
>
>> As always, git trees for the kernel, util-linux, and e2fsprogs, lots
>> of documentation, and LWN articles describing the various problems
>> unioning file systems will encounter are here:
>>
>> http://valerieaurora.org/union/
>
> The webpage there says "linked_list" is the most recent branch, but that
> doesn't match with your patches posted here. ?Is "+ext2_cleanup" the matching
> branch?
That's never up to date, but I just fixed it. The branch you want is
"ext2_cleanup". Any branch with "+" at the front is a mistake from
trying to do a git push of a rebased branch. I deleted it.
-VAL
Valerie Aurora <[email protected]> wrote:
> That's never up to date, but I just fixed it. The branch you want is
> "ext2_cleanup". Any branch with "+" at the front is a mistake from
> trying to do a git push of a rebased branch. I deleted it.
Okay, I've got that pulled up to Linus's head branch. I've mostly got the RCU
pathwalk and managed dentry stuff correctly entangled.
However, I have a few questions:
(1) Is it meant to be possible to unionmount over a mount tree rather than
just a single mount? I ask because do_lookup_union() calls
__follow_mount().
(2) When you open a file that exists in the lower layer but not the top
layer, am I right in thinking that f_path points to the lower layer file?
(3) If I'm correct in (2), I presume something must intercept fchown() and
suchlike?
(4) I presume IS_DIR_UNIONED() only gives true on the upper layer (the one
that was mounted -o union)?
David
On Thu, Apr 21, 2011 at 6:09 AM, David Howells <[email protected]> wrote:
> Valerie Aurora <[email protected]> wrote:
>
>> That's never up to date, but I just fixed it. ?The branch you want is
>> "ext2_cleanup". ?Any branch with "+" at the front is a mistake from
>> trying to do a git push of a rebased branch. ?I deleted it.
>
> Okay, I've got that pulled up to Linus's head branch. ?I've mostly got the RCU
> pathwalk and managed dentry stuff correctly entangled.
Awesome, thanks!
> However, I have a few questions:
>
> ?(1) Is it meant to be possible to unionmount over a mount tree rather than
> ? ? just a single mount? ?I ask because do_lookup_union() calls
> ? ? __follow_mount().
It's meant to allow mounting over a mount tree, as long as all the
mounts are read-only. I don't recall the difference between
__follow_mount() and follow_mount() at this moment, but that code may
be left over from the time that we could only union mount a single
mount.
Think about it carefully though, and check my comments, and run the
union mounts test suite - I got this wrong a few times and added a
number of tests to make sure the mount point case is right.
> ?(2) When you open a file that exists in the lower layer but not the top
> ? ? layer, am I right in thinking that f_path points to the lower layer file?
If the file is opened read-write, then it is copied up and the f_path
points to the upper layer file. If the file is opened read-only, then
it is not copied up and the f_path points to the lower layer file.
So, yes, f_path points to the lower layer file.
> ?(3) If I'm correct in (2), I presume something must intercept fchown() and
> ? ? suchlike?
There's a thread somewhere on this, hang on...
http://kerneltrap.org/mailarchive/linux-fsdevel/2010/3/29/6897953/thread
Basically, if you open the file read-write and do an fchown() on it,
it works fine because the file is copied up on open. If you open the
file read-only and fchown() it (yes, that's permitted) then in union
mounts you will get EPERM or EBADF (don't recall which). Actually
implementing this requires copy-up after open, which requires atomic
update of the struct file pointer, which is ugly and painful and what
we were trying to avoid in the first place.
I discussed this with Al and Christoph and the consensus was along the
lines of, "What? You can do that? POSIX is so stupid. Yes, we don't
care if union mounts returns EPERM in this case that no one thinks
should work anyway."
If you can find a way to do this cleanly, hurray. Otherwise the
current code works for fchown/fchmod/utimensat already in the open
read-write case.
> ?(4) I presume IS_DIR_UNIONED() only gives true on the upper layer (the one
> ? ? that was mounted -o union)?
Yes. It maybe should be renamed...
Thanks,
-VAL