Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 09 Mar 2011 12:52:31 +0000
From:      Hugo Silva <hugo@barafranca.com>
To:        freebsd-geom@freebsd.org
Subject:   Cannot create gjournal on gmirror partition - 8.2-RELEASE: "No such file or directory"
Message-ID:  <4D77780F.8020209@barafranca.com>

next in thread | raw e-mail | index | archive | help
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.



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