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: 21+ 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-26 21:35 ` Reindl Harald
2017-11-26 22:43 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.