Re: e2fsprogs and fast symlink

[Andreas Dilger <adilger@sun.com>]

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.