> > > As for unlink... How do you deal with having that thing
> > > mounted, mounting something _under_ it (so that vfsmount would be kept
> > > busy) and then unlinking that sucker?
> >
> > Yeah, that's a good point. Current patch doesn't deal with that.
> > Simplest solution could be to disall
Hi!
> > As for unlink... How do you deal with having that thing
> > mounted, mounting something _under_ it (so that vfsmount would be kept
> > busy) and then unlinking that sucker?
>
> Yeah, that's a good point. Current patch doesn't deal with that.
> Simplest solution could be to disallow subm
> I hope to get some breathing space next week, then I'll get back to
> VFS work.
Great.
> I'd rather do that one myself,
Sure, don't want to rob you of any fun stuff ;)
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
On Wed, May 23, 2007 at 05:25:49PM +0200, Miklos Szeredi wrote:
> > > How will this work with copy_tree() and namespace duplication, which
> > > currently walk the tree with only namespace_sem held?
> >
> > Easy - grab namespace_sem, grab vfsmount_lock, walk the subtree and bump
> > mnt_busy on ev
> > How will this work with copy_tree() and namespace duplication, which
> > currently walk the tree with only namespace_sem held?
>
> Easy - grab namespace_sem, grab vfsmount_lock, walk the subtree and bump
> mnt_busy on everything (by 1 + number of non-busy children). Then drop
> vfsmount_lock
On Wed, May 23, 2007 at 04:32:37PM +0200, Miklos Szeredi wrote:
> > Umm... It is related to detached subtrees, but I'm not sure if it is what
> > you are thinking about.
>
> I was thinking of a similar one by Mike Waychison. It had the problem
> of requiring a spinlock for mntget/mntput. It was
> > > * invalidation on unlink is still an open problem.
> > > * locking in final mntput() doesn't look nice; we probably need
> > > a new refcounting scheme for vfsmounts to make that work. I have a
> > > variant
> > > that might work here (and make life much easier for expiry logics in
> >
On Wed, May 23, 2007 at 03:23:54PM +0200, Ph. Marek wrote:
> How about some special node in eg. /proc (or a new filesystem)?
> Eg.
>/fileAsDir/etc/passwd/owner ...
> would work for all *files*. For directories we do not know whether we're
> still
> climbing the hierarchy or would like to see
On Wed, May 23, 2007 at 03:01:38PM +0200, Miklos Szeredi wrote:
> Someone might think of a way to make those work with directories.
> Invisible directory entries, anyone?
Not unless you manage to get working union-mount [*NOT* unionfs]
> > * invalidation on unlink is still an open problem.
Hello,
On Tuesday May 22, 2007, Miklos Szeredi wrote:
> Why do we want this?
>
>
> That depends on who you ask. My answer is this:
>
> 'foo.tar.gz/foo/bar' or
> 'foo.tar.gz/contents/foo/bar'
>
> or something similar.
>
I work for a similir goal in my bachelor's these
On Mittwoch, 23. Mai 2007, Al Viro wrote:
> Then I do not understand what this mechanism could be used for, other
> than an odd way to twist POSIX behaviour and see how much of the userland
> would survive that.
I have some similar considerations about how userspace should deal with that.
The beha
> On Wed, May 23, 2007 at 12:39:25PM +0100, Al Viro wrote:
> > Then I do not understand what this mechanism could be used for, other
> > than an odd way to twist POSIX behaviour and see how much of the userland
> > would survive that. Certainly not useful for your "look into tarball
> > as a tree"
On Wed, May 23, 2007 at 08:34:42AM -0400, Trond Myklebust wrote:
> On Wed, 2007-05-23 at 08:36 +0100, Al Viro wrote:
> > On Wed, May 23, 2007 at 09:19:17AM +0200, Miklos Szeredi wrote:
> > > > Eh... Arbitrary limitations are fun, aren't they?
> > >
> > > But these mounts _are_ special. There is
On Wed, 2007-05-23 at 08:36 +0100, Al Viro wrote:
> On Wed, May 23, 2007 at 09:19:17AM +0200, Miklos Szeredi wrote:
> > > Eh... Arbitrary limitations are fun, aren't they?
> >
> > But these mounts _are_ special. There is really no point in moving or
> > pivoting them.
>
> pivoting - probably tr
On Wed, May 23, 2007 at 12:39:25PM +0100, Al Viro wrote:
> Then I do not understand what this mechanism could be used for, other
> than an odd way to twist POSIX behaviour and see how much of the userland
> would survive that. Certainly not useful for your "look into tarball
> as a tree", unless y
On May 22 2007 20:48, Miklos Szeredi wrote:
>Why do we want this?
>
>
>That depends on who you ask. My answer is this:
>
> 'foo.tar.gz/foo/bar' or
> 'foo.tar.gz/contents/foo/bar'
>
>or something similar.
Stole reiser4 an idea.
These semantics are quite fragile. Until now, c
> When the real superblock is created. It could even be the _same_
> super block as the real one. There'd be just the problem of anchoring
> the dir-on-file dentries somewhere...
>
> Or with fuse the dir-on-file mount can just come from any mounted
> filesystem, again possibly the same one as th
> > Right. After locking vfsmount_lock, mount_dironfile() should recheck
> > if there was a race and bail out.
>
> Owww... Not pretty, that...
If the cost of ->enter() is low, then it shouln't really be a problem.
We can't use ->i_mutex for locking, and introducing a new lock for
this doesn't s
> > > + * This is tricky, because for namespace modification we must take the
> > > + * namespace semaphore. But mntput() is called from various places,
> > > + * sometimes with namespace_sem held. Fortunately in those places the
> > > + * mount cannot yet have MNT_DIRONFILE, or at least that's w
On Wed, May 23, 2007 at 12:09:19PM +0200, Miklos Szeredi wrote:
> Right. After locking vfsmount_lock, mount_dironfile() should recheck
> if there was a race and bail out.
Owww... Not pretty, that...
> I don't think the filesystem ought to try _creating_ a vfsmount. I
> imagine, that the fs ha
> On Wed, May 23, 2007 at 11:03:08AM +0200, Miklos Szeredi wrote:
> > I still don't get it where the superblock comes in. The locking is
> > "interesting" in there, yes. And I haven't completely convinced
> > myself it's right, let alone something that won't easily be screwed up
> > in the future
> > + * This is called if the object has no ->lookup() defined, yet the
> > + * path contains a slash after the object name.
> > + *
> > + * If the filesystem defines an ->enter() method, this will be called,
> > + * and the filesystem shall fill the supplied struct path or return an
> > + * error.
On Wed, May 23, 2007 at 11:03:08AM +0200, Miklos Szeredi wrote:
> I still don't get it where the superblock comes in. The locking is
> "interesting" in there, yes. And I haven't completely convinced
> myself it's right, let alone something that won't easily be screwed up
> in the future. So ther
On Tue, May 22, 2007 at 08:48:49PM +0200, Miklos Szeredi wrote:
> */
> -static int __follow_mount(struct path *path)
> +static int __follow_mount(struct path *path, bool enter)
> {
> int res = 0;
> while (d_mountpoint(path->dentry)) {
> - struct vfsmount *mounted = lookup
> > > As for unlink... How do you deal with having that thing
> > > mounted, mounting something _under_ it (so that vfsmount would be kept
> > > busy) and then unlinking that sucker?
> >
> > Yeah, that's a good point. Current patch doesn't deal with that.
> > Simplest solution could be to disallo
> > So your question is, which mount takes priority on the lookup? It
> > probably should be the propagated real mount, rather than the
> > dir-on-file one, shouldn't it?
> >
>
> Maybe this might belong into __link_path_walk() similar to the
> handling of symbolic links. If the real mount has alw
On 5/23/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> As for unlink... How do you deal with having that thing
> mounted, mounting something _under_ it (so that vfsmount would be kept
> busy) and then unlinking that sucker?
Yeah, that's a good point. Current patch doesn't deal with that.
Sim
On 5/23/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
So your question is, which mount takes priority on the lookup? It
probably should be the propagated real mount, rather than the
dir-on-file one, shouldn't it?
Maybe this might belong into __link_path_walk() similar to the
handling of symb
> On Wed, May 23, 2007 at 10:05:21AM +0200, Miklos Szeredi wrote:
> > > Er... These mounts might not be propagated, but what about a bind
> > > over another instance of such file in master tree?
> >
> > So your question is, which mount takes priority on the lookup? It
> > probably should be the
On Wed, May 23, 2007 at 10:05:21AM +0200, Miklos Szeredi wrote:
> > Er... These mounts might not be propagated, but what about a bind
> > over another instance of such file in master tree?
>
> So your question is, which mount takes priority on the lookup? It
> probably should be the propagated r
> > > Eh... Arbitrary limitations are fun, aren't they?
> >
> > But these mounts _are_ special. There is really no point in moving or
> > pivoting them.
>
> pivoting - probably true, moving... why not?
I don't see any use for that. But indeed, it should not be too hard
to do.
> > > What abou
On Wed, May 23, 2007 at 09:19:17AM +0200, Miklos Szeredi wrote:
> > Eh... Arbitrary limitations are fun, aren't they?
>
> But these mounts _are_ special. There is really no point in moving or
> pivoting them.
pivoting - probably true, moving... why not?
> > What about MNT_SLAVE stuff being se
> > > Interesting... How do you deal with mount propagation and things like
> > > mount --move?
> >
> > Moving (or doing other mount operations on) an ancestor shouldn't be a
> > problem. Moving this mount itself is not allowed, and neither is
> > doing bind or pivot_root. Maybe bind could be a
On Wed, May 23, 2007 at 08:36:04AM +0200, Miklos Szeredi wrote:
> > Interesting... How do you deal with mount propagation and things like
> > mount --move?
>
> Moving (or doing other mount operations on) an ancestor shouldn't be a
> problem. Moving this mount itself is not allowed, and neither i
> > Others might suggest accessing streams, resource forks or extended
> > attributes through such an interface. However this patch only deals
> > with the non-directory case, so directories would be excluded from
> > that interface.
>
> here's a possibly stupid question. What about symlinks to
> > When a non-directory object is accessed without a trailing slash, then
> > path resolution returns the object itself as usual.
> >
> > If a non-directory object is accessed with a trailing slash, then the
> > filesystem may opt to let the file be accessed as a directory. In
> > this case "som
Miklos Szeredi wrote:
Why do we want this?
That depends on who you ask. My answer is this:
'foo.tar.gz/foo/bar' or
'foo.tar.gz/contents/foo/bar'
or something similar.
Others might suggest accessing streams, resource forks or extended
attributes through such an interf
On Tue, May 22, 2007 at 08:48:49PM +0200, Miklos Szeredi wrote:
> Why do we want this?
>
>
> That depends on who you ask. My answer is this:
>
> 'foo.tar.gz/foo/bar' or
> 'foo.tar.gz/contents/foo/bar'
>
> or something similar.
>
> Others might suggest accessing streams
Why do we want this?
That depends on who you ask. My answer is this:
'foo.tar.gz/foo/bar' or
'foo.tar.gz/contents/foo/bar'
or something similar.
Others might suggest accessing streams, resource forks or extended
attributes through such an interface. However this patch
39 matches
Mail list logo
