lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 27 Nov 2017 09:43:24 +1100
From:   Dave Chinner <>
To:     Reindl Harald <>
Cc:     linux-ext4 <>
Subject: Re: regression: 4.13 cannot follow symlinks on some ext3 fs

On Sun, Nov 26, 2017 at 10:35:08PM +0100, Reindl Harald wrote:
> Am 26.11.2017 um 22:14 schrieb Dave Chinner:
> >On Sun, Nov 26, 2017 at 10:40:26AM -0500, Theodore Ts'o wrote:
> >>Are you
> >>running some benchmarks that are logging into the root, and that's
> >>triggering the ENOSPC condition?
> >
> >No, I'm not doing anything like that on these machines. It's
> >straight forward "something filled the root fs unexpectedly" type of
> >error which I don't notice immediately...
> have you ever considered to just buy larger disks or introduce quota
> because "Unlike ext3, ext4 is not a filesystem that takes kindly to
> being abused by an environment that involves machines being crashed,
> oopsed and forcibly rebooted without warning tens of times a day"

That's my normal production workload, been doing it successfully
on ext3 root filesystems for more than 10 years. This causes very
few problems for ext3 filesystems, but it causes real problems for
ext4 filesystems.

> caused by a full root fs

I don't think you've quite understood: a) I don't run my root
filesystems at ENOSPC (it's a rare event), and b) crashing kernels
and abusing filesystems is the one-line summary of my job

> is anyhting but a reasonable workload and i
> doubt any filesystem is intended to run under such abused
> environment

Intended or not, we have to make filesystems robust in such
environments because that's the sort of abuse we see in production
environments. Users *expect* filesystems to handle crashes, ENOSPC,
etc conditions without losing data or corrupting themselves. 

If filesystem developers aren't abusing their filesystems and
attempting to break them into little pieces and put them back
together again, then they aren't doing their jobs properly.


Dave Chinner

Powered by blists - more mailing lists