Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Apr 2010 09:54:28 +1000
From:      Andrew Reilly <areilly@bigpond.net.au>
To:        freebsd-fs@freebsd.org
Subject:   gjournal: what is it good for?
Message-ID:  <20100418235428.GC4620@duncan.reilly.home>

next in thread | raw e-mail | index | archive | help
So, I've had quite a bit of yoyo-mode over the last week, caused
by the journal overflow panic that I reported in the previous
message, and I've noticed that my gjournalled file systems do
not (ever) mark themselves clean after the journal is replayed,
and so still require fsck, which takes just as long as it ever
did.

I assume that the journals have been replayed, because after
these crashes I've had to sit through screen-fulls of "Root
mount waiting for: GJOURNAL" messages, even though my root
partition is not gjournalled.  Is that assumption correct?

Even after that waiting (which has been on the order of ten
minutes or so), an attempt to mount one of my journalled
partitions results in a message like:

Warning: R/W mount of /usr denied.  Filesystem is not clean - run fsck.
mount: /dev/mirror/gm0e.journal: operation not permitted.

So: if a manual fsck is required before mounting a journalled
partition after a crash, what purpose does the journalling
serve?

Clearly I'm doing something wrong here: I've read no other
messages suggesting that gjournal is totally useless, but what?
All of my gjournal partitions have been set up according to the
examples in the man page, and the newfs operations that followed
all had the -J option, also per the man page.  They're all
mounted async, per the man page.

Here's my current df state:
Filesystem                  Size    Used   Avail Capacity  Mounted on
/dev/mirror/gm0a            2.1G    550M    1.4G    29%    /
devfs                       1.0k    1.0k      0B   100%    /dev
/dev/mirror/gm0d             10G    248M    9.3G     3%    /var
/dev/mirror/gm0e.journal    951G    296G    578G    34%    /usr
/dev/ad10s1.journal         726G    226G    442G    34%    /nb
procfs                      4.1k    4.1k      0B   100%    /proc
/dev/md0                     65M     35k     60M     0%    /tmp
/dev/ad8s1a.journal         1.5T    692G    644G    52%    /mnt
/dev/da0s1a                 969G    296G    595G    33%    /backup

and my /etc/fstab:

# Device		Mountpoint	FStype	Options		Dump	Pass#
/dev/ad4s1b		none		swap	sw		0	0
/dev/ad6s1b		none		swap	sw		0	0
/dev/mirror/gm0a	/		ufs	rw		1	1
/dev/mirror/gm0d	/var		ufs	rw		1	2
/dev/mirror/gm0e.journal /usr		ufs	rw,async	1	3
/dev/ad10s1.journal	/nb		ufs	rw,async	0	2
/dev/ad8s1a.journal	/mnt		ufs	rw,async,noauto	0	2
/dev/da0s1a		/backup		ufs	rw,async,noauto	0	2
proc			/proc		procfs	rw		0	0
#linprocfs		/compat/linux/proc linprocfs rw		0	0

(/backup used to be on a journal too, but I removed that when I
attempted to sort out the panic-on-dump problem.)

Oh: I'm running 9-current as of this weekend.

Cheers,

-- 
Andrew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100418235428.GC4620>