On Mar 24, 2008 17:26 -0400, Theodore Ts'o wrote: > On Mon, Mar 24, 2008 at 02:45:10PM -0600, Andreas Dilger wrote: > > Instead I propose that we just use the i_size itself to determine if > > there is a fast symlink, because there has never (AFAIK) been a kernel > > that created slow symlinks for files < 60 bytes in length. > > I have a vague memory that at one point (along time ago, over ten > years ago) there were slow symlinks where the target was < 60 bytes. Hmm, I don't recall this, but it seems possible. As far back as 2.2 kernels I checked this wasn't the case, I haven't looked back further. > And the kernel has always determined whether or not a symlink was fast > or slow by looking i_blocks. (See ext3_inode_is_fast_symlink() in > fs/ext3/inode.c). Sure, but that doesn't mean it is the best way... > In retrospect, the true clean way to do this would have been an > explicit i_flags bitfield. One thing we could do is make a change > into ext4 (and ext3) so that we silently set an EXT3_SLOW_LINK_FL and > EXT3_FAST_LINK_FL, and if neither is set, we fall back to a hueristic > involving i_blocks. This gives e2fsck one more bit of redundancy to > make sure it notices problems and to make sure it gets things right. > I'm not sure it's worth it, but eventually it would allow us to clean > things up. Since it is impossible to have a fast symlink with > 60 bytes of data it seems reasonable to only flag slow symlinks explicitly. The unusual, but theoretically possible, case would be slow symlinks <= 60 bytes, so we may as well flag all slow symlinks and assume fast symlinks for others. I don't think there are a huge number of available flags left (12 or less) so we can't use them without good reason. Hmm, that brings up a question as I look at the used flags in 2.6.24 - did the HUGE_FILE support make it into the ext4 upstream? 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
