On Feb 21, 2008  10:40 -0600, Eric Sandeen wrote:

Ok, but my concern is what happens to those long symlinks when they
really truly are in extents format.  One option is to say "hey it was
ext4DEV, deal with it" and nuke the symlink, but if possible, converting
back to the proper format would be nice.

Is that actually the case though?  That should be pretty easy to massage
into storing a block number.  The difficulty is if the long symlink block
is beyond 32-bit blocknr, in which case it actually needs extents format.
We may as well bite the bullet and fix the code to be the same as with
htree fakeroot index block reading and use the proper mapping to find
the symlink block.  See htree_blk_iter_cb() for how to do that.

quoted

One related question is whether we want to try to get support for full
64-bit physical block numbers into ext4.  I think there were some
rough draft patches floating about, but IIRC they didn't
simultaneously support the 48-bit extent format.

I too had assumed that 48 bits would be it for now; it should be
sufficient for a good while.  I guess what I'd like to see if a usable
ext4 out there in the near future, with stuff added on later as
necessary; delalloc, flex_bg (if that doesn't make 2.6.25...) etc.

At some point 32-bit logical block numbers will also be an issue, but
the need for 16TB+ non-sparse single files is rare even in my world.

Oh, speaking of all this - what do you think the criteria are for
dropping the "dev" from ext4dev?  How do we decide that it's cooked
enough?  :)

I'd say when e2fsprogs has an official release with extents support,
and there are no show-stopping bugs in the existing code...  I don't
think that is too far off anymore.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.