gjournal & fsck
Manolis Kiagias
sonic2000gr at gmail.com
Thu Aug 28 14:44:37 UTC 2008
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.
More information about the freebsd-questions
mailing list