gjournal & fsck

[Manolis Kiagias]

Brian McCann wrote:
> Hi all.  I'm having some problems with several servers I've built
> recently (7.0-RELEASE) that are using gjournal.  I had two reboot a
> few days ago (un-related to FreeBSD problems I think)...but when they
> came back up, the file systems wouldn't mount since they were not
> clean.  Now, I understand that UFS knows nothing about the fact that
> it's journaled, and the journaling knows nothing about UFS...but it's
> my understanding that by using gjournal, you should really never need
> to fsck a file system.  However, the only way to get them to mount is
> by doing the fsck.  Is there something else I should be doing instead
> of fsck?
>
> And since I know it will probably come up, I built the file systems
> using the instructions and notes at
> http://www.freebsd.org/cgi/man.cgi?query=gjournal&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html.
>
> Any help would be greatly appreciated!
> Thanks!
> --Brian
>
>   

You may wish to have a look at this article:

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop

In particular, you should make sure you use tunefs to enable Journaling 
and disable soft update on the journaled filesystems, i.e.:

tunefs -J enable -n disable /dev/ad0s1f.journal

Mount them using the async option:

/dev/ad0s1f.journal     /usr            ufs     rw,async        2       2

Note that the pass # still indicates the filesystem should be checked. 
While I was writing the article, I was trying several scenarios were I 
had the pass # set to 0, thinking that a gjournaled filesystem would not 
need fsck at all. I would then press the reset button. In most cases, 
the system would refuse to mount them. However with the pass # set, the 
fsck would finish almost immediately, since the actual consistency check 
takes place when the gjournal module is loaded (you will get a "journal 
consistent" after a bad reboot) and before fstab is even parsed.  All 
fsck does in this case is simply confirm to the system it is a clean volume.

In short, leaving the pass # to something that would cause an fsck is 
the safe way to go. The fsck will be almost instant anyway.