SU+J Lost files after a power failure

[Charles Swiger]

On Oct 14, 2013, at 11:33 AM, CeDeROM <cederom at tlen.pl> wrote:
> On Mon, Oct 14, 2013 at 7:54 PM, Bruce Cran <bruce at cran.org.uk> 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:

fsck_y_enable="YES"
background_fsck="NO"
force_fsck="YES"

> 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
(or SCSI "SYNCHRONIZE CACHE", etc).

Regards,
-- 
-Chuck