[PATCH] VFS mapping table

[PATCH] VFS mapping table

[Bernard Blackham]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

Hi,

Whilst setting up a bunch of thin clients, I thought it'd be really
useful if a symlink could be pointed at, say /mnt/{ip}/hostname and
{ip} would expand to the IP address of the machine (inspired by
Tru64 unix).

It was subsequently realised that this could have other uses, so
here is a patch, against 2.4.20 (applies against 2.4.21-rc6 too)
that allows you to expand {keyword} to something customisable
through /proc. For usage details, see the comments at the top of
fs/vfs_map.c

Patch at http://dagobah.ucc.asn.au/linux-2.4.20-vfsmap.diff
68dd58872ec33cfb4ce34306b712a8f4  linux-2.4.20-vfsmap.diff

So does anybody think this would be a useful feature to have, or
just feature bloat? If useful, I'd be happy to port it to 2.5.xx.

Ta,
Bernard.
PS. please CC me on replies.

-- 
 Bernard Blackham 
 bernard at blackham dot com dot au

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] VFS mapping table

[viro]

On Sun, Jun 01, 2003 at 09:38:04PM +0800, Bernard Blackham wrote:

> Whilst setting up a bunch of thin clients, I thought it'd be really
> useful if a symlink could be pointed at, say /mnt/{ip}/hostname and
> {ip} would expand to the IP address of the machine (inspired by
> Tru64 unix).

You can trivially do that by having '/mnt/{ip}' a directory and
mount --bind /mnt/$IP '/mnt/{ip}' done from initscripts.  No magic
needed.
 
> So does anybody think this would be a useful feature to have, or
> just feature bloat? If useful, I'd be happy to port it to 2.5.xx.

a) it affects all pathname components.  IOW, in effect you are getting
the same bunch of symlinks in each directory.  Besides, what is supposed
to happen if somebody wants different things for different tasks (quite
realistic with your '{ip}' example)?

b) what if I set value to something that contains '/'?
c) what's so special about ' ', '\n' or '\r' (?!?) in the keys and values?
d) no locking whatsoever.

(a) is the real problem - such things should be (at the very least)
per-directory.  What's more, rationale for that stuff in OSF^WTrue64
doesn't apply to Linux - we don't have to modify any filesystem objects
to get host-specific mappings.  Yes, symlinks do not work if fs is
imported read-only.  But we don't need these beasts to be symlinks -
host (or group of processes) can have whatever mounts it wants and
bindings are mounts.  Moreover, with bindings '..' works correctly,
regardless of the relative positions in the tree, so you are less
constrained in the choice of layout.  IOW, we already have tools
to do it in a clean way - no need to copy kludges caused by lack
of decent mount layer in other kernels.