On Fri 24-11-17 15:03:37, Andreas Dilger wrote:
> On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote:
> >
> >> 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,
On Mon, Nov 27, 2017 at 12:11:26PM -0500, Theodore Ts'o wrote:
> On Mon, Nov 27, 2017 at 08:14:27AM +1100, Dave Chinner wrote:
> > Of course. I've done that every time I've come acros these sorts of
> > problems.
>
> The most recent report I was able to find was against 4.7-rc6, in July
> 2016. H
On Mon, Nov 27, 2017 at 08:14:27AM +1100, Dave Chinner wrote:
> Of course. I've done that every time I've come acros these sorts of
> problems.
The most recent report I was able to find was against 4.7-rc6, in July
2016. Have you been able to reproduce it more recently than that?
Cheers,
On Sun, Nov 26, 2017 at 10:40:26AM -0500, Theodore Ts'o wrote:
> On Sun, Nov 26, 2017 at 09:32:02AM +1100, Dave Chinner wrote:
> >
> > They don't have any whacky symlinks around, but the modern ext4 code
> > does try to eat these filesystems every so often. Extended operation
> > at ENOSPC will ev
On Sun, Nov 26, 2017 at 09:32:02AM +1100, Dave Chinner wrote:
>
> They don't have any whacky symlinks around, but the modern ext4 code
> does try to eat these filesystems every so often. Extended operation
> at ENOSPC will eventually corrupt the rootfs and crash the kernel,
> and then I play the "
Am 25.11.2017 um 23:32 schrieb Dave Chinner:
On Fri, Nov 24, 2017 at 03:03:37PM -0700, Andreas Dilger wrote:
Any worse an idea than running a new kernel on an old system?
Newer e2fsck fixes a lot of bugs that are present in older
e2fsck as well...
I'm running with everything up to date (debia
On Sat, Nov 25, 2017 at 11:45:07PM +0100, Reindl Harald wrote:
>
> Am 25.11.2017 um 23:32 schrieb Dave Chinner:
> >On Fri, Nov 24, 2017 at 03:03:37PM -0700, Andreas Dilger wrote:
> >>Any worse an idea than running a new kernel on an old system?
> >>Newer e2fsck fixes a lot of bugs that are present
On Fri, Nov 24, 2017 at 03:03:37PM -0700, Andreas Dilger wrote:
> On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote:
> >
> >> 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_ d
On Fri, Nov 24, 2017 at 08:51:02AM -0800, Andi Kleen wrote:
> > 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 ne
> Sure, but not many people are going to be running a 4.14 kernel with
> a 2007 system.
It's not just root, but any disk. People could well have 10 year old
disks.
> Could you please run the updated find command to see
> whether this is an isolated case, or if it is a common case:
>
> find / -
On Fri, 2017-11-24 at 15:03 -0700, Andreas Dilger wrote:
> On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote:
> >
> >
> > >
> > > We checked old kernels, and old e2fsprogs, and didn't see any
> > > cases
> > > where fast (<= 60 chars) symlinks were created using external
> > > blocks.
> > > It seem
On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote:
>
>> 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 deter
> 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
On Nov 23, 2017, at 7:04 PM, Andi Kleen wrote:
>
>> As a workaround, you could delete and recreate the symlink with the new
>
> I revert the patch for now. Everything seems to work.
>
>> kernel to create a proper fast symlink. It would be useful to scan
>> the image to see if there are other s
> As a workaround, you could delete and recreate the symlink with the new
I revert the patch for now. Everything seems to work.
> kernel to create a proper fast symlink. It would be useful to scan the
> image to see if there are other similar symlinks present:
>
> find /myth/tmp -type l -si
On Nov 23, 2017, at 4:31 PM, Andi Kleen wrote:
>
> On Thu, Nov 23, 2017 at 05:23:17PM -0500, Theodore Ts'o wrote:
>> On Thu, Nov 23, 2017 at 12:33:30PM -0800, Andi Kleen wrote:
>>>
>>> I have an older qemu VM image that i sometimes use for testing. It
>>> stopped booting with 4.13-4.14 because i
On Thu, Nov 23, 2017 at 05:23:17PM -0500, Theodore Ts'o wrote:
> On Thu, Nov 23, 2017 at 12:33:30PM -0800, Andi Kleen wrote:
> >
> > I have an older qemu VM image that i sometimes use for testing. It
> > stopped booting with 4.13-4.14 because it couldn't run init.
> > It uses ext3 for the root f
On Thu, Nov 23, 2017 at 12:33:30PM -0800, Andi Kleen wrote:
>
> I have an older qemu VM image that i sometimes use for testing. It
> stopped booting with 4.13-4.14 because it couldn't run init.
> It uses ext3 for the root file system.
Hmm, do you know roughly when (what krenel version) this ima
18 matches
Mail list logo
