Re: silent semantic changes with reiser4

I think there are two ways to analyze the code boundary issue.  One is 
"does it belong in the kernel?"  Another is, "does it belong in the 
filesystem. and if so should name resolution in a filesystem be split 
into two parts, one in kernel, and one in user space."  In ten years I 
might have the knowledge needed to make such a split, but I know for 
sure that I don't know how to do it today without regretting it 
tomorrow, and I don't really have confidence that I will ever be able to 
do it without losing performance.

Glad that BeFS finds the new model better.:)

Hans

Will Dyson wrote:

Hans Reiser wrote:

quoted

Will Dyson wrote:

quoted

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.

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 don't think having find in the kernel would be worth the cost or 
complexity.

However, now that I've had to think about it while writing the above, 
it occurs to me that if we wanted to offer something like the beos's 
live queries, doing it in the kernel might be the way to go.

For the 99.9% of people who were not beos users back in the day, the 
"live query" was a way to register a query string with the kernel, so 
that you got notifications when the list of files matching the query 
changed. It was pretty cool, but this is really just blue-skying since 
I am not stepping up to write such a beast any time soon.

quoted

quoted

However, the best alternative I've come up with is to simply export 
the index data as a special file (perhaps in sysfs?) and have 
userspace responsible for searching the index.

That is the best implementation suggestion I've heard for splitting 
the filesystem into two parts, one in user space and one in kernel, 
but I still don't trust it to work well.

Why not? And if it really splits the filesystem into two parts depends 
on which of the two following statements you agree with more:

"Fast searching is a feature of the filesystem"
"Maintaining indexes is a feature of the filesystem"


PS.
The file-as-directory attribute/stream/whatever model is a much better 
fit for befs's internals than the xattr api. If the kernel supported 
it, I would enable support for it in befs.