> 4. While reading an offline disk causes errors, writing does not! > *** CAUSES DATA LOSS *** > > This is a big one: ZFS can continue writing to an unavailable pool. It > doesn't always generate errors (I've seen it copy over 100MB > before erroring), and if not spotted, this *will* cause data loss after you > reboot. > > I discovered this while testing how ZFS coped with the removal of a hot plug > SATA drive. I knew that the ZFS admin tools were > hanging, but that redundant pools remained available. I wanted to see > whether it was just the ZFS admin tools that were failing, > or whether ZFS was also failing to send appropriate error messages back to > the OS. >
This is not unique for zfs. If you need to know that your writes has reached stable store you have to call fsync(). It is not enough to close a file. This is true even for UFS, but UFS won't delay writes for all operations so you will notice faster. But you will still loose data. I have been able to undo rm -rf / on a FreeBSD system by pulling the power cord before it wrote the changes... Databases use fsync (or similar) before they close a transaction, that one of the reasons that databases like hardware write caches. cp will not. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
