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

[Tomohiro Kusumi]

Silent corruption isn't a filesystem issue in the first place.

If your question is about how journal works on hammer, it guarantees
consistency of the fs. It doesn't guarantee file contents. It's
similar to ordered mode of ext3, which writes file contents before
other stuff.

If your question is about delayed allocation, there is something
similar in hammer (called reservation). Not sure if anyone had a
problem with it.


2016-05-31 10:55 GMT+09:00 Steve Petrie, P.Eng. <apetrie at aspetrie.net>:
> 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
> 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
>