On Sep 21, 2007, at 3:50 PM, Tim Spriggs wrote: > Paul B. Henson wrote: >> On Thu, 20 Sep 2007, Tim Spriggs wrote: >> >> >>> The x4500 is very sweet and the only thing stopping us from >>> buying two >>> instead of another shelf is the fact that we have lost pools on >>> Sol10u3 >>> servers and there is no easy way of making two pools redundant >>> (ie the >>> complexity of clustering.) Simply sending incremental snapshots >>> is not a >>> viable option. >>> >>> The pools we lost were pools on iSCSI (in a mirrored config) and >>> they >>> were mostly lost on zpool import/export. The lack of a recovery >>> mechanism really limits how much faith we can put into our data >>> on ZFS. >>> It's safe as long as the pool is safe... but we've lost multiple >>> pools. >>> >> >> Lost data doesn't give me a warm fuzzy 8-/. Were you running an >> officially >> supported version of Solaris at the time? If so, what did Sun >> support have >> to say about this issue? >> > > Sol 10 with just about all patches up to date. > > I joined this list in hope of a good answer. After answering a few > questions over two days I had no hope of recovering the data. Don't > import/export (especially between systems) without serious cause, at > least not with U3. I haven't tried updating our servers yet and I > don't > intend to for a while now. The filesystems contained databases that > were > luckily redundant and could be rebuilt, but our DBA was not too > happy to > have to do that at 3:00am. > > I still have a pool that can not be mounted or exported. It shows up > with zpool list but nothing under zfs list. zpool export gives me > an IO > error and does nothing. On the next downtime I am going to attempt to > yank the lun out from under its feet (as gently as I can) after I have > stopped all other services. > > Still, we are using ZFS but we are re-thinking on how to deploy/manage > it. Our original model had us exporting/importing pools in order to > move > zone data between machines. We had done the same with UFS on iSCSI > without a hitch. ZFS worked for about 8 zone moves and then killed 2 > zones. The major operational difference between the moves involved a > reboot of the global zones. The initial import worked but after the > reboot the pools were in a bad state reporting errors on both > drives in > the mirror. I exported one (bad choice) and attempted to gain > access to > the other. Now attempting to import the first pool will panic a > solaris/opensolaris box very reliably. The second is in the state I > described above. Also, the drive labels are intact according to zdb. > > When we don't move pools around, zfs seems to be stable on both > Solaris > and OpenSolaris. I've done snapshots/rollbacks/sends/receives/ > clones/... > without problems. We even have zvols exported as mirrored luns from an > OpenSolaris box. It mirrors the luns that the IBM/NetApp box > exports and > seems to be doing fine with that. There are a lot of other people that > seem to have the same opinion and use zfs with direct attached > storage. > > -Tim > > PS: "when I have a lot of time" I might try to reproduce this by: > > m2# zpool create test mirror iscsi_lun1 iscsi_lun2 > m2# zpool export test > m1# zpool import -f test > m1# reboot > m2# reboot >
Since I haven't actually looked into what problem caused your pools to become damaged/lost, i can only guess that its possibly due to the pool being actively imported on multiple machines (perhaps even accidentally). If it is that, you'll be happy to note that we specifically no longer that to happen (unless you use the -f flag): http://blogs.sun.com/erickustarz/entry/poor_man_s_cluster_end http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6282725 Looks like it just missed the s10u4 cut off, but should be in s10_u5. In your above example, there should be no reason why you have to use the '-f' flag on import (the pool was cleanly exported) - when you're moving the pool from system to system, this can get you into trouble if things don't go exactly how you planned. eric _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
