Date: Thu, 21 Jun 2012 16:44:29 +0200 (CEST) From: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> To: Julien Cigar <jcigar@ulb.ac.be> Cc: freebsd-questions@freebsd.org Subject: Re: Is ZFS production ready? Message-ID: <alpine.BSF.2.00.1206211635400.3170@wojtek.tensor.gdynia.pl> In-Reply-To: <4FE32FF5.60603@ulb.ac.be> References: <4FE2CE38.9000100@gmail.com> <CAPj0R5Kmi-%2BdJ7mPvTrTAoS8O983svOyR2WyK2_v1Cr07dSS_A@mail.gmail.com> <alpine.BSF.2.00.1206211413140.2263@wojtek.tensor.gdynia.pl> <CA%2BD9QhuQ%2BbxKW9%2BdX%2BzS9mErwz8JSkV2G7qL0KfB8BH_LGJAgA@mail.gmail.com> <alpine.BSF.2.00.1206211539230.2903@wojtek.tensor.gdynia.pl> <CA%2BD9QhvR_eKtVxdKcaMyOS7tLw_AOHKgUy3o7mJn2b=chMA0Xw@mail.gmail.com> <4FE32FF5.60603@ulb.ac.be>
next in thread | previous in thread | raw e-mail | index | archive | help
> One interesting feature of ZFS if it's block checksum: all reads and writes > include block checksum, so it can easily detect situations where, for > example, data is quietly corrupted by RAM. you may be shocked but you are sometimes wrong. i already demostrated it and checksumming doesn't get any errors, and do write wrong data with right checksums :) it's quite easy to explain if one understand hardware details. Checksumming will protect you from - failed SATA/SAS port, on-disk controller that returns bad data as good. This is actually really rare case. i never seen that, but maybe it happens. - some types of DRAM failure - but not all. Actually just a small fraction because DRAM failure like that would bring your system to crash so quickly that you are unlikely to get big data corruption. Common case with DRAM memory is that after you write to it, keeps right data some time and RARELY flips some bit later in spite of refresh. With this type you may run your machine for hours, even days or longer. And ZFS would calculate proper checksum of wrong data and will write it to disk. This is the reason i keep few failed DIMMs - for testing how different software behaves on broken machine. UFS resulted in few corrupted files after half a day of heavy work and 4 crashes. fsck always recovered things well (of course "unexpected softupdate inconsistency....") ZFS survived 2 crashes. After third it panicked on startup. Of course - no zfs_fsck. And no possibility of making really good zfs_fsck because of data layout, at least not easy. > This feature is very important for databases. is data integrity not important for the rest? :) Still - disks itself perform quite heavy ECC and both SATA and SAS ports.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1206211635400.3170>