On Oct 14, 2013, at 11:33 AM, CeDeROM <cede...@tlen.pl> wrote: > On Mon, Oct 14, 2013 at 7:54 PM, Bruce Cran <br...@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 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"