Hans Reiser <[email protected]> said:
> Horst von Brand wrote:
> >Hans Reiser <[email protected]> said:
> >>Horst von Brand wrote:
> >>>Spam <[email protected]> said:
> >>>>Christer Weinigel <[email protected]> said:
[...]
> >>>>>2. How do we want to expose named streams?
> >>>>> One suggestion is file-as-directory in some form.
> >>>Which is broken, as it forbids hard links to files.
> >>No, it forbids hard links to the directory aspect of the file-directory
> >>duality.
> >How do you distinguish a "hard link to the directory personality" from
> >"hard link to the file personality"?
> Put in (undoubtedly overly) simple terms, if you can do it to a file you
> can do it to the file personality, but if you currently can only do it
> to a directory and get an error from attempting it to a file then in the
> new scheme doing it to the hard link only gives the same error.
Let me sort this out: If it can't be done POSIXly to a directory, it can't
be done in Reiser4 to a file (which really is a directory too). So there
can be exactly _one_ hard link to a file. Way borken.
> Or, we can ask Alexander to help us use his deadlock detection algorithm
> and try to do things right....
Good luck with that one. I'd suspect if it can be made to work, it will
have _huge_ overhead, so much that it is useless. I'd love to be proven
wrong, but I won't hold my breath.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
> Hans Reiser <[email protected]> said:
>> Horst von Brand wrote:
>> >Hans Reiser <[email protected]> said:
>> >>Horst von Brand wrote:
>> >>>Spam <[email protected]> said:
>> >>>>Christer Weinigel <[email protected]> said:
> [...]
>> >>>>>2. How do we want to expose named streams?
>> >>>>> One suggestion is file-as-directory in some form.
>> >>>Which is broken, as it forbids hard links to files.
>> >>No, it forbids hard links to the directory aspect of the file-directory
>> >>duality.
>> >How do you distinguish a "hard link to the directory personality" from
>> >"hard link to the file personality"?
>> Put in (undoubtedly overly) simple terms, if you can do it to a file you
>> can do it to the file personality, but if you currently can only do it
>> to a directory and get an error from attempting it to a file then in the
>> new scheme doing it to the hard link only gives the same error.
> Let me sort this out: If it can't be done POSIXly to a directory, it can't
> be done in Reiser4 to a file (which really is a directory too). So there
> can be exactly _one_ hard link to a file. Way borken.
But you can make a hard link to a file in reiser4, and you can
access the metadata in both. I did this test:
echo "moooo" > test
ln test moo
chmod +x moo test
echo "0700" > test/metas/rwx
dir moo test
-rwx------ 2 root root 10 Sep 7 23:17 moo*
-rwx------ 2 root root 10 Sep 7 23:17 test*
echo "0777" > test/metas/rwx
dir moo test
-rwxrwxrwx 2 root root 10 Sep 7 23:17 moo*
-rwxrwxrwx 2 root root 10 Sep 7 23:17 test*
rm moo test
mkdir test
ln test moo
ln: `test': hard link not allowed for directory
If this is the intended behaviour I do not know, but it shows that
hard links works as normal.
You can also do linking to meta-data:
echo moo > moo
ln -s moo/metas/rwx test
dir
-rwxrwxrwx 1 root root 0 Sep 7 23:24 moo*
lrwxrwxrwx 1 root root 13 Sep 7 23:25 test -> moo/metas/rwx
echo 0700 > test
dir moo
-rwx------ 1 root root 0 Sep 7 23:24 moo*
>> Or, we can ask Alexander to help us use his deadlock detection algorithm
>> and try to do things right....
> Good luck with that one. I'd suspect if it can be made to work, it will
> have _huge_ overhead, so much that it is useless. I'd love to be proven
> wrong, but I won't hold my breath.
Horst von Brand wrote on Tue, 07 Sep 2004 17:02:20 -0400:
> Hans Reiser <[email protected]> said:
> > Or, we can ask Alexander to help us use his deadlock detection algorithm
> > and try to do things right....
>
> Good luck with that one. I'd suspect if it can be made to work, it will
> have _huge_ overhead, so much that it is useless. I'd love to be proven
> wrong, but I won't hold my breath.
Depends if you consider it to be a huge overhead to lock all the objects
that are ancestors (possibly through cyclical multiple parents) of the
fildirute (file/directory/attribute/whatever) being deleted/renamed.
It could definitely be a lot if you have some weird worst case directory
layout with lots of parent directories. But that's rare (most users
don't have that many directories anyway).
By the way, the deadlock system I was using is just a hack - a timeout
on the locking semaphores for each file. If it fails to lock everything
it needs, it backs off, waits a while, tries again, and eventually
reports EDEADLK if it exhausts the retry count.
Well, actually it's a bit fancier - it read-locks the file nodes as it
is traversing the graph to find all ancestors. Then when it has finished,
it write-locks the ones it needs to change.
- Alex