gjournal & fsck

[Pawel Jakub Dawidek]

On Thu, Aug 28, 2008 at 05:44:32PM +0300, Manolis Kiagias wrote:
> 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.

Not exactly. Gjournal handles all inconsistencies, except one - orphaned
files. An orphaned file is a file that some open, deleted, but haven't
closed. If you have panic or power failure at this point, there will be
unreferenced file. When fsck detects that it operates on gjournaled file
system, it will do a very fast lookup of such orphaned files. It is
optimized so that total number of such files is kept in superblock - if
this counter is 0, we're done. If it is not zero, then fsck scans only
cylinder groups headers, there is another counter in each header says
how many orphaned files is in this CG. If CG's counter is 0, the whole
CG can be skipped. Once we found X dirty CGs (X is stored in superblock)
we can also stop earlier. All in all, there are very few such files (if
any), so fsck is way, way faster with gjournal (eg. ~1 minute instead of
~8 hours on huge file system).

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20080828/00338729/attachment.pgp