Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Oct 2013 18:34:36 +0200
From:      David Demelier <>
Subject:   Re: SU+J Lost files after a power failure
Message-ID:  <>
In-Reply-To: <>
References:  <>	<l3gc7e$c91$> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On 14.10.2013 14:39, RW wrote:
> On Mon, 14 Oct 2013 05:02:22 -0400
> Michael Powell wrote:
>> David Demelier wrote:
>>> Hello there,
>>> I'm writing because after a power failure I was unable to log in on
>>> my FreeBSD 9.2-RELEASE. The SU+J journal were executed correctly
>>> but some files disappeared, including /etc/pwd.db. Thus I was
>>> unable to log in.
>>> I've been able to regenerate the password database with a live cd
>>> but I'm afraid that more files had disappeared somewhere else...
>>> I think this is a serious issue, the journal should not truncate
>>> files, so something should have gone wrong somewhere..
> The journalling in  SU+J has nothing to do with data integrity.
> When the system isn't shut-down cleanly, soft-updates are supposed to
> leave the filesystem in a self-consistent state, except that it may
> lose track of some freed disk space. The journal allows that space to
> be recovered without the lengthy background fsck that used to cripple
> performance.
> If you are having problems with data integrity you might try gjournal or
> zfs instead.

Why? SU+J is enabled by default. Isn't the purpose of a journaled file
system to ensure that any bad shutdown will protect data?

On GNU/Linux, on Windows you will not require anything else to recover
your data.

I don't want to tweak the filesystem or use something different that the
default, as it is the default it's the *warranty* that it is the correct
way to protect data for new FreeBSD user's installations IMHO.

> If you look back at the lists before these were added
> there was a lot of suspicion about soft-updates and background checks.
> Some of the problems were explained by some (mostly desktop) drives
> incorrecty reporting what has been commited to disk - I don't know
> whether this is still the case.
>> This error about the replay of the journal(s) failing is somewhat 
>> disconcerting. 
> I think this is probably a good thing. With background checks you would
> (if you were looking) occasionally see "unexpected soft-update
> inconsistency" during the background check, which would lead to a
> foreground check on the next boot.
> _______________________________________________
> mailing list
> To unsubscribe, send any mail to ""

Want to link to this message? Use this URL: <>