Re: [RFC][PATCH] ext4: handle fast symlink properly with inline_data

[Ian Nartowicz <ian@nartowicz.co.uk>]

On Mon, 2 Jun 2014 14:42:51 +0800
Zheng Liu <gnehzuil.liu@gmail.com> wrote:

>Hi all,
>
>On Fri, May 30, 2014 at 04:26:33PM -0700, Darrick J. Wong wrote:
>> On Tue, Feb 18, 2014 at 11:07:24AM -0800, Andreas Dilger wrote:
>> > I suspect that the stats for symlinks > 60 but < ~150 chars is only a very
>> > small fraction of files. If the code complexity of handling this is very
>> > small (i.e. it is just handled as a natural consequence of writing "data" 
>> > of this size) then I would be OK with it. 
>> > 
>> > Otherwise, I expect the code and maintenance overhead of supporting
>> > the 0.01% (?) of symlinks that are this size is probably lot worth it. 
>> > 
>> > People could check what the actual usage is via the "fsstats" tool at:
>> > 
>> > http://www.pdsi-scidac.org/fsstats/
>> > 
>> > There is also data there already that reports stats on symlink length, but
>> > it is mostly HPC filesystems and it might be better to redo this with a
>> > desktop-type workload. 
>> 
>> I think we should either put in this kernel patch so that we can read inline
>> data fast symlinks, or remove the ability to write inline data fast symlinks.
>> It's a bit surprising that I can do:
>> 
>> # mke2fs -t ext4 -O inline_data /dev/sdb         
>> # mount /dev/sdb /mnt/
>> # ln -s "Fuzzy Wuzzy was a bear. Fuzzy Wuzzy had no hair. I guess he wasn't
>> fuzzy, was he?" /mnt/biglink # readlink /mnt/biglink
>> Fuzzy Wuzzy was a bear. Fuzzy Wuzzy had no hair. I guess he wasn't fuzzy,
>> was he? # umount /mnt
>> # mount /dev/sdb /mnt/
>> # readlink /mnt/biglink
>> Fuzzy Wuzzy was a bear. Fuzzy Wuzzy had no hair. I guess he
>> 
>> What happened to the punchline of the limerick? ------------^^^^^^^ ???? :)
>
>Do *not* apply this patch, please.  I revise this patch and I think it
>is not right solution, although it can fix the bug.
>
>The root cause is in ext4_inode_is_fast_symlink() function that it
>doesn't check whether or not an inode has inline data.  After creating
>a normal symlink, the symlink will be stored in ->i_block and extra
>space if the length of symlink is greater than 60 bytes and less than
>extra space in inline data.  In the mean time, this inode has inline
>data flag.  If the file system is remounted, ext4_inode_is_fast_symlink
>thinks this inode is a fast symlink, and the data in ->i_block is copied
>to user.  I will send a new patch to fix this bug.
>
>> 
>> e2fsck still seems to think that you can't have inline_data fast symlinks.  I
>> don't see a downside to continuing to allow them.
>
>Meanwhile another patch for e2fsck also will be sent out soon in order
>to handle symlink properly with inline data in e2fsck.
>
>Regards,
>                                                - Zheng

fsstats on root on my desktop, percentage of symlink targets 64 - 150
characters long is 22%, almost all in the 64-71 char bucket.  Lots of them are
theme icons and python packages, some shared library objects, nothing that
many people won't have.

--ian