From: Andi Kleen Subject: Re: regression: 4.13 cannot follow symlinks on some ext3 fs Date: Fri, 24 Nov 2017 08:51:02 -0800 Message-ID: <20171124165102.GS2482@two.firstfloor.org> References: <20171123203330.GN2482@two.firstfloor.org> <20171123222317.bq2v26zm5i2jspui@thunk.org> <20171123233101.GP2482@two.firstfloor.org> <700971AC-BDE2-4993-BD56-7497AD8A0FC4@dilger.ca> <20171124020435.GQ2482@two.firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andi Kleen , Theodore Ts'o , Tahsin Erdogan , Linux Kernel Mailing List , linux-fsdevel , linux-ext4 To: Andreas Dilger Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org > We checked old kernels, and old e2fsprogs, and didn't see any cases > where fast (<= 60 chars) symlinks were created using external blocks. > It seems that _something_ did create them, and it would be good to > figure that out so we can determine if it is a widespread problem I assume it was the original kernel. > > I think e2fsck can fix this quite easily, and there really isn't > an easy way to revert to the old method if the large xattr feature > is enabled. If you are willing to run a new kernel, you should also > be willing to run a new e2fsck. It's obviously not enabled on ext3. > > We could probably add a fallback to the old mechanism (and print > a one-time warning to upgrade to a newer e2fsck) if an external fast > symlink is found and the large xattr feature is not enabled, which > would give more time to fix this (hopefully rare in the wild) case. If the old kernel created it, then likely all the /lib{,64}/ld-linux.so.2 symlinks have that, which breaks all ELF executables. I suspect in these old file systems it's not particularly rare. So I don't think you can just break them all. I think it's ok to only handle it when the large xattrs are disabled. Requiring new e2fsck on old systems is a bad idea. -Andi