SU+J systems do not fsck themselves

[David Thiel]

On Tue, Dec 27, 2011 at 02:48:22PM -0800, Xin Li wrote:
> >> - use journalled fsck; - use normal fsck to check if the
> >> journalled fsck did the right thing.

Ok, here is the log of fsck with and without journal.

http://redundancy.redundancy.org/fscklog3

That was done the very next boot, after a clean shutdown. The errors 
from the previous live fsck aren't there (oddly), but there are still 
are apparently some corrections made. The next fsck still complains, but 
doesn't give any salvage prompts.

Here is jsa@'s, done on a live FS with SU+J:

http://redundancy.redundancy.org/fscklog4

I'm not actually looking to solve my particular problem per se. The 
issue is that almost everyone I've checked with that's running SU+J gets 
unref'd file and other errors when they check their filesystem (with the 
fs live). Unless I'm missing something, a running FS should never have 
those kinds of errors unless you deliberately disabled fsck.

This leaves only a couple options:

- SU+J and fsck do not work correctly together to fix corruption on 
  boot, i.e. bgfsck isn't getting run when it should
- Stuff is getting completely screwed up after boot
- fsck is giving incorrect results
- I'm completely clueless about how SU+J is supposed to behave or be 
  deployed

I'm pretty certain that the first is the issue here. It would be great 
if others could check their own SU+J filesystems so we could get a few 
more data points.