On Oct 10, 2008, at 15:48, Victor Latushkin wrote: > I've mostly seen (2), because despite all the best practices out > there, > single vdev pools are quite common. In all such cases that I had my > hands on it was possible to recover pool by going back by one or two > txgs.
For better or worse this is the case where I work. Most of our storage is on SANs (EMC and NetApp), and so if we need more space we ask for it and we get a giant LUN given to us (usually multi-pathed). We also have a lot of Veritas VxVM and VxFS for Oracle, and so even if we're running Solaris 10, we're not using ZFS in that case. SAN space is also allocated to Windows and VMware ESX machines as well, so it's not like we can ask for the disks in the SAN to be exported raw, as that would mess up managing of things with the other OSes. (We have a very small global storage / back up team, and I really don't want to add more to their workload.) If someone finds themselves in this position, what advice can be followed to minimize risks? For example, is having checksums enabled a good idea? If you have no redundancy and an error occurs, the system will panic by default (configurable in newer builds of OpenSolaris, but not in Solaris 'proper' yet). But if the system is ignoring checksums, you're no worse off than most other file systems (but still get all the other features of ZFS). Or is there a way to mitigate a checksum error on non-redundant zpool? _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
