D. Eckert wrote: > too many words wasted, but not a single word, how to restore the data. > > I have read the man pages carefully. But again: there's nothing said, that on > USB drives zfs umount pool is not allowed. > It is allowed. But it's not enough. You need to read both the 'zpool ' and 'zfs' manpages. the 'zpool' manpage will tell you that the way to move the 'whole pool' to another machine is to run 'zpool export <poolname>'. The 'zpool export' will actually run the 'zfs umount' for you, though it's not a problem if it's already been done.
Note, this isn't USB specific, you won't see anything in the docs about USB. This condition applies to SCSI and others too. You need to export the pool to move it to another machine. If the machine crashed before you could export it, 'zpool import -f' on the new machine can help import it anyway. With USB, there are probably other commands you'll also need to use to notify Solaris that you are going to unplug the drive, Just like the 'Safely remove hardware' tool on windows. Or you need to remove it only when the system is shut down. These commands will be documented somewhere else, not in the ZFS docs because they don't apply to just ZFS. > So how on earth should a simple user know that, if he knows that filesystems > properly unmounted using the umount cmd?? > You need to understand that the filesystems are all contained in a 'pool' (more than one filesystem can share the disk space in in the same pool). Unmounting the filesystem *does not* prepare the *pool* to be moved from one machine to another. > And again: Why should a 2 weeks old Seagate HDD suddenly be damaged, if there > was no shock, hit or any other event like that? > Who knows? Some harddrives are manufactured with problems. Remember that ZFS is designed to catch problems that even the ECC on the drive doesn't catch. So it's not impossible for it to catch errors even the manufacturer's QA tests missed. > It is of course easier to blame the stupid user instead of having proper > documentation and emergency tools to handle that. > > I beleive that between the man pages, the administration docs on the web, the best practices pages, and all the other blogs and web pages, that ZFS is documented well enough. It's not like other filesystems, so there is more to learn, and you need to review all the docs, not just the ones that cover the operations (like unmount) that you're familiar with. Understanding pools (and the commands that manage pools,) is also important. Man pages and command references are good when you understand the architecture and need to learn about the details of a command you know you need to use. It's the other documentation that will fill you in you on how the system parts work together, and advise you on the best way to setup or do what you want. As I said in my other email ZFS can't repair errors without a way to reconstruct the data. It needs mirroring, parity (or the copies=x setting) to be able to repair the data. By setting up a pool with no redundancy. So your email subject line is a little backwards, since any 'professional' usage would incorporate redundancy (Mirror, Parity, etc.) What you're trying to do is more 'home/hobbiest' usage. Though most home/hobbiest users decide to incorporte redundancy for any data they really care about. > The list of malfunctions of SNV Builts gets longer and longer with every > version released. > > I'm sure new things are added every release, but many are also fixed. sNV is pre-release software after all. Overall the problems found aren't around long, and I beleive the list gets shorter as often as it gets longer. If you want production level Solaris, ZFS is available in solaris 10. > e. g. on SNV 107 > > - installation script is unable to write properly the boot blocks for grub > - you choose German locale, but have an American Keyboard style in the gnome > (since SNV 103) > - in SNV 107 adding these lines to xorg.conf: > > Option "XkbRules" "xorg" > Option "XkbModel" "pc105" > Option "XkbLayout" "de" > > (was working in SNV 103) > > lets crash the Xserver. > > - latest Nvidia Driver (Vers. 180) for GeForce 8400M doesn't work with > OpenSolaris SNV 107 > - nwam and iwk0: not solved, no DHCP responses > > Yes there was a major update of the X server sources to catch up to the latest(?) X.org release. Workarounds are known, and I bet this will be working again in b108 (or not long after.) > it seems better, to stay focused on having a colourfull gui with hundreds of > functions no one needs instead providing a stable core. > > The core of solaris is much more stable than anythign else I've used. The windowing system is not a part of the core of an operatinog system in my book. > I am looking forward the day booting OpenSolaris and see a greeting Windows > XP Logo surrounded by the blue bubbles of OpenSolaris..... > > <roll-eyes> Note that sNV (aka SXCE - or Solaris eXpress Community Edition) isn't really OpenSolaris, though they are related. OpenSolaris is based of specifc snapshots of sNV (the last one being b101 I think) and is updated much less often than sNV. sNV is mainly targeted at those who want to develop Solaris itself, and those who want to try out the latest builds. -Kyle > Cheers, > > D. > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
