Date: Wed, 20 Oct 2010 10:04:37 +0100 From: Karl Pielorz <kpielorz_lst@tdx.co.uk> To: Willem Jan Withagen <wjw@digiware.nl>, Freddie Cash <fjwcash@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS 'read-only' device / pool scan / import? Message-ID: <79DCDDF23AE4C12D5A222B8B@HexaDeca64.dmpriest.net.uk> In-Reply-To: <4CBE1485.2070400@digiware.nl> References: <AE519076FDEA1259C5DEA689@HexaDeca64.dmpriest.net.uk> <20101019151602.GA61733@icarus.home.lan> <7BEF90D9F4D4CB985F3573C3@HexaDeca64.dmpriest.net.uk> <4CBDFFF6.5080701@digiware.nl> <AANLkTi=DikO4-N8BG4U0WBX-7ypbPkVCR8=vHSaeN3qV@mail.gmail.com> <4CBE1485.2070400@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--On 19 October 2010 23:58 +0200 Willem Jan Withagen <wjw@digiware.nl> wrote: > And your suggestion is that although things looked really messed up, just > export/import fixed the lot.... I've had messed up pools fixed up before by shutting down, 'rejigging' the drives and restarting - but I've didn't think of exporting/importing [afaik the FreeBSD code goes and 'looks' for all the drives anyway at startup - i.e. it doesn't have something akin to zfs.cache] - so I kind of didn't see the point... I also didn't think you could export a faulted pool :) [or, as the original thread started - that once you'd tried to import a faulted pool, the on-drive metadata gets change, possibly corrupted - or at the very least it makes a note of the fact the missing drives are, 'missing' :) > The GPT trick is sort of selfdocumenting, because it is otherwise real > easy to get lost with 10 disks and 4 flash-devices. :( > And just because I yanked a single log disk (the wrong one) I ended up > with a corrupt zraid. Yeah, we'll definitely start looking at GPT - I've kind of always shied away from it before as we've always just used raw disks, and I think there was a paranoia about other stuff 'clobbering' the GPT metadata. That was probably a few years ago now though - so definitely worth a re-visit. > So the least lesson for me here (again) has been that disk handling > requires the utmost care. Trouble is just around the corner. A very valid point - for all the wonder and security ZFS brings, you *still* need to be careful with data! I'm also starting to disfavour RAIDZx vs. mirrors - mirrors are so much easier to work with (performance aside) and the ability to just 'buddy up' a possibly failing disk, or change redundancy on a volume is very nice. I guess a lot depends on if you have the bays for it :) I guess a counter argument is that if you've designed the system correctly you shouldn't want or need to go affecting a volumes redundancy! :) -Karl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79DCDDF23AE4C12D5A222B8B>