From: Andi Kleen <andi@firstfloor.org>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Andi Kleen <andi@firstfloor.org>, "Theodore Ts'o" <tytso@mit.edu>,
Tahsin Erdogan <tahsin@google.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: regression: 4.13 cannot follow symlinks on some ext3 fs
Date: Fri, 24 Nov 2017 08:51:02 -0800 [thread overview]
Message-ID: <20171124165102.GS2482@two.firstfloor.org> (raw)
In-Reply-To: <C656DD8B-7521-4281-8D55-4416A3C75161@dilger.ca>
> 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
next prev parent reply other threads:[~2017-11-24 16:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-23 20:33 regression: 4.13 cannot follow symlinks on some ext3 fs Andi Kleen
2017-11-23 22:23 ` Theodore Ts'o
2017-11-23 23:31 ` Andi Kleen
2017-11-24 0:41 ` Andreas Dilger
2017-11-24 2:04 ` Andi Kleen
2017-11-24 6:12 ` Andreas Dilger
2017-11-24 16:51 ` Andi Kleen [this message]
2017-11-24 22:03 ` Andreas Dilger
2017-11-24 22:28 ` James Bottomley
2017-11-25 1:42 ` Andi Kleen
2017-11-25 22:32 ` Dave Chinner
2017-11-25 22:45 ` Reindl Harald
2017-11-25 22:57 ` Dave Chinner
2017-11-26 15:40 ` Theodore Ts'o
2017-11-26 21:14 ` Dave Chinner
2017-11-27 17:11 ` Theodore Ts'o
2017-11-28 0:42 ` Dave Chinner
2017-12-04 16:35 ` Jan Kara
2017-11-25 3:54 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171124165102.GS2482@two.firstfloor.org \
--to=andi@firstfloor.org \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tahsin@google.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).