On Sat, 2 Sep 2000, Linus Torvalds wrote:
> Not at all. In fact, I'd prefer it that way, because this same thing is
> obviously going to be useful for any other block filesystem with the same
> issue.
Which is a nice way to say "any other block filesystem in the tree" ;-/
Oh, well... Modulo ->i_blocks issue (I'ld still like to hear if Ted has
something nicer) ext2 should be OK now. minix and sysvfs are easy
(slightly easier than ext2, in fact). Hell knows what's up with UDF - I
didn't look at it lately. UFS is a bitch. We will either have to deal
with two fragment-expanding subsystems (one for directories, another for
files) _or_ go for directories-in-pagecache. That would nicely encapsulate
all knowledge of that stuff into ufs_prepare_write(), but that's nearly
complete rewrite of ufs/{namei,dir}.c. Frankly, I prefer the latter
variant - it's much simpler code-wise and I have that rewrite done. Since
it's local to filesystem and that filesystem is currently completely
broken... AFFS is a total fuckup on directory side. HFS... Dunno. I didn't
look deep enough. FAT and HPFS are hopefully OK, mostly because of their
lack of sparse files. However, expanding truncate() may be a problem.
Fortunately, that can be solved inside the foo_notify_change(). BFS... No
idea, that's Tigran's playground, didn't look there. QNX4 will probably
become a problem once it gets real truncate().
<evil grin>
I wonder how much of the crap fixed lately would be caught by
Reiserfs Mighty Benchmark Suite(tm) (main testing tool, according to
Hans). Could somebody take it and run on ext2 from, say it, 2.4.0-test1?
Might be interesting...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:15 EST