Skip site navigation (1) Skip section navigation (2)

fsync, ext2 on Linux

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: pgsql-hackers(at)postgresql(dot)org
Subject: fsync, ext2 on Linux
Date: 2004-10-31 11:18:20
Message-ID: Pine.OSF.4.61.0410311246390.238375@kosh.hut.fi (view raw or flat)
Thread:
Lists: pgsql-hackers
The Linux fsync man page says:

"It does not necessarily ensure that the entry in the directory 
containing the file has also reached disk. For that an explicit fsync on 
the file descriptor of the directory is also needed."

AFAIK, we don't care about it at the moment. The actual behaviour depends 
on the filesystem, reiserfs and other journaling filesystems probably 
don't need the explicit fsync on the parent directory, but at least ext2 
does.

I've experimented with a user-mode-linux installation, crashing it at 
specific points. It seems that on ext2, it's possible to get the database 
in non-consistent state.

Especially:

1. start transaction
2. do a lot of updates, so that a new xlog file is created
3. commit
4. crash

Sometimes the creation of the new xlog file is lost, losing the already 
committed transaction.

I also got into this situation after one crash test:

template1=# SELECT * FROM foo;
ERROR:  could not access status of transaction 1768515945
DETAIL:  could not open file 
"/home/hlinnaka/pgsql/data_broken/pg_clog/0696": No such file or directory

I haven't tried to debug it more deeply.

Should we fix this by fsyncing the parent directory of new files? We could 
also declare ext2 broken, but there could be others.

- Heikki

Responses

pgsql-hackers by date

Next:From: Jim ButtafuocoDate: 2004-10-31 12:09:32
Subject: float4/float8 regression failure on Alpha Linux
Previous:From: Devrim GUNDUZDate: 2004-10-31 10:48:13
Subject: make check error on -HEAD

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group