On Fri, May 30, 2008 at 6:30 AM, Jeb Campbell <[EMAIL PROTECTED]> wrote: > Ok, here is where I'm at: > > My install of OS 2008.05 (snv_86?) will not even come up in single user. > > The OS 2008.05 live cd comes up fine, but I can't import my old pool b/c of > the missing log (and I have to import to fix the log ...). > > So I think I'll boot from the live cd, import my rootpool, mount it, and copy > /rootpool/etc/zfs.cache to zfs.cache.save. Then I'll stick the zfs.cache from > the live cd onto the rootpool, update boot bits, and cross my fingers. > > The goal of this is to get my installed OS to finish a boot, then I can try > using the saved zfs.cache to load the degraded pool w/o import. As long as I > can get to it read-only, I'll copy what I can off. > > Any tips, comments, or suggestions would be welcome, >
It seems we are in our own little echo chamber here. Well, these are the bugs/resolutions that need to be addressed: 1) and l2arc or log device needs to evacuation-possible 2) any failure of a l2arc or log device should never prevent importation of a pool. It is an additional device for cache/log purposes, and failures of these devices should be correctly handled, but not at the scope of failing the volume/losing already stored data. Yes, this means that data in the intent log may be lost, but I'd rather lose that 0.01% vs the whole volume 3) The failure to iterate filesystems bug is also quite annoying. If any sub-FS in a zfs pool is not iteratable (data/home in my example), the importation of the pool should note the error but proceed. Mounts to data/proj and data/* except for data/home should continue. Again, always attempt to do as much as possible to provide access to the data that's still available. Giving up on all mounts because of a fault on one is not reasonable behavior There are more things here, and perhaps one can argue with the above. However, my stance is being overly conservative to _DATA ACCESS_ -- faulting a pool until you can contact support and get a hack to recover otherwise available data is just not good form :) You'll lose customers left and right because of the cost of the "downtime" > Jeb > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
