Well, the testing hasn't been going great. Fails: 17 T and 4 T of user data.
My testing protocol is pretty basic, but I want to know that the fundamentals work. A large part of being a database administrator is being methodical and working through all possibilities, including the obvious ones. To test phar2 64-bit, I'll be undertaking the following basic tests:
1. Create and verify 100% pars. Why verify? Because it's the most obvious step. Parity data created by app should be verifiable by the same app. Data should be no problem with the creator app. the verification should work 100% of the time.
2. Repair using 100% pars. Obviously, it should work, but assumption is the mother of all fuckups. Independently verify the repaired data file using SHA256 hashes.
3. Repair using 50% pars and 50% data. Independently verify the repaired data file using SHA256 hashes.
If a test can pass all three tests, the process is acceptable.
After ad-hoc testing failed with 17 T and 4 T of user data, I'm testing with 1 T of data. Failure at this level will mean that testing of higher amounts of data is not necessary.
Method:
1. I created a 1 T VHDX of fixed size. Even though I specified fixed, it was instantaneously created on a ReFS volume. ReFS is working great so far. I quick-formatted the VHDX, but there's no actual data in it.
2. I hashed the VHDX file. Funny, but it seems ReFS knows that most of the file is empty, so there was almost zero disk reads while hashing. I thought something was wrong with sha256deep64, so I used get-filehash in PS. Same behaviour - practically zero disk reads. And the hashing of a 1 T file took like an hour. This would normally take several hours at least. Nice!
3. Running the following command:
phpar264 c -b100 -r100 -u -n100 -m28672 -t16 -v test1.par2 .\1T.vhdx
A friend of minds thinks we should specify block SIZE, and not block COUNT (as I have in this command). I will test that in another test. once this is complete, I will proceed with the test and update this post.
No comments:
Post a Comment