checksum
Cadet
- Joined
- Dec 1, 2016
- Messages
- 5
Newb here,
I'm running a abominable testrig in preparation for building multiple proper FreeNAS servers.
It's a Apple iMac (21.5 inch), and it's a few years old. My 4 connected drives are:
2 x 3TB connected in a Firewire 800 daisychain
2 x 2TB connected with USB 2.0
500GB internal spinning drive
Ridiculous, I know. This is about breaking things to learn why they break.
I created a pool with the 3TB drives mirrored in a vdev and the 2TB drives mirrored in a second vdev. I used the 500GB drive as cache.
I filled the pool to 78% (3.4/4.4TB) and let it sit for a day. This data is of no importance. Then i ran a scrub.
The scrub found one corrupt file it couldn't recover.
After I copied the data in the first place I ran a checksum compare (I ran rsync a second time with the "--checksum" flag). And all was cool in the pool. After ZFS gave me the error I ran rsync with checksum on the broken file, and rsync did recopy it (meaning the checksum was different than on my source).
So now my questions:
- I assume my files made it into the pool whole, because the checksum pass after copy didn't complain. Am I wrong?
- The drives are old and well past worn in, so failure doesn't seem unlikely. But failure of both copies of that one file?
- Is the non ECC RAM to blame? (Will I not have to worry about this mode of failure in a proper ECC RAM build?)
I am running a new scrub after having replaced the broken file. I want to do a memtest after that finishes.
I know the machine is terrible, but I did not expect failure in this place. I hope you wise people of the forum can make me smarter.
I'm running a abominable testrig in preparation for building multiple proper FreeNAS servers.
It's a Apple iMac (21.5 inch), and it's a few years old. My 4 connected drives are:
2 x 3TB connected in a Firewire 800 daisychain
2 x 2TB connected with USB 2.0
500GB internal spinning drive
Ridiculous, I know. This is about breaking things to learn why they break.
I created a pool with the 3TB drives mirrored in a vdev and the 2TB drives mirrored in a second vdev. I used the 500GB drive as cache.
I filled the pool to 78% (3.4/4.4TB) and let it sit for a day. This data is of no importance. Then i ran a scrub.
The scrub found one corrupt file it couldn't recover.
After I copied the data in the first place I ran a checksum compare (I ran rsync a second time with the "--checksum" flag). And all was cool in the pool. After ZFS gave me the error I ran rsync with checksum on the broken file, and rsync did recopy it (meaning the checksum was different than on my source).
So now my questions:
- I assume my files made it into the pool whole, because the checksum pass after copy didn't complain. Am I wrong?
- The drives are old and well past worn in, so failure doesn't seem unlikely. But failure of both copies of that one file?
- Is the non ECC RAM to blame? (Will I not have to worry about this mode of failure in a proper ECC RAM build?)
I am running a new scrub after having replaced the broken file. I want to do a memtest after that finishes.
I know the machine is terrible, but I did not expect failure in this place. I hope you wise people of the forum can make me smarter.
Last edited by a moderator: