Absolutely. I wrote reiserfs delayed allocation code back in october, and
kind of left it alone until the VM had the callbacks needed to make it
clean (err, less ugly). I included bunches of optimizations to
reiserfs_get_block, and the most effective one was a cache of block
pointers in the inode to avoid consecutive tree searches. This was a
locking and an i/o win, for both reading and writing (reiserfs needs this
more than ext2 does)
For growing the file, delayed allocation was a huge bonus. For all the
reasons you've already discussed, and because writing a file went from this:
(reiserfs_get_block is starting/stopping the transaction)
while(bytes_to_write)
start_transaction
allocate block
insert block pointer
end_transaction
end
To this:
while(bytes_to_write)
update counters
end
(delayed alloc routine is starting/stopping trans)
start_transaction
allocate X blocks
insert X block pointers
update counters
end_transaction
A big fat transaction is a happy one ;-)
Anyway, I'll return to the optimizations once things have settled down a
bit, and might give the generic delayed allocation (instead of reiserfs
only code) a try.
-chris
-
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/