SU+J systems do not fsck themselves
lx at redundancy.redundancy.org
Wed Dec 28 07:34:43 UTC 2011
On Tue, Dec 27, 2011 at 11:54:20PM -0700, Scott Long wrote:
> The first run of fsck, using the journal, gives results that I would
> expect. The second run seems to imply that the fixes made on the
> first run didn't actually get written to disk. This is definitely an
> oddity. I see that you're using geli, maybe there's some strange
> side-effect there. No idea. Report as a bug, this is definitely
> undesired behavior.
Not impossible, but I was seeing similar issues on two non-geli systems
as well, i.e. tons of errors fixed when doing a single-user
non-journalled fsck, but journalled fsck not fixing stuff. I'll try to
replicate on a test machine, as I already lost data on the last
(non-geli) machine this happened to.
> For the love that is all good and holy, don't ever run fsck on a live
> filesystem. It's going to report these kinds of problems! It's
> normal; filesystem metadata updates stay cached in memory, and fsck
> bypasses that cache.
Ok. I expected fsck would be softupdate-aware in that way, but I
understand it not doing so.
> > - SU+J and fsck do not work correctly together to fix corruption on
> > boot, i.e. bgfsck isn't getting run when it should
> The point of SUJ is to eliminate the need for bgfsck. Effectively,
> they are exclusive ideas.
This is surprising to me. It is my impression that under Linux at least,
ext3fs is checked against the journal, and gets a full e2fsck if it
finds it's still dirty. Additionally, there's a periodic fsck after 180
days continuous runtime or x number of mounts (see tune2fs -i and -c).
Is SU+J somehow implemented in such a way that this is unnecessary? What
does it do that the ext3fs people have missed?
More information about the freebsd-current