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 description. > 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. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx