Re: silent semantic changes with reiser4

[David Ford <david+challenge-response@blue-labs.org>]

[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]

Will Dyson wrote:

> Hans Reiser wrote:
>
>> Will Dyson wrote:
>>
>>>
>>> In the original BeOS, they solved the problem by having the 
>>> filesystem driver itself take a text query string and parse it, 
>>> returning a list of inodes that match. The whole business of parsing 
>>> a query string in the kernel (let alone in the filesystem driver) 
>>> has always seemed ugly to me. 
>>
>>
>> Why?
>
>
> Hmm. Trying to explain aesthetic judgments is always fun, but I'll try.
>
> String parsing bloats the kernel with code that will be called rarely, 
> and doing it inside the filesystem module makes for duplicate code if 
> more than one filesystem does it. But a good common parser routine (or 
> a kernel api that takes a pre-compiled parse tree) would reduce the 
> bad taste.


Like say.. printk() ?  :)

> The real objection I have is that it puts the kernel in the position 
> of doing more work than it has to for the system to operate correctly 
> and efficiently. The user wants to know what files match a certain set 
> of criteria. The filesystem provides special features which can 
> greatly accelerate some searches. Does it make more sense to move the 
> functionality of /usr/bin/find into the kernel, or to export the index 
> information so that an enhanced version of find can make use of it?


I think it depends largely on where you see file systems going 5, 10, 20 
years from now.  Are they going to be decadent designs or will they be 
flush with meta data and other tidbits?  Where does the heuristic line 
sit when it becomes better to put such a function into the kernel v.s. 
user land?

> I don't think having find in the kernel would be worth the cost or 
> complexity.


Probably not.  But as I view it, file systems are slowly evolving into 
relational objects and the margin between what are files and directories 
versus content within said objects is shrinking.  More and more, people 
are using a relational database to store content that once resided in 
singular files.

Sure, it makes for a much fatter *FS system, but the user doesn't care 
too much, he simply enjoys the ability to manage, search, and cross 
reference his content much more easily.

And then comes the "it's a user land thing" comment again.  And again 
the response.  When does moving this from user land into kernel land 
become a better choice.

With the file systems we have today, it's really not much of a gain 
compared to the cost of the move.

Consider Reiser4 now.  More and more meta data is being used in regards 
to files.  That margin is shrinking.

BeOS broached it, Microsoft is building it.  Just because they did it 
doesn't mean we have to do it nor that it is right.

But it's food for thought.  Especially as more and more tidbits get 
associated with files.

-david