On Feb 22, 2008  19:15 -0500, Theodore Ts'o wrote:

So before the recent patch were we actually creating long symlinks in
extents format?  Or were we just setting the flag but still treating
them as a block number?  If it was the latter, I guess we can put in
code into e2fsck to detect that case, and convert it back to a
singleton block number.  

Eric informed me that the long symlinks were actually stored in extent
mapped blocks.  That is not harmful, because it can only be a single
block and it will always fit into the inode.  The other thing to note
is that extent mapping is REQUIRED for > 32-bit blocknumbers, so we
may as well fix e2fsprogs to allow these symlinks to be handled normally.

quoted

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.

I guess I'd be a *bit* more cautious.  We still have some code patches
such as the delayed allocation and to a lesser extent the online
defrag patches which have the possibility of introducing bugs.  Once
all of those get merged and we have a full kernel release cycle to fix
the last remaining bugs, that's when I would drop the -dev from the
name.

Well, there isn't any hard requirement to include delalloc into the
first non-dev ext4 release.  Yes, it would be desirable, but I don't
think we HAVE to have it.  I think the important thing is that the
on-disk format is no longer changing.

One thing that still needs to be done (AFAIK) is the removal of the
"auto-setting" of filesystem feature flags, and allow tune2fs/e2fsck
to set/leave the flags that we currently set automatically.  I'd
hazard that for feature flags which have been around a LONG time (like
EAs and LARGEFILE) that these should be enabled by default.

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