zfs discuss - Feb 2010 - Another user looses his pool (10TB) in this case and 40 days work

I had a very similar problem. 8 external USB drives running OpenSolaris
native. When I moved the machine into a different room and powered it back
up (there were a couple of reboots and a couple of broken usb cables and
drive shut downs in between), I got the same error. Loosing that much data
is definitely a shock.

I m running zraid2 and I would have assumed that a 2 level redundancy should
fine to toss a lot of roughness at the pool.

After panicking a little, stressing my family out, and some playing with zdb
that lead nowhere, I did a
zpool export mypool
zpool import mypool

It complained about being unable to mount because the mount point was not
empty, so I did
umount /mypool/mypool
zfs mount mypool/mypool
zfs status mypool

and to my relieving surprise it seems all fine.
ls /mypool/mypool

does show data.

Scrub is running right now to be on the safe side.

Thought that may help some folks out there.

Cheers!

Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100213/3868e2db/attachment.html>

I just have the say this, and I don''t mean it in a bad way... If you 
really care about your data why then use usb drives with lose cables and 
(apparently no backup)....

USB connected drives for data backup are okay, for playing around and 
getting to know ZFS seems also okay. Using it for online data that you 
care about and expecting it to be reliable...its just not the right 
technology for that imho.

..Remco

On 2/13/10 11:23 AM, Andy Stenger wrote:
> I had a very similar problem. 8 external USB drives running 
> OpenSolaris native. When I moved the machine into a different room and 
> powered it back up (there were a couple of reboots and a couple of 
> broken usb cables and drive shut downs in between), I got the same 
> error. Loosing that much data is definitely a shock.
>
> I m running zraid2 and I would have assumed that a 2 level redundancy 
> should fine to toss a lot of roughness at the pool.
>
> After panicking a little, stressing my family out, and some playing 
> with zdb that lead nowhere, I did a
> zpool export mypool
> zpool import mypool
>
> It complained about being unable to mount because the mount point was 
> not empty, so I did
> umount /mypool/mypool
> zfs mount mypool/mypool
> zfs status mypool
>
> and to my relieving surprise it seems all fine.
> ls /mypool/mypool
>
> does show data.
>
> Scrub is running right now to be on the safe side.
>
> Thought that may help some folks out there.
>
> Cheers!
>
> Andy
>
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100213/5b7de805/attachment.html>

Hello,
I''m now thinking there is some _real_ bug in the way zfs handles files
systems created with the pool itself (ie tank filesystem when zpool is tank,
usually mounted as /tank)
My own experiens shows that zfs is unable to send/receive recursively
(snapshots, child fs) properly when the destination is such a "level
0" files system ie othertank, thought everything works as expected when i
send to othertank/tank (see my posts)
I think you might  also see some aspects of this problem
Bruno
-- 
This message posted from opensolaris.org

Yes, if you value your data you should change from USB drives to normal drives.
I heard that USB did some strange things? Normal connection such as SATA is more
reliable.
-- 
This message posted from opensolaris.org