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. > > 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. - 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
