Messages in this thread | | | From | Andres Freund <> | Subject | Re: EXT4 ENOSPC Bug | Date | Tue, 2 Dec 2008 18:47:24 +0100 |
| |
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 [unhandled content-type:application/pgp-signature] | |