I agree, but I didn't have his address at hand.
I thought at first emailing Stephen and you about this, but
then just emailed the list.
...
> Of course, for the ultimate in performance gain, you would have
> to change the on-disk format, and the way to do this compatibly would be
> to use an ext2 inode flag to designate whether an inode is using the old
> format or the new format. As you noted, for sparse files, for obvious
> reasons the old format is superior.
Quite so. I am coding my test "ext2e" module with most of these
ideas. Including ioctl()ed flag per file.
(I need unchanged "ext2" to boot and run my laptop, and to be safe
way to back off -- except that I need to alter the super-block
of my test partition, by adding "incompatible feature flag",
I think.)
> In fact, for a first-cut implementation, it might make sense to
> make a kernel which only creates files in the new format assuming that
> the entries all fit in i_blocks, and immediately converts things to the
> old format once that assumption is violated.
I would like to support files spanning more than 5 inode groups,
that is, very large files... But yes, for the first-cut that
might make sense.
Also the first lseek() causing creation of hole could cause
format conversion to the old format. Now I have written
code to auto-fill any such holes, but to trigger that format
conversion might make sense -- perhaps with some treshold,
though. (Or perhaps another flag telling: always fill the
holes/stay at contiguous block-group descriptors.)
Your e2fsck and friends will need changes too. Without support
from those, the test will soon be doomed to data loss..
> - Ted
/Matti Aarnio