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 submounting
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 something (as
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 dirs?
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 is
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 allowed...
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 set up
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 about MNT_SLAVE
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
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.
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 submounting
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 =
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 there's
+ * 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
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 has
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 the
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, chdir is
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 you
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 true,
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 really no
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
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 theses. But my
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? /me ducks
Not unless you manage to get working union-mount [*NOT* unionfs]
* invalidation on unlink is still an open
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
* 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 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 also
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 and do
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 everything
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-fsdevel in
the body of a message to [EMAIL PROTECTED]
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
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
31 matches
Mail list logo
