lkml.org 
[lkml]   [1998]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectHow small files are a first step that allows eventual evolution of FS's into databases (was dynamic stat data)
This stat data issue is only one trivial piece of a larger goal of someday merging the other namespaces of the OS into the
filesystem. Frankly, I don't see my doing that until after a thorough foundation has been laid by making ReiserFS effective at
current filesystem usage patterns. That said, the complication of using balanced trees is quite arguably not worthwhile compared
to other objectives if one's goal is current filesystem usage patterns.

Once you understand that I want to lay a foundation suitable for someday evolving in the functionality of database, keyword,
version control, persistent object storage, and as many other namespaces as we have into the filesystem, then and only then can
you really understand why we designed ReiserFS this way. Small files are the hard first step that prevents incremental evolution
into database functionality (to be only slightly more precise, I intend to be set theoretic rather than employing relational
algebra, so database functionality will be an important subset of what the filesystem can do someday if I get my way).

I see us currently implementing endless different namespaces none of them as good as we could do with one namespace that we really
focused on. This is the way Microsoft works, we can't afford to work that way, let's continue to add to the Unix tradition of
building good tools so that application code is simpler.

I don't see ReiserFS exceeding or breaking the current VFS interface before I get more funding or active volunteers though.

Squid performance was not an objective but I am happy if we have it.

Hans

Stephen C. Tweedie wrote:
>
> Hi,
>
> On Mon, 22 Jun 1998 23:59:31 -0700, Hans Reiser <reiser@ricochet.net> said:
>
> > It would be nice to say cat /usr/local/bin/xemacs/version and get the
> > version of the xemacs installed, say /usr/local/bin/xemacs/ACL and get
> > the ACLs on xemacs, say /usr/local/bin/xemacs/owner and get the
> > traditional file stat_data field of owner, but still say
> > /usr/local/bin/xemacs to run xemacs by referencing the file body
> > (which can be thought of as the default file of the directory xemacs.)
>
> I'd have to disagree. This would be neat if we were designing a brand
> new operating system, but such munging of the namespace is just so
> non-Unix that I'd hate to see us doing that in Linux.
>
> Production systems need compatibility; POSIX and C stdio compatibility
> at least. Arbitrarily breaking the rules for the filesystem namespace
> doesn't seem like a good idea if POSIX already specifies perfectly good
> standard ways of getting at the same information.
>
> --Stephen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.062 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site