[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hurd and Unix/Linux and Plan9 features
From: |
Ivan Shmakov |
Subject: |
Re: Hurd and Unix/Linux and Plan9 features |
Date: |
04 Feb 2007 20:53:11 +0600 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
>>>>> "o" == <olafBuddenhagen@gmx.net> writes:
S> * Also will it support hard links for directories?
IS> This problem was discussed on the list some time ago. My opinion
IS> that it /shouldn't/ be done. If one thinks of a directory as a
IS> mapping of file names to actual file objects, and of hard links as
IS> the alternate names to a file (directory) object, then it becomes
IS> hard to decide, which file (directory) the `..' name is mapped to?
o> Well, as you seem to have followed the ngHurd discussions, you
o> should be aware that this has shown to be only one of the reasons
o> why having ".." links in the filesystem is a bad idea. ngHurd
o> almost certainly won't have these, and in fact it might be changed
o> in the existing implementation as well. So, this is not really a
o> reason to avoid hardlinks to directories.
o> In another discussion at a different place, someone pointed out that
o> hardlinked directories are problematic, because this way loops are
o> possible, and the filesystem would no longer be a directed graph. No
o> idea whether this is a serious problem in practice.
At a first glance, handling of such loops might be implemented
in applications, so the kernel could provide hardlinks to
directories with no harm. However, the ``directed graph'' model
is not just about making no loops: it demands the way to, given
some directory, obtain its parent.
Then, if a ``directory'' is thought about as a mapping of names
to files (I mean not only regular files, but directories, pipes,
etc.), then hardlinks to a directory is to be meant as a
different names to the very same directory, so, e. g.:
$ mkdir a
$ ln a b
$ cat a/file
cat: a/file: No such file or directory
$ touch a/file
$ cat a/file
$ cat b/file
$
Suppose a different scenario:
a/ $ mkdir b
a/ $ mkdir c
a/ $ ln b c/d
a/ $ cd c/d/
a/c/d/ $ cd ..
Which path the last command would lead to, a/c/ (as a/c/d/../)
or a/ (as a/b/../)?
Should `..' entry be stored ``on disk'', the answer will
probably be the same every time the entry is used, bringing,
however, some confusion in how path names behave (in simple
cases, `..' in path works essentially like an ``eraser'',
removing a path component to the left.)
If it's to be derived from the current working directory (in
case of `cd'), the `..' sub-directories of `a/b/' and `a/c/d/'
would, indeed, be different directories. So the ``mappings''
are, actually, different. (This is how ``firmlinks''
implemented in Hurd, IIUC.)
Although I see no reason to deny such behaviour (either
``firmlinks'' or even ``no parent altogether''), my opinion is
that it's sufficiently different to ``traditional'' FS. Would
there be any uses for it? Wouldn't it make more sense to
support, e. g., some kind of a relational data model with a
separate interface?
S> 2. Will it support the Linux LVM concept?
IS> Looks like with HurdNG's ``space banks'', things would be even
IS> better than with the Linux LVM.
o> I think the space bank concept is rather orthogonal to partitions
o> and LVM. Space banks are about allocating memory from the available
o> stores, not about how stores are laid out on HD.
Well, I have little knowledge of ``space banks''. I know Linux
LVM somewhat better. In simple words, LVM allows one to:
* create physical volumes out of disk partitions;
* create volume groups out of one or more physical volumes;
* allocate and deallocate memory of volume groups into logical
volumes.
From my point of view, volume group is essentially a such
``store'', from which I could allocate memory for whichever
purposes I feel appropriate (swap space, news spool,
filesystems, etc.)
- Hurd and Unix/Linux and Plan9 features, Shams, 2007/02/01
- Re: Hurd and Unix/Linux and Plan9 features, Ivan Shmakov, 2007/02/03
- Re: Hurd and Unix/Linux and Plan9 features, Shams, 2007/02/03
- Re: Hurd and Unix/Linux and Plan9 features, olafBuddenhagen, 2007/02/03
- Re: Hurd and Unix/Linux and Plan9 features,
Ivan Shmakov <=
- Re: Hurd and Unix/Linux and Plan9 features, Shams, 2007/02/04
- Re: Hurd and Unix/Linux and Plan9 features, Pierre THIERRY, 2007/02/06
- Re: Hurd and Unix/Linux and Plan9 features, Ivan Shmakov, 2007/02/07
- Re: Hurd and Unix/Linux and Plan9 features, Pierre THIERRY, 2007/02/07
- symbolic links & `..' entry, Ivan Shmakov, 2007/02/08
- Re: symbolic links & `..' entry, Pierre THIERRY, 2007/02/08
- Re: symbolic links & `..' entry, Ivan Shmakov, 2007/02/10
- Re: symbolic links & `..' entry, Thomas Bushnell BSG, 2007/02/10
- Re: symbolic links & `..' entry, Pierre THIERRY, 2007/02/11
Re: Hurd and Unix/Linux and Plan9 features, Pierre THIERRY, 2007/02/03