Hammer Filesystem -- Any known issues with failures (e.g. due to server power loss) forcing to zero-length a non-zero-length file?

Steve Petrie, P.Eng. apetrie at aspetrie.net
Mon May 30 18:55:52 PDT 2016

Greetings To DragonFlyBSD List,

This is a precautionary query, as I am planning to use the PostgreSQL 
(PG) database server for a new website application (not yet online) to 
run using the Hammer filesystem under DragonFlyBSD.

* * *
* * *

There is currently an interesting discussion thread active on the PG 
mailing list pgsql-general at postgresql.org that describes how PG has an 
exposure to silent data loss.

Thread started on 30 May 2016, subject "[GENERAL] Silent data loss in 
its pure form";

Apparently, PG is incapable of detecting data loss, caused by a problem 
in a filesystem that, after a power failure, either erroneously (RHEL 
XFS, bug fixed in 2012) or by design (ext4, delayed file allocation) 
incorrectly wipes files to zero length after a power loss.

Here are links to descriptions of the underlying problems in the 



Even the optional built-in PG checksumming protection against data 
corruption, does not detect this catastrophic silent data data loss. 
Although there are apparently clues about this otherwise silent data 
loss, written to a PG log file, should the PG DBA be lucky enough to be 
an obsessive reviewer of PG log files.

Apparently the root of this PG vulnerability, is that PG writes no 
header to to a newly-initialized data file, so a zero-length file is 
taken to be a legitimate newly-initialized data file, even if its 
zero-length was caused by some problem in the underlying filesystem, 
that effectively destroyed all active data in the file.

* * *
* * *

So, my question to the DragonFlyBSD / Hammer experts is, are there any 
known issues with the Hammer filesystem erroneously forcing a file to 
zero-length, issues that a user of PostgreSQL running under 
DragonFlyBSD, needs to know about?

Thanks for any comments,


More information about the Users mailing list