From owner-freebsd-questions@FreeBSD.ORG Mon Oct 14 18:48:28 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 15F17BD5 for ; Mon, 14 Oct 2013 18:48:28 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EDD732E4A for ; Mon, 14 Oct 2013 18:48:27 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MUO00I3I9ITGF61@mail-out.apple.com> for freebsd-questions@freebsd.org; Mon, 14 Oct 2013 11:48:15 -0700 (PDT) X-AuditID: 1180715a-b7fdb6d000004dc1-57-525c3c6e5a5d Received: from [17.153.18.19] (Unknown_Domain [17.153.18.19]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id BE.77.19905.F6C3C525; Mon, 14 Oct 2013 11:48:15 -0700 (PDT) Subject: Re: SU+J Lost files after a power failure From: Charles Swiger In-reply-to: Date: Mon, 14 Oct 2013 11:48:18 -0700 Message-id: References: <525A6831.5070402@gmail.com> <20131014133953.58f74659@gumby.homeunix.com> <525C1D1C.9050708@gmail.com> <525C2554.7080203@pchotshots.com> <525C2FBC.4080808@cran.org.uk> To: CeDeROM X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUiOFNIWDffJibIYGULk8WembPYLF5+3cTi wOQx49N8Fo97SzoYA5iiuGxSUnMyy1KL9O0SuDIezm9hKnglUNHWv4ixgXEdbxcjB4eEgInE kp9iXYycQKaYxIV769m6GLk4hAS6mSR+rbjBCpJgFtCSuPHvJRNIPa+AnsT2X3IgYWEBI4kr e1awgoTZBNQkJkzkAQlzCgRKbPj0mAnEZhFQlbjx8g0LxBRTie8dD5khbG2JZQtfg9m8AlYS 1xZtZYdY+4RZYv+bb2ANIgKyEn0XL7BD3CYrcfrcc5YJjPyzkFw0C+GiWUjGLmBkXsUoUJSa k1hpppdYUJCTqpecn7uJERRuDYVROxgbllsdYhTgYFTi4f3BGxMkxJpYVlyZe4hRgoNZSYQ3 9210kBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeCXWgaoH0xJLU7NTUgtQimCwTB6dUA2PU7+Ur FiWqu/r9zXQ+fbPXwinxbvmJmV7dba+TXxQ+NppZPXXnpc+WKzfF9AVkVTdIzJL6dnm5gk7s q+re1ReZzyxcrJzd+tFHxW/5Dz/XSeE+UlIMO7RVnn39Njnj8bxZ85kXutxOfRU2y6CwLEci +fBO7dL113pmH1K++r44IerkN6bFWkeVWIozEg21mIuKEwHPQ37+MwIAAA== Cc: FreeBSD Questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 18:48:28 -0000 On Oct 14, 2013, at 11:33 AM, CeDeROM wrote: > On Mon, Oct 14, 2013 at 7:54 PM, Bruce Cran 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