lkml.org 
[lkml]   [2004]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: silent semantic changes with reiser4
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

begin:vcard
fn:David Ford
n:Ford;David
email;internet:david@blue-labs.org
title:Industrial Geek
tel;home:Ask please
tel;cell:(203) 650-3611
x-mozilla-html:TRUE
version:2.1
end:vcard

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