Re: reiser4 (was Re: [PATCH] Revised extended attributes interface)

From: Hans Reiser (
Date: Thu Dec 13 2001 - 04:23:46 EST

Andrew Pimlott wrote:

>On Wed, Dec 12, 2001 at 12:21:49AM +0300, Hans Reiser wrote:
>>Naming conventions are easy.
>While I look forward to your work, I think Anton points out some
>issues that you really should try to address now, only you have not
>understood them. Can I take a crack at posing some concrete
>questions that manifest the issues?
>Let's imagine that we have a Linux system with an NTFS filesystem
>and a reiserfs4 filesystem. You can make any tentative assumptions
>about reiserfs4 and new API's that you like, I just want to have an
>idea of how you envision the following working:
>First, I write a desktop application that wants to save an HTML file
>along with some other object that contains the name of the creating
>application. The latter can go anywhere you want, except in the
>same stream as the HTML file. The user has requested that the
>filename be /home/user/foo.html , and expects to be able to FTP this
>file to his ISP with a standard FTP program. What calls does my
>application make to store the HTML and the application name? If the
>answer is different depending on whether /home/user is NTFS or
>reiserfs4, explain both ways.
Are you sure that standard ftp will be able to handle extended
attributes without modification?

One approach is to create a plugin called ..archive that when read is a
virtual file consisting of an archive of everything in the directory.
 It would be interesting I think to attach said plugin to standard
directories by default along with several other standard plugins like, etc.

>Second, I booted NT and created a directory in the NTFS filesystem
>called /foo . In the directory, I created a file called bar. I
>also created a named stream called bar, and an extended attribute
>called bar. Now I boot Linux. What calls do I make to see each of
>the three objects called bar?

You access /foo/bar, /foo/bar/,,bar, /foo/ by name.

>The heart of Anton's argument is that the UNIX filesystem name space
>is basically used up--there's just not much room to add new
>semantics. The only obvious avenue for extension is, if /foo is not
>a directory, you can give some interpretation to /foo/bar . But
>this doesn't help if /foo is a directory. So something has to give,
>and we want to see what will give in reiserfs4.
Naming conventions are easy, but teaching user space is hard no matter
whose scheme is used.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:25 EST