Messages in this thread | | | From | Jesse Pollard <> | Subject | Re: FS: hardlinks on directories | Date | Mon, 4 Aug 2003 16:16:39 -0500 |
| |
On Monday 04 August 2003 09:50, Stephan von Krawczynski wrote: > On Mon, 4 Aug 2003 15:04:28 +0100 (BST) > > Anton Altaparmakov <aia21@cam.ac.uk> wrote: > > For a start the kernel VFS dcache would break because you end up with > > multiple entries for each inode, one entry for each parallel directory > > tree. Read-only you are just about able to get away with it (been there, > > done that, don't recommend it!) but allow files to be deleted and it will > > blow up in your face. > > I cannot comment, I have no inside knowledge of it. > > > You ask for examples of applications? There are millions! Anything that > > walks the directory tree for a start, e.g. ls -R, find, locatedb, medusa, > > du, any type of search and/or indexing engine, chown -R, cp -R, scp > > -R, chmod -R, etc... > > There is a flaw in this argument. If I am told that mount --bind does just > about what I want to have as a feature then these applictions must have the > same problems already (if I mount braindead). So an implementation in fs > cannot do any _additional_ damage to these applications, or not?
Mount -bind only modifies the transient memory storage of a directory. It doesn't change the filesystem. Each bind occupies memory, and on a reboot, the bind is gone.
> My saying is not "I want to have hardlinks for creating a big mess of loops > inside my filesystems". Your view simply drops the fact that there are more > possibilities to create and use hardlinks without any loops...
been there done that, is is a "big mess of loops".
And you can't prevent the loops either, without scanning the entire graph, or keeping a graph location reference embeded with the file. Which then breaks "mv" for renaming directories... It would then have to scan the entire graph again to locate a possble creation of a loop, and regenerate the graph location for every file. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |