Date: Tue, 19 Oct 2010 22:30:46 +0200 From: Willem Jan Withagen <wjw@digiware.nl> To: Karl Pielorz <kpielorz_lst@tdx.co.uk> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS 'read-only' device / pool scan / import? Message-ID: <4CBDFFF6.5080701@digiware.nl> In-Reply-To: <7BEF90D9F4D4CB985F3573C3@HexaDeca64.dmpriest.net.uk> References: <AE519076FDEA1259C5DEA689@HexaDeca64.dmpriest.net.uk> <20101019151602.GA61733@icarus.home.lan> <7BEF90D9F4D4CB985F3573C3@HexaDeca64.dmpriest.net.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2010-10-19 17:30, Karl Pielorz wrote:
> As there is such a large aspect of human error (and controller
> behaviour), I don't think it's worth digging into any deeper. It's the
> first pool we've ever "lost" under ZFS, and like I said a combination of
> the controller collapsing devices, and humans replacing wrong disks,
> 'twas doomed to fail from the start.
>
> We've replaced failed drives on this system before - but never rebooted
> after a failure, before a replacement - and never replaced the wrong
> drive :)
>
> Definitely a good advert for backups though :)
I'm running my ZFS stuff on a 3ware and an areca controller, and they
once in a while forgot their order of disks during booting.
(the 3ware got fixed by a bios upgrade)
The areca just keeps reordering no matter how hard you like to tell it
otherwise.
But GPT really proves useful since reallocation of disks does not result
in a different device in the gpt directory.
eg.:
pool: zroot
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
mirror ONLINE 0 0 0
gpt/root4 ONLINE 0 0 0
gpt/root6 ONLINE 0 0 0
I could even migrate a disk from the 3ware controller to the std SATA
interfaces without losing the the gpt-label.
--WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CBDFFF6.5080701>