Good afternoon,
We're setting up a new backup server and in an effort to reduce fsck
times and system unresponsiveness during bgfsck, gjournal is being
considered.
Presently the machine is booting off a gmirror, at disk-level:
Name Status Components
mirror/gm0 DEGRADED ad12
ad16 (33%)
gm0s1h is a 1.4T partition - the one causing the unacceptable delays on
unclean shutdowns.
While attempting to create a gjournal there:
# gjournal label /dev/mirror/gm0s1h
gjournal: Cannot clear metadata on /dev/mirror/gm0s1h: No such file or
directory.
# stat /dev/mirror/gm0s1h
33619712 98 crw-r----- 1 root operator 98 0 "Mar 9 12:42:06 2011" "Mar
9 12:42:06 2011" "Mar 9 12:42:06 2011" "Dec 31 23:59:59 1969" 4096 0
0 /dev/mirror/gm0s1h
Creating a gjournal on a improvised md0 device worked; Memory might be
failing me, but the above used to work?
My only alternative theory is that i thas something to do with the
mirror syncing, but that looks like a long shot. And it won't be synced
for another 5 hours.
Another thing: We've noticed that system becomes very unresponsive
(running programs that haven't been run before will take up to 20
seconds, for example - presumably while reading the binary image into
memory) while bgfsck is running on that big partition. However, the same
doesn't happen while gmirror is syncing, at 80MB/s. Does anyone know why
one operation (fsck on huge partition) impacts the systems performance
so much, while another (gmirror sync) does not?
It is my understanding that the symptoms presented (programs whose image
has not been cached taking a lot of time to load, also shell tab
completion taking noticeably more time) should also be present if the
explanation was simply the disk being used to full capacity. And this
also happens with gmirror sync.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "[email protected]"
