On Wed, Oct 30, 2013 at 6:35 PM, Mathew Snyder <mathew.sny...@gmail.com>wrote:
> I understand what you're saying. I wonder if perhaps, though, the > disconnect between your statements and that of Brandon's is the fact that > this isn't a standard "crash". This is a situation in which the drives just > go "POOF". Not something common, but certainly not unheard of. > It is in fact perhaps the only case that journaling *will* handle. Unfortunately, that is papering over that there is a lot of infrastructure not under your control that can also go wrong (ok, your network attached drives went poof. did the physical drives underneath also go poof in some way? perhaps in a way that corrupted something that shouldn't have been touched? I have heard horror stories about some of Amazon's infrastructure...). Basically, when it comes to data I am paranoid, and when it comes to infrastructure I don't control I am even more paranoid. And I strongly distrust things advertised as solving all possible problems, which is how journaling was misrepresented here. (I quote: "Journaling is designed explicitly for the purpose of eliminating the need for fsck after system crash." It doesn't *eliminate* it, it just makes many of the common failure modes less likely. Elimination requires a trusted data path between the filesystem layer and the physical media; a journal can only ameliorate, not eliminate.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
