SU+J systems do not fsck themselves

[David Thiel]

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?