bcirvin, you proposed "something to allow us to try to pull data from a failed pool". Yes and no. 'Yes' as a pragmatic solution; 'no' for what ZFS was 'sold' to be: the last filesystem mankind would need. It was conceived as a filesystem that does not need recovery, due to its guaranteed consistent states on the/any drive - or better: at any moment. If this was truly the case, a recovery program was not needed, and I don't think SUN will like one neither. It also is more then suboptimal to prevent caching as proposed by others; this is but a very ugly hack.
Again, and I have yet to receive comments on this, the original poster claimed to have done a proper flash/sync, and left a 100% consistent file system behind on his drive. At reboot, the pool, the higher entity, failed miserably. Of course, now one can conceive a program that scans the whole drive, like in the good ole days on ancient file systems to recover all those 100% correct file system(s). Or, one could - as proposed - add an Überblock, like we had the FAT-mirror in the last millennium. The alternative, and engineering-wise much better solution, would be to diagnose the weakness on the contextual or semantical level: Where 100% consistent file systems cannot be communicated to by the operating system. This - so it seems - is (still) a shortcoming of the concept of ZFS. Which might be solved by means of yesterday, I agree. Or, by throwing more work into the level of the volume management, the pools. Without claiming to have the solution, conceptually I might want to propose to do away with the static, look-up-table-like structure of the pool, as stored in a mirror or Überblock. Could it be feasible to associate pools dynamically? Could it be feasible, that the filesystems in a pool create a (new) handle once they are updated in a consistent manner? And when the drive is plugged/turned on, the software simply collects all the handles of all file systems on that drive? Then the export/import is possible, but not required any longer, since the filesystems form their own entities. They can still have associated contextual/semantic (stored) structures into which they are 'plugged' once the drive is up; if one wanted to ('logical volume'). But with or without, the pool would self-configure when the drive starts by picking up all file system handles. Uwe -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss