Date: Wed, 12 Nov 2008 17:27:01 -0800 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Brooks Davis <brooks@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: GEOM hangover disables NFS Message-ID: <20081113012701.GA27354@troutmask.apl.washington.edu> In-Reply-To: <20081113011506.GA6719@lor.one-eyed-alien.net> References: <20081112235903.GA19865@troutmask.apl.washington.edu> <20081113011506.GA6719@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 12, 2008 at 07:15:06PM -0600, Brooks Davis wrote: > On Wed, Nov 12, 2008 at 03:59:03PM -0800, Steve Kargl wrote: > > On three nodes in my cluster (nodes n17, n18, and n19), I had > > GEOM use /dev/ad4s1e for tests with gmirror and ggated/ggatec. > > I found that GEOM was insufficient for my needs and decided > > to return the 3 partitions to NFS-exported partitions. It seems > > that once GEOM touches a partition, the partition can no longer > > be used by NFS. > > (snip) > > So, how does one exorcise GEOM from /dev/ad4s1e? > > All disks and partitions are always represented as GEOM devices. This is > the only way to access storage so I'm pretty sure you don't actually > want to get rid of GEOM. :) > > The output of "sysctl -b kern.geom.conftxt" would show if there were > bits that were being picked up by a stray geom consumer. A dmesg from > the problem nodes might also be helpful in determining what's wrong. > The best guess would be left over state, probably at the end of the > volumes. If local access to the file system actually works, NFS really > shouldn't care what's been done to the disk below the file system. > Andrzej Tobola pointed me to the NFS_LEGACYRPC kernel option. Seems I chose a bad time to experiment with gmirror and ggated/ggatec in that my fallback plan to plain old NFS had an unforeseen (by me) bug. -- Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081113012701.GA27354>