And as the normal filesystems are all using the common buffer routines
anyway, it's only the special cases tat are hurt by having to explicitly
do te dirty balancing. In fact, I suspect that raiserfs should =really=
try to use the common routines too - it will never beat the standard
filesystems in performance if it doesn't (the old-fashioned way of having
data in both buffer-cache and the page cache not only uses memory, but is
much slower for certain memory-mapped operations).
My guess is that reiserfs can't use the standard buffer routines in many
cases since the file data isn't necessarily block aligned. (I don't
know if this is true for small files, or for all files, but there are
definitely many cases where file data isn't located a specific block
location, and so the standard page cache routines probably won't work
for them.)
The idea (as I understand it; Hans I am sure will correct me if I'm
wrong) is that you win because you don't have to seek to another block
to read the data, since the data is stored in-line in the B-tree. Note
that I am *not* defending this design decision; just pointing out one of
the consequences of it. Personally, I think it's radical enough that
it's worth experimenting with, but I'm not convinced that it's going to
be a win. (I investigated doing something like this by storing data in
the inode ala fast inodes, and decided it wasn't worth the complexity
cost, but reiserfs should be able to store larger small files within the
B-tree than I was.)
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/