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 [email protected] 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
filesystems:
XFS
https://bugzilla.redhat.com/show_bug.cgi?id=845233
ext4
http://www.pointsoftware.ch/en/4-ext4-vs-ext3-filesystem-and-why-delayed-allocation-is-bad/
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,
Steve
