4 ms·

ZFS however would protect against this, in that it checksums each chunk of data. And "zfs scrub poolname" will go through and do the checksums for you in the e

ZFS however would protect against this, in that it checksums each chunk of data. And "zfs scrub poolname" will go through and do the checksums for you in the event you are storing a lot of data and not necessarily reading/writing it often.

spydez 18y ago
Well, maybe I should look into transition my home server from Ubuntu and XFS to Nexenta or OpenSolaris and ZFS... I'd hate to lose some of the data on that thing, though I'm currently not doing any RAID. Just a disk of important stuff rsnapshotted every 4 hours to another disk.
- lallysingh 18y ago
  I've been running opensol/zfs for almost a year now. Zero problems, good perf & reliability. My research is on two mirrored sata/160gb drives. The most important stuff is on a FS on there with copies=2, making 2 copies on each drive. Also, backing up zfs is really, really easy. 48 lines of shell scripts do daily incrementals and weekly snapshot backups. But, do yourself a favor and put /usr/gnu/bin first in your path. oh, and alias tar=gtar. Old solarisisms will otherwise be irritating.
attack 18y ago
No, but it will notify you of a problem. However, I suspect that smartmontools would do an even better job of notifying you of a problem before it even occurs. If you want something that will actually protect against bit level errors well, generate some extra data using an appropriate Error Correcting Code for your important archives/files. Something like what par2repair generates. This is incredibly slow compared to simple erasure codes like RAID uses, though. There are some filesystems that do this for you automatically, I wrote one:) Actually, other than that I don't know of any filesystems that do this. If the above is impractical for performance reasons, Google recommends mirroring everything on three disks...
iigs 18y ago
As theoretically awesome as ZFS is, the math behind the human factors are more important than the math behind the computer failure rates, and this is something I don't believe we can fix with our current development methodologies. It looks like Joyent was able to rebuild most (all?) of their data in their ZFS data loss situation, but it could have played out drastically differently. http://discuss.joyent.com/viewtopic.php?id=19430 http://discuss.joyent.com/viewtopic.php?id=19430

spydez 18y ago

Well, maybe I should look into transition my home server from Ubuntu and XFS to Nexenta or OpenSolaris and ZFS... I'd hate to lose some of the data on that thing, though I'm currently not doing any RAID. Just a disk of important stuff rsnapshotted every 4 hours to another disk.

lallysingh 18y ago
I've been running opensol/zfs for almost a year now. Zero problems, good perf & reliability. My research is on two mirrored sata/160gb drives. The most important stuff is on a FS on there with copies=2, making 2 copies on each drive. Also, backing up zfs is really, really easy. 48 lines of shell scripts do daily incrementals and weekly snapshot backups. But, do yourself a favor and put /usr/gnu/bin first in your path. oh, and alias tar=gtar. Old solarisisms will otherwise be irritating.

attack 18y ago

No, but it will notify you of a problem. However, I suspect that smartmontools would do an even better job of notifying you of a problem before it even occurs. If you want something that will actually protect against bit level errors well, generate some extra data using an appropriate Error Correcting Code for your important archives/files. Something like what par2repair generates. This is incredibly slow compared to simple erasure codes like RAID uses, though. There are some filesystems that do this for you automatically, I wrote one:) Actually, other than that I don't know of any filesystems that do this. If the above is impractical for performance reasons, Google recommends mirroring everything on three disks...

iigs 18y ago

As theoretically awesome as ZFS is, the math behind the human factors are more important than the math behind the computer failure rates, and this is something I don't believe we can fix with our current development methodologies. It looks like Joyent was able to rebuild most (all?) of their data in their ZFS data loss situation, but it could have played out drastically differently. http://discuss.joyent.com/viewtopic.php?id=19430 http://discuss.joyent.com/viewtopic.php?id=19430