linux-kernel - Re: EXT4 ENOSPC Bug

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-Id: <200812021847.35771.andres@anarazel.de>
Date:	Tue, 2 Dec 2008 18:47:24 +0100
From:	Andres Freund <andres@...razel.de>
To:	Theodore Tso <tytso@....edu>
Cc:	Andreas Dilger <adilger@....com>,
	LKML <linux-kernel@...r.kernel.org>, linux-ext4@...r.kernel.org
Subject: Re: EXT4 ENOSPC Bug

Hi,

On Tuesday 02 December 2008 17:47:09 Theodore Tso wrote:
> You say you are using Postgres, right?  Something you might try to see
> if it triggers the problem it is creating a new database and then
> restoring some database dump/backup into that new database.  Some
> databases expand into a new table space (or whatever terminology
> Postgres uses) by random writes into a sparse portion of the file.
> This could be triggering the problem, or at least trigger the problem
> more quickly.
I tried that - I have seen no problems so far. But it is not the first time I 
did not see the problem for some time.

Btw, postgres just creates the database by copying over a default database.

For an easy test with sparse files, I created a big one, set it up as a loop 
device, created a filesystem and ran some stuff in it.
No Problem so far.

> The other thing I wanted to ask is whether "df" was showing the 37%
> in-use statistic at the time, or was that after you rebooted. 
It definitely was before a reboot. And there were plenty of both, inodes and 
blocks.

I think that I have seen the problem on metadata only changes (find /tmp -type 
f|xargs touch) as well, but sometimes metadata changes were possible while file 
creation was not.

Another Datapoint: File deletion sometimes made it possible to create more 
files, but by far not as much as the space freed.

> And although I hate to ask it, you're sure this isn't the standard "delete
> an in-use file but not get the space back" Unix trap, right?
There were over 200GB free, so I doubt that. I don't know what could have 
caused an allocation of so much space unnoticed in an idle system multiple 
times.
But I do understand the reason for the question ;-)


Andres

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)