SU+J Lost files after a power failure

Charles Swiger cswiger at
Mon Oct 14 18:48:28 UTC 2013

On Oct 14, 2013, at 11:33 AM, CeDeROM <cederom at> wrote:
> On Mon, Oct 14, 2013 at 7:54 PM, Bruce Cran <bruce at> wrote:
>> On 10/14/2013 6:16 PM, CeDeROM wrote:
>>> Isn't there Journal to prevent and reverse such damage?
>> Unlike other journaling filesystems, UFS+J only protects the metadata, not
>> the data itself - i.e. I think it ensures you won't have to run a manual
>> fsck, but just like plain old UFS files may be truncated as the journal is
>> replayed.
> Thank you for explaining :-) So it looks that it would be sensible to
> force filesystem check every n-th mount..?

You shouldn't ever need to recheck the filesystem if it was shutdown cleanly.

However, it doesn't hurt to fire off an fsck once a year or so just to look for
any unexpected issues.

> Or to do a filesystem check after crash..?

Yes.  Without journalling, you'd normally perform the full timeconsuming fsck
in the foreground.  With journalling, it should be able to do a journal replay 
to restore the filesystem to an OK state, but sometimes that doesn't restore
consistency, in which case it usually fires off a background fsck rather than
the foreground fsck.

> Are there any flags like that to mark filesystem
> unclean and to force fsck after n-th mount? That would assume
> disabling journal and soft updates journaling I guess..?

/etc/rc.conf should support something like the following to do what you ask:


> What would be the best option for best data integrity in case of
> crash? That would be helpful for development systems I guess :-)

Well, you can use mount -o sync and disable write caching via hw.ata.wc=0 or
similar depending on what kind of drives you use.

This will cause a massive loss of write performance, but will greatly improve
reliability-- i.e. fsync() and such are not as likely to lie about whether bits
have made it to disk, even in the face of hardware which lies about ATA_FLUSHCACHE


More information about the freebsd-questions mailing list