From owner-freebsd-questions@FreeBSD.ORG Mon Oct 14 21:04:54 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 CD8FD7EE for ; Mon, 14 Oct 2013 21:04:54 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out.apple.com (mail-out.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 AFAA42833 for ; Mon, 14 Oct 2013 21:04:54 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay3.apple.com ([17.128.113.83]) 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 <0MUO00IHDFVAGFH1@mail-out.apple.com> for freebsd-questions@freebsd.org; Mon, 14 Oct 2013 14:04:42 -0700 (PDT) X-AuditID: 11807153-b7fa56d000007d7a-93-525c5c6a3e26 Received: from [17.153.100.31] (Unknown_Domain [17.153.100.31]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 73.72.32122.A6C5C525; Mon, 14 Oct 2013 14:04:42 -0700 (PDT) Subject: Re: SU+J Lost files after a power failure From: Charles Swiger In-reply-to: Date: Mon, 14 Oct 2013 14:04:45 -0700 Message-id: <2351E8C5-4FC0-4AE9-AC21-312DA46C0EE8@mac.com> References: <525A6831.5070402@gmail.com> <20131014133953.58f74659@gumby.homeunix.com> <525C1D1C.9050708@gmail.com> <525C2554.7080203@pchotshots.com> <525C2FBC.4080808@cran.org.uk> To: Daniel Feenberg X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUiODNFXjcrJibIYMkaLYvZp5ewWLz8uonF gcljxqf5LB4Hdj1kCmCK4rJJSc3JLEst0rdL4MqYtvILc8FT/oozm24zNjBe5Oli5OSQEDCR aD/bwgphi0lcuLeerYuRi0NIoJdJ4vjJJewgCWYBLYkb/14ydTFycPAK6Els/yUHEhYWMJK4 smcFK0iYTUBNYsJEsJGcAtYSCzf/AetkEVCV2LRnDivEFFOJ7x0PmSFsbYllC1+D2bwCVhLv jr6CWnuOWeLg+TlMIAkRAXWJvkN/mCBuk5U4fe45ywRG/llILpqFcNEsJGMXMDKvYhQoSs1J rDTWSywoyEnVS87P3cQICriGwuAdjH+WWR1iFOBgVOLh/ckbEyTEmlhWXJl7iFGCg1lJhDf3 bXSQEG9KYmVValF+fFFpTmrxIUZpDhYlcd41XkDVAumJJanZqakFqUUwWSYOTqkGRkP2FW62 1ZtTVX/MNG93+2//3Uelmv/w1PtMzyuk7PJX5m3nUBFfs1F3Hdv1D39m8d5wO2zF/nfx/SnC AofUc/p4i9cfqPhn4rHrjlSy7ORXReI3UlIXZC+3aFVcs+2XZ/JhPnfp3zKPe7YEP9tvp5gY FbN4fZZ/le1x680hOSVb3Ip+hN/oV2Ipzkg01GIuKk4EADte6Hw0AgAA 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 21:04:55 -0000 Hi-- On Oct 14, 2013, at 11:51 AM, Daniel Feenberg wrote: > This discussion skirts the critical issue - are files that are not open for writing endangered? No description of the uses of journaling can be considered informative if it doesn't address that explicitly. As a naive user I have always assumed that once closed, a file was invulnerable to improper shutdowns, but this discussion shakes that belief. Well, it's good to be a little paranoid if the data matters. :-) First, unless you call fsync() before close() and your OS and/or drive hardware isn't being deceptive when fsync() returns about whether the bits have made it to permanent storage, then you might be surprised at just how long the unwritten buffers containing the last updates to the file data take to get properly flushed to disk. > I expect the answer may be different for SSD and spinning disks. Second, this is an excellent point: however, it also applies to anything where the actual hardware block size does not match the device blocksize that the filesystem thinks it has-- so new "4K sector" rotational disks also have some risk. The basic issue with SSDs is that you (or the drive firmware, more precisely) need to read in an entire hardware sector, update the portion with changes in cache memory, do a bulk-erase of that block, and then scribble that back out. Good drive firmware actually writes out to a different block than the original for wear-leveling purposes and only updates the flash translation layer once the new version of that block is written. That makes the drive mostly immune to major data integrity issues even if powered off in the middle of the process. Less-than-good firmware, aka buggy firmware, can lead from power-failure to data loss of files which were not being modified at the time. And may you possess recent working backups if the FTL somehow ever gets confused! Regards, -- -Chuck