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. > > 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. - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
