VFS mapping table
PATCH 1/1 VFS mapping table
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.diff68dd58872ec33cfb4ce34306b712a8f4 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.
Signature · 2 lines
Bernard Blackham bernard at blackham dot com dot au
Quoted 4 lines · Bernard Blackham
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}/hostnameand {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.
Quoted 2 lines
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.