On Nov 21, 2016, at 4:19 PM, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Fri, Nov 18, 2016 at 02:52:22PM -0700, Andreas Dilger wrote: >> >>> Yes, this would be a much nicer way to detect fast symlinks. >>> >>> The only thing I'd be concerned about is the possibility of pre-existing >>> "slow" symlinks that actually have targets short enough to be "fast" >>> symlinks, perhaps in filesystems created by old drivers or by external >>> tools. If such links happened to work before, then a change to check >>> i_size would break them. >>> >>> This may not be an issue in practice. I checked some old ext4 versions, >>> ext2 from Linux 0.99.7, e2fsprogs, Android's ext4_utils, and FreeBSD's >>> ext2 driver. They all create "fast" symlinks if the length of the >>> symlink target length excluding the terminating null (i_size) is < 60. >> >> I did a similar analysis with similar results. >> > > Ted, what would you say about Andreas' suggestion to use i_size to > distinguish fast symlinks from slow symlinks? > > It looks like this was discussed some years ago but the discussion died > out and no change was made: see https://www.spinics.net/lists/linux-ext4/msg05693.html > > Given the investigation I did it seems it would very likely be safe, but > we can never be 100% sure it won't break some obscure tool or (version of > a tool) to create symlinks on ext2/ext3/ext4 filesystems we don't know > about. Conversely, we've had fast symlinks break a few times due to additional blocks being stored with the fast symlink (external xattr blocks for SELinux, now encryption), possibly others in the future, and such breakages are backwards incompatible (i.e. if there is some new way to add a block to a symlink it will break all older kernels). Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
