Symlink indirection

DISCUSSION Andrew Walrond 15 participants 28 messages Dec 13, 2002 – Dec 23, 2002 1 message not in the archive

Share & tools

Andrew Walrond

author

2002-12-13 14:59 UTC #0 lore raw

Quick question;

Is the number of allowed levels of symlink indirection (if that is the right phrase; I mean symlink -> symlink -> ... -> file) dependant on the kernel, or libc ? Where is it defined, and can it be changed?

TIA
Andrew

Marc-Christian Petersen

2002-12-13 15:04 UTC #1 lore raw

On Friday 13 December 2002 16:06, Andrew Walrond wrote:

Hi Andrew,

Quoted 3 lines

Is the number of allowed levels of symlink indirection (if that is the right phrase; I mean symlink -> symlink -> ... -> file) dependant on the kernel, or libc ? Where is it defined, and can it be changed?

fs/namei.c

if (current->link_count >= 5)

change to a higher value.

So, the answer is: Kernel :)

ciao, Marc

Andrew Walrond

author

2002-12-13 15:13 UTC #2 lore raw

Thanks Marc

5 is very low isn't it? Certainly marginal for an application I have in mind.

What's the reasoning behind it being a) 5 and b) so low?

Quoted 20 lines · Marc-Christian Petersen

On Friday 13 December 2002 16:06, Andrew Walrond wrote:
Hi Andrew,
Quoted 3 lines
Is the number of allowed levels of symlink indirection (if that is the right phrase; I mean symlink -> symlink -> ... -> file) dependant on the kernel, or libc ? Where is it defined, and can it be changed?
fs/namei.c
if (current->link_count >= 5)
change to a higher value.
So, the answer is: Kernel :)
ciao, Marc

Alan Cox

2002-12-13 16:36 UTC #3 lore raw

Quoted 4 lines · Andrew Walrond

Thanks Marc
5 is very low isn't it? Certainly marginal for an application I have in mind.

8 is more normal, but their are recursion and stack size considerations

Richard B. Johnson

2002-12-13 15:20 UTC #4 lore raw

In reply to Marc-Christian Petersen

Quoted 10 lines · Marc-Christian Petersen

On Friday 13 December 2002 16:06, Andrew Walrond wrote:
Hi Andrew,
Quoted 3 lines
Is the number of allowed levels of symlink indirection (if that is the right phrase; I mean symlink -> symlink -> ... -> file) dependant on the kernel, or libc ? Where is it defined, and can it be changed?
fs/namei.c

Quoted 7 lines

if (current->link_count >= 5)
change to a higher value.
So, the answer is: Kernel :)
ciao, Marc

No, that thing (whetever it is) is different.

Script started on Fri Dec 13 10:26:30 2002

# file *
foo:        symbolic link to ../foo
typescript: empty
# pwd
/root/foo
# cd *
# cd *
# cd *
# cd *
# cd *
# cd *
# pwd
/root/foo/foo/foo/foo/foo/foo/foo
# cd *
# cd *
# cd *
# pwd
/root/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo
# cd *
# cd *
# cd *
# pwd
/root/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo
# exit
exit

Script done on Fri Dec 13 10:27:21 2002

You can do this until you run out of string-space. Your "link-count" has something to do with something else.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.

James Antill

2002-12-13 16:10 UTC #5 lore raw

Quoted 18 lines · Richard B. Johnson

Quoted 16 lines · Marc-Christian Petersen
On Friday 13 December 2002 16:06, Andrew Walrond wrote:
Hi Andrew,
Quoted 3 lines
Is the number of allowed levels of symlink indirection (if that is the right phrase; I mean symlink -> symlink -> ... -> file) dependant on the kernel, or libc ? Where is it defined, and can it be changed?
fs/namei.c
if (current->link_count >= 5)
change to a higher value.
So, the answer is: Kernel :)

Quoted 7 lines

Quoted 1 line
ciao, Marc
No, that thing (whetever it is) is different.
Script started on Fri Dec 13 10:26:30 2002
# file *
foo:        symbolic link to ../foo

*sigh*, you are following one symlink at a time ... what is this
proving ?

Quoted 2 lines

You can do this until you run out of string-space. Your "link-count" has something to do with something else.

The link count is for recursively following symlinks, as the original
question wanted to know ... and has been discussed on lkml numerous times.

Andrew, one extra piece of information you might not know is that the
above value doesn't come into play when the new symlink is the last element in the new path, then you get a higher value.
The full code...

        if (current->link_count >= max_recursive_link)
                goto loop;
        if (current->total_link_count >= 40)
                goto loop;
[...]
        current->link_count++;
        current->total_link_count++;
        UPDATE_ATIME(dentry->d_inode);
        err = dentry->d_inode->i_op->follow_link(dentry, nd);
        current->link_count--;

...Ie. a link from /a -> /b/c where "b" is a symlink takes the "max_recursive_link" value (5 on vanilla kernels) but if "/b/c" was a symlink then you get to use the 40 value.

Signature · 4 lines

# James Antill -- [email protected]
:0:
* ^From: .*james@and\.org
/dev/null

Andrew Walrond

author

2002-12-13 16:27 UTC #6 lore raw

Hi James.

Thanks for the info; my application is now entirely plausible :) And apologies for asking an FAQ. (Google didn't throw up anything useful)

BTW is documented anywhere except the code?

Andrew

Quoted 25 lines

The link count is for recursively following symlinks, as the original
question wanted to know ... and has been discussed on lkml numerous times.
Andrew, one extra piece of information you might not know is that the
above value doesn't come into play when the new symlink is the last element in the new path, then you get a higher value.
The full code...
        if (current->link_count >= max_recursive_link)
                goto loop;
        if (current->total_link_count >= 40)
                goto loop;
[...]
        current->link_count++;
        current->total_link_count++;
        UPDATE_ATIME(dentry->d_inode);
        err = dentry->d_inode->i_op->follow_link(dentry, nd);
        current->link_count--;
...Ie. a link from /a -> /b/c where "b" is a symlink takes the "max_recursive_link" value (5 on vanilla kernels) but if "/b/c" was a symlink then you get to use the 40 value.

James Antill

2002-12-13 17:16 UTC #7 lore raw

Quoted 4 lines · Andrew Walrond

Hi James.
Thanks for the info; my application is now entirely plausible :) And apologies for asking an FAQ. (Google didn't throw up anything useful)

Sorry, this was an error on my part, I shouldn't reply to Richard's
posts until I've calmed down.

Quoted 1 line

BTW is documented anywhere except the code?

Apart from this mailing list, not AFAIK.

Quoted 24 lines

Quoted 23 lines
The link count is for recursively following symlinks, as the
original
question wanted to know ... and has been discussed on lkml numerous times.
Andrew, one extra piece of information you might not know is that
the
above value doesn't come into play when the new symlink is the last element in the new path, then you get a higher value.
The full code...
        if (current->link_count >= max_recursive_link)

                goto loop;
        if (current->total_link_count >= 40)
                goto loop;
[...]
        current->link_count++;
        current->total_link_count++;
        UPDATE_ATIME(dentry->d_inode);
        err = dentry->d_inode->i_op->follow_link(dentry, nd);
        current->link_count--;
...Ie. a link from /a -> /b/c where "b" is a symlink takes the

Quoted 2 lines

Quoted 2 lines
"max_recursive_link" value (5 on vanilla kernels) but if "/b/c" was a symlink then you get to use the 40 value.

The last part of the path is still part of the follow_link, and thus
subject to the non-total link_count value. The only times you get the bigger value is...

/a -> /b/c
/b -> /b.1 -> /b.2 -> /b.3 -> /b.4
/b.4/c -> /b.4/c.1 -> /b.4/c.2 -> /b.4/c.3 -> /b.4/c.4

...here you can open /a even if you'll follow more than ->link_count links.

Signature · 4 lines

# James Antill -- [email protected]
:0:
* ^From: .*james@and\.org
/dev/null

Andrew Walrond

author

2002-12-13 16:17 UTC #8 lore raw

In reply to Richard B. Johnson

No, I think marc was right...

daedalus@bob sym $ ls -l
total 4

lrwxrwxrwx    1 daedalus users           1 Dec 13 16:19 a -> b
lrwxrwxrwx    1 daedalus users           1 Dec 13 16:19 b -> c
lrwxrwxrwx    1 daedalus users           1 Dec 13 16:20 c -> d
lrwxrwxrwx    1 daedalus users           1 Dec 13 16:20 d -> e
lrwxrwxrwx    1 daedalus users           1 Dec 13 16:20 e -> f
lrwxrwxrwx    1 daedalus users           1 Dec 13 16:20 f -> g
lrwxrwxrwx    1 daedalus users           4 Dec 13 16:21 g -> test
-rw-r--r--    1 daedalus users           6 Dec 13 16:18 test

daedalus@bob sym $ cat a
cat: a: Too many levels of symbolic links
daedalus@bob sym $ cat b
cat: b: Too many levels of symbolic links
daedalus@bob sym $ cat c
Hello

Jesse Pollard

2002-12-13 16:18 UTC #9 lore raw

In reply to Richard B. Johnson

Quoted 48 lines · Richard B. Johnson

Quoted 10 lines · Marc-Christian Petersen
On Friday 13 December 2002 16:06, Andrew Walrond wrote:
Hi Andrew,
Quoted 3 lines
Is the number of allowed levels of symlink indirection (if that is the right phrase; I mean symlink -> symlink -> ... -> file) dependant on the kernel, or libc ? Where is it defined, and can it be changed?
fs/namei.c
Quoted 7 lines
if (current->link_count >= 5)
change to a higher value.
So, the answer is: Kernel :)
ciao, Marc
No, that thing (whetever it is) is different.
Script started on Fri Dec 13 10:26:30 2002
# file *
foo:        symbolic link to ../foo
typescript: empty
# pwd
/root/foo
# cd *
# cd *
# cd *
# cd *
# cd *
# cd *
# pwd
/root/foo/foo/foo/foo/foo/foo/foo
# cd *
# cd *
# cd *
# pwd
/root/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo
# cd *
# cd *
# cd *
# pwd
/root/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo
# exit
exit

Quoted 5 lines

Script done on Fri Dec 13 10:27:21 2002
You can do this until you run out of string-space. Your "link-count" has something to do with something else.

Example isn't the same thing:

[pollard@merlin ~/test]$ echo "test" >target
[pollard@merlin ~/test]$ ln -s target a - 1 link
[pollard@merlin ~/test]$ ln -s a b - 2 links
[pollard@merlin ~/test]$ ln -s b c - 3
[pollard@merlin ~/test]$ ln -s c d - 4
[pollard@merlin ~/test]$ cat d
test
[pollard@merlin ~/test]$ ln -s d e -5
[pollard@merlin ~/test]$ cat e
test
[pollard@merlin ~/test]$ ln -s e f -6
[pollard@merlin ~/test]$ cat f
cat: f: Too many levels of symbolic links

This catches problem situations like:

[pollard@merlin ~/test]$ ln -s loop loop [pollard@merlin ~/test]$ ls -l loop
lrwxrwxrwx 1 pollard NA0101 4 Dec 13 10:24 loop -> loop
[pollard@merlin ~/test]$ cat loop
cat: loop: Too many levels of symbolic links

Signature · 5 lines

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]

Any opinions expressed are solely my own.

Richard B. Johnson

2002-12-13 15:13 UTC #10 lore raw

In reply to Andrew Walrond

Quoted 9 lines · Andrew Walrond

Quick question;
Is the number of allowed levels of symlink indirection (if that is the right phrase; I mean symlink -> symlink -> ... -> file) dependant on the kernel, or libc ? Where is it defined, and can it be changed?
TIA
Andrew

Since a symlink is just a file containing a name, the resulting path length is simply the maximum path length that user-space tools allow. This should be defined as "PATH_MAX". Posix defines this as 255 characters but I think posix requires that this be the minimum and all file-name handling buffers must be at least PATH_MAX in length.

A hard link is just another directory-entry for the same file. This, therefore follows the same rules. There must be enough space on the device to contain the number of directory entries, as well as enough buffer length in the tools necessary to manipulate these "nested" directories, which are not really "nested" at all.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.

Alfred M. Szmidt

2002-12-13 16:34 UTC #11 lore raw

This should be defined as "PATH_MAX".

This should only be defined if such an limit exists. Systems like GNU/Hurd do not have this limit, but GNU/Linux does.

Jeff Bailey

2002-12-13 16:44 UTC #12 lore raw

In reply to Richard B. Johnson

Quoted 5 lines · Richard B. Johnson

Since a symlink is just a file containing a name, the resulting path length is simply the maximum path length that user-space tools allow. This should be defined as "PATH_MAX". Posix defines this as 255 characters but I think posix requires that this be the minimum and all file-name handling buffers must be at least PATH_MAX in length.

Small nit here, the Posix draft I have says that the definition shall be omitted from the <limits.h> header on specific implementation where the corresponding value is equal or greater than the stated minimum, but where the value can vary depending on the file to which it is applied.

Please don't ever rely on PATH_MAX existing. pathconf() is a better tool. We spend a lot of time chasing authors to explain to them why it really is okay for the Hurd (i386-pc-gnu)'s libc to omit this definition.

Tks,
Jeff Bailey

Signature · 3 lines

When you get to the heart,
use a knife and fork.
 - From instructions on how to eat an artichoke.

Amos Waterland

2002-12-13 17:08 UTC #13 lore raw

I think that you and Richard are dicussing a slightly different issue than the original poster asked about. The original question was:

Quoted 3 lines · Andrew Walrond

Is the number of allowed levels of symlink indirection (if that is the right phrase; I mean symlink -> symlink -> ... -> file) dependant on the kernel, or libc ? Where is it defined, and can it be changed?

To which Richard replied:

Quoted 11 lines

Since a symlink is just a file containing a name, the resulting path length is simply the maximum path length that user-space tools allow. This should be defined as "PATH_MAX". Posix defines this as 255 characters but I think posix requires that this be the minimum and all file-name handling buffers must be at least PATH_MAX in length.
A hard link is just another directory-entry for the same file. This, therefore follows the same rules. There must be enough space on the device to contain the number of directory entries, as well as enough buffer length in the tools necessary to manipulate these "nested" directories, which are not really "nested" at all.

But Richard is not actually completely correct. There is a limit of 5 levels of symlink indirection in vanilla 2.4 series Linux kernels.

% touch 0
% for i in seq 1 10; do ln -s ls | sort | tail -1 $i; done
% ls
0 1 10 2 3 4 5 6 7 8 9
% cat 5
% cat 6
cat: 6: Too many levels of symbolic links
% strace cat 6 2>&1 | grep 'open("6",'
open("6", O_RDONLY|O_LARGEFILE) = -1 ELOOP (Too many levels of symbolic links)

This has been discussed by Al Viro et al. many times on lkml. I believe that it is not a user-space or POSIX issue, but rather a kernel issue. Thanks.

Amos Waterland

Richard B. Johnson

2002-12-13 17:41 UTC #14 lore raw

Quoted 35 lines · Amos Waterland

I think that you and Richard are dicussing a slightly different issue than the original poster asked about. The original question was:
Quoted 3 lines · Andrew Walrond
Is the number of allowed levels of symlink indirection (if that is the right phrase; I mean symlink -> symlink -> ... -> file) dependant on the kernel, or libc ? Where is it defined, and can it be changed?
To which Richard replied:
Quoted 11 lines
Since a symlink is just a file containing a name, the resulting path length is simply the maximum path length that user-space tools allow. This should be defined as "PATH_MAX". Posix defines this as 255 characters but I think posix requires that this be the minimum and all file-name handling buffers must be at least PATH_MAX in length.
A hard link is just another directory-entry for the same file. This, therefore follows the same rules. There must be enough space on the device to contain the number of directory entries, as well as enough buffer length in the tools necessary to manipulate these "nested" directories, which are not really "nested" at all.
But Richard is not actually completely correct. There is a limit of 5 levels of symlink indirection in vanilla 2.4 series Linux kernels.
% touch 0
% for i in seq 1 10; do ln -s ls | sort | tail -1 $i; done
% ls
0 1 10 2 3 4 5 6 7 8 9
% cat 5
% cat 6
cat: 6: Too many levels of symbolic links
% strace cat 6 2>&1 | grep 'open("6",'
open("6", O_RDONLY|O_LARGEFILE) = -1 ELOOP (Too many levels of symbolic links)

Quoted 6 lines

This has been discussed by Al Viro et al. many times on lkml. I believe that it is not a user-space or POSIX issue, but rather a kernel issue. Thanks.
Amos Waterland

Yep. I thought the original poster was talking about following the links, i.e., "indirection", rather than creating links which is "definition".

So, the kernel does set a limit on the number of symlinks of the form,

ln -s a b ; ln -s b c ; ln -s c d ; ln -s d e ; # etc.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.

A message that is not in the archive (sent off-list or not yet received): [email protected]

Pete Zaitcev

2002-12-13 16:08 UTC #16 lore raw

Quoted 9 lines

Quoted 3 lines
Is the number of allowed levels of symlink indirection (if that is the right phrase; I mean symlink -> symlink -> ... -> file) dependant on the kernel, or libc ? Where is it defined, and can it be changed?
fs/namei.c
if (current->link_count >= 5)
change to a higher value.

This is vey, very misleading statement. The counter mentioned above is there to protect stacks from overflow, but our symlink resolution is largely non-recursive, and certainly not in case of a tail recursion within the same directory.

Also, consider this message from Al:

----------------------------------------------------
From: Alexander Viro <[email protected]>
Date: Mon, 3 Jun 2002 13:01:16 -0400

Quoted 7 lines · Matt Wilson

SUSv3:
http://www.opengroup.org/onlinepubs/007904975/basedefs/limits.h.html
{_POSIX_SYMLOOP_MAX} The number of symbolic links that can be
traversed in the resolution of a pathname in the absence of a loop. Value: 8

... and that has nothing to said limit of 5. What we do have limited is the number of nested symlinks. 4BSD and derived Unices limit the total amount of symlinks traveresed in pathname resolution. Example:
if you have

/a -> b
/b/a -> b
/b/b/a -> b
/b/b/b/a -> b
/b/b/b/b/a -> b
/b/b/b/b/b/a -> b
/b/b/b/b/b/b/a -> b
/b/b/b/b/b/b/b/a -> b
/b/b/b/b/b/b/b/b/a -> b

the pathname

/a/a/a/a/a/a/a/a/a

will resolve to

/b/b/b/b/b/b/b/b/b

and there will be 9 symlink traversals done during the pathname resolution. However, the depth (i.e. the thing we do limit) is 1 in that case. OTOH, with

/1 -> 2/a
/2 -> 3/a
/3 -> 4/a
/4 -> 5/a
/5 -> 6/a
/6 -> 7/a

will resolve to

/7/a/a/a/a/a/a

with 6 symlink traversals and depth 6. IOW, SuS limit is not an argument for changing the Linux one - they limit different things. They are not independent, of course, since depth of recursion can't be greater than total amount of symlinks we had traversed, but that's a separate story.

Frankly, all cases when I had seen the nested symlink farms of that depth would be better served by use of bindings - these are not subject to any limits on nesting and avoid a lot of PITA inherent to symlink farms. To put it another way, nested symlink farms grow from attempts to work around the lack of bindings. It's not that you need to replace all symlinks with bindings, of course - the crown of the tree is usually OK, it's the trunk that acts as source of pain.

Andrew Walrond

author

2002-12-13 16:41 UTC #17 lore raw

Pete,

Sorry for being dense, but what do you mean by 'bindings' ? Hard links?

Andrew

Quoted 7 lines

Frankly, all cases when I had seen the nested symlink farms of that depth would be better served by use of bindings - these are not subject to any limits on nesting and avoid a lot of PITA inherent to symlink farms. To put it another way, nested symlink farms grow from attempts to work around the lack of bindings. It's not that you need to replace all symlinks with bindings, of course - the crown of the tree is usually OK, it's the trunk that acts as source of pain.

Pete Zaitcev

2002-12-13 16:47 UTC #18 lore raw

Quoted 4 lines

Date: Fri, 13 Dec 2002 16:48:45 +0000
From: Andrew Walrond <[email protected]>
Sorry for being dense, but what do you mean by 'bindings' ? Hard links?

$ man mount

Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
mount --bind olddir newdir
After this call the same contents is accessible in two places.

-- Pete

Andrew Walrond

author

2002-12-13 16:56 UTC #19 lore raw

Of course; Didn't think of that in this context.

My application of symlinks involves overlaying several directories onto another, in an order such that any like named files are overridden in a defined way.

I had thought about asking the feasibility of [made up name] 'transparent bindings' which would have this effect

Suppose I might as well ask now ;) Any takers?

Quoted 16 lines · Pete Zaitcev

Quoted 5 lines
Date: Fri, 13 Dec 2002 16:48:45 +0000
From: Andrew Walrond <[email protected]>
Sorry for being dense, but what do you mean by 'bindings' ? Hard links?
$ man mount
Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
mount --bind olddir newdir
After this call the same contents is accessible in two places.
-- Pete

Joseph Fannin

2002-12-14 06:16 UTC #20 lore raw

Quoted 10 lines · Andrew Walrond

Of course; Didn't think of that in this context.
My application of symlinks involves overlaying several directories onto another, in an order such that any like named files are overridden in a defined way.
I had thought about asking the feasibility of [made up name] 'transparent bindings' which would have this effect
Suppose I might as well ask now ;) Any takers?

I don't understand what you are trying to explain. Do you mean a
union mount, or a variation thereof?

I thought Al Viro was going to do union mount support for 2.5, but
I haven't heard about it in a while. Maybe it went in and no one noticed?

Quoted 25 lines

Quoted 7 lines · Pete Zaitcev
Quoted 5 lines
Date: Fri, 13 Dec 2002 16:48:45 +0000
From: Andrew Walrond <[email protected]>
Sorry for being dense, but what do you mean by 'bindings' ? Hard links?
Quoted 9 lines
$ man mount
Since Linux 2.4.0 it is possible to remount part of the file hierarchy
somewhere else. The call is
mount --bind olddir newdir
After this call the same contents is accessible in two places.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 4 lines

Joseph Fannin
[email protected]

"That's all I have to say about that." -- Forrest Gump.

Andrew Walrond

author

2002-12-14 12:40 UTC #21 lore raw

Quoted 7 lines · Joseph Fannin

I don't understand what you are trying to explain. Do you mean a
union mount, or a variation thereof?
I thought Al Viro was going to do union mount support for 2.5, but
I haven't heard about it in a while. Maybe it went in and no one noticed?

Hi Joseph

I'm not familiar with the phrase 'union mount' and although google gives wads of hits, I can't find a good description of it

What I mean is (contrived example with made-up mount option --overlay)

mkdir a
echo "a/x" > a/x
echo "a/y" > a/y
echo "a/z" > a/z

mkdir b
echo "b/y" > b/y

mkdir c
echo "c/z" > c/z

mkdir d
mount --bind a d
mount --bind --overlay b d
mount --bind --overlay c d

cat d/x
"a/x"

cat d/y
"b/x"

cat d/z
"c/z"

This would be *really* useful and nice. I currently emulate this behavior with a bash script which creates hard or soft links, but the mounting system would be much nicer, easier to unwind etc.

I assume this isn't possible now (man mount gives no hint), but how feasible is it? Has anybody tried to implement this? If yes and No perhaps I could (with some initial guidance) have a look at implementing this.

I don't use HD's much anymore, so it would need to work for tmpfs.

John Bradford

2002-12-14 13:36 UTC #22 lore raw

Quoted 27 lines

Quoted 5 lines
I don't understand what you are trying to explain. Do you mean a
union mount, or a variation thereof?
I thought Al Viro was going to do union mount support for 2.5, but
I haven't heard about it in a while. Maybe it went in and no one noticed?
I'm not familiar with the phrase 'union mount' and although google gives wads of hits, I can't find a good description of it
What I mean is (contrived example with made-up mount option --overlay)
mkdir a
echo "a/x" > a/x
echo "a/y" > a/y
echo "a/z" > a/z
mkdir b
echo "b/y" > b/y
mkdir c
echo "c/z" > c/z
mkdir d
mount --bind a d
mount --bind --overlay b d
mount --bind --overlay c d

Quoted 5 lines

cat d/x
"a/x"
cat d/y
"b/x"

Shouldn't that be "b/y"?

Quoted 2 lines

cat d/z
"c/z"

John.

Andrew Walrond

author

2002-12-14 13:53 UTC #23 lore raw

Yes, typo - thanks John.

Trying again...

(contrived example with made-up mount option --overlay)

mkdir a
echo "a/x" > a/x
echo "a/y" > a/y
echo "a/z" > a/z

mkdir b
echo "b/y" > b/y

mkdir c
echo "c/z" > c/z

mkdir d
mount --bind a d
mount --bind --overlay b d
mount --bind --overlay c d

cat d/x
"a/x"

cat d/y
"b/y"

cat d/z
"c/z"

John Bradford

2002-12-14 15:54 UTC #24 lore raw

Quoted 18 lines

(contrived example with made-up mount option --overlay)
mkdir a
echo "a/x" > a/x
echo "a/y" > a/y
echo "a/z" > a/z
mkdir b
echo "b/y" > b/y
mkdir c
echo "c/z" > c/z
mkdir d
mount --bind a d
mount --bind --overlay b d
mount --bind --overlay c d

Quoted 8 lines

cat d/x
"a/x"
cat d/y
"b/y"
cat d/z
"c/z"

BSD has a mount_union command which does this, as well as mount_null, which allows you to effectively mount a filesystem more than once.

I'm not sure how well it works, though, it might only work on some filesystems.

John.

Stephen Wille Padnos

2002-12-14 19:42 UTC #25 lore raw

In reply to Andrew Walrond

Quoted 10 lines · Andrew Walrond

[snip]
cat d/x
"a/x"
cat d/y
"b/y"
cat d/z
"c/z"

What would you expect to happen if you then did:
echo "d/w" > d/w

Which physical directory would you expect a new file to go into?

- Steve

Andrew Walrond

author

2002-12-15 00:34 UTC #26 lore raw

Hi steve

Quoted 6 lines · Stephen Wille Padnos

What would you expect to happen if you then did:
echo "d/w" > d/w
Which physical directory would you expect a new file to go into?

Using my example:

mkdir a
echo "a/x" > a/x
echo "a/y" > a/y
echo "a/z" > a/z

mkdir b
echo "b/y" > b/y

mkdir c
echo "c/z" > c/z

mkdir d
mount --bind a d
mount --bind --overlay b d
mount --bind --overlay c d

cat d/x
"a/x"

cat d/y
"b/y"

cat d/z
"c/z"

Then...

echo "d/w" > d/w would create a new file in directory a. echo "d/y" > d/y would replace the file b/y etc...

Is this sort of thing possible, or are there fundamental reasons that would make it difficult?

Andrew

Thomas Zimmerman

2002-12-23 05:48 UTC #27 lore raw

Quoted 34 lines · On Sun, 15 Dec 2002 00:41:06 +0000 Andrew Walrond <[email protected]> wrote:

Hi steve
Quoted 6 lines · Stephen Wille Padnos
What would you expect to happen if you then did:
echo "d/w" > d/w
Which physical directory would you expect a new file to go into?
Using my example:
mkdir a
echo "a/x" > a/x
echo "a/y" > a/y
echo "a/z" > a/z
mkdir b
echo "b/y" > b/y
mkdir c
echo "c/z" > c/z
mkdir d
mount --bind a d
mount --bind --overlay b d
mount --bind --overlay c d
cat d/x
"a/x"
cat d/y
"b/y"

Quoted 8 lines

cat d/z
"c/z"
Then...
echo "d/w" > d/w would create a new file in directory a. echo "d/y" > d/y would replace the file b/y etc...

I would have expected any changes to /d/* to happen in c; as that was the *last* change to the mount point. It would allow much niceness, like NFS root with local changes having persistence, if you "mount -bind -overlay <smaller local drive> /"

Quoted 2 lines

Is this sort of thing possible, or are there fundamental reasons that would make it difficult?

I'll leave that to greater minds then mine. :)

Quoted 7 lines

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

James Antill

2002-12-13 17:25 UTC #28 lore raw

In reply to Pete Zaitcev

Quoted 6 lines · Pete Zaitcev

Quoted 6 lines
Quoted 3 lines
Is the number of allowed levels of symlink indirection (if that is the right phrase; I mean symlink -> symlink -> ... -> file) dependant on the kernel, or libc ? Where is it defined, and can it be changed?
fs/namei.c

Quoted 8 lines

Quoted 3 lines
if (current->link_count >= 5)
change to a higher value.
This is vey, very misleading statement. The counter mentioned above is there to protect stacks from overflow, but our symlink resolution is largely non-recursive, and certainly not in case of a tail recursion within the same directory.

tail recursion is a bad name, as that implies the last element of the
path can go beyond the above value. A better way is to say that each element of the path can have at most link_count and the total path can have at most total_link_count symlinks (or that nested symlinks are limited to a small number, in Al's words).

Signature · 4 lines

# James Antill -- [email protected]
:0:
* ^From: .*james@and\.org
/dev/null