misc/144943: gconcat randomly "loses" all knowledge of JBOD set
freebspr at sensation.net.au
Sun Mar 21 23:50:06 UTC 2010
>Synopsis: gconcat randomly "loses" all knowledge of JBOD set
>Arrival-Date: Sun Mar 21 23:50:05 UTC 2010
>Originator: Rowan Crowe
>Release: 6.3-RELEASE i386
FreeBSD ******.sensation.net.au 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Aug 20 02:13:07 EST 2008 rowan@******.sensation.net.au:/usr/src/sys/i386/compile/VID62R i386
I've recently had a few "events" where gconcat seems to have disowned the drives in a set. For example, I just inserted two drives, powered on, then at boot there's no mention of GCONCAT at all. It's in memory - via loader.conf - but it doesn't recognise the disks as belonging to a gconcat set.
I can restore access to the data if I manually recreate the array, but I'm very concerned that it seems to be deliberately disconnecting drives (and possibly updating their metadata?) for some reason.
# gconcat list
[there is no list output, ie no sets are recognised]
# gconcat create -v permdocs ad3 ad1
# geli attach /dev/concat/permdocs
# mount -o rw,noatime /dev/concat/permdocs.eli /permdocs
.. and from this point everything seems to be fine. fsck_ufs also succeeds with no issues.
There is no output in /var/log/messages.
I have been using gconcat+geli for several months but it's only in the past 2-3 weeks that this has happened. I cannot reconcile this behaviour with any change in software or hardware so it may be coincidence.
I consider this a fairly serious problem because although the data does not appear to be lost this issue can impact on the running of a machine (automated mounts at boot will fail) and may also cause panic by the human trying to fix it!
Unknown. I have set kern.geom.concat.debug > 0 to hopefully show some useful debug output next time it happens.
More information about the freebsd-bugs