!00% completed, 117224MiB processed in 1:00
Everything OK
Error syncing parity file 'C:/Parity/ZZ/Documentary.parity' Bad file descriptor [1]
Danger! Unexpected sync error in 2-parity disk.
First bank of drives (not this one) was without incident, but this one has me stumped. No way to attach the screen prints here?
Including only because this may have some effect. With this bank, I used ATA-over-ethernet for the parity drives also, and these drives spin down after about 15 minutes of non use.
I've used a similar setup without incident on another drive tho...so I would tend to rule this out.
Has this array in fact synced? What do I need to do to be sure?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My supposition is that for some reasons Windows doesn't provide a buffered access at parity in this configuration, and then the internal FlushFileBuffers() call fails.
I'l gladly do this, but you'll need to forgive delays. Currently taking down our Raid 1 servers for replacement with your system. Every disassembled server yields more drives...and since I'd like to preserve my current backups for this array - need more recovered drives for a new parity drive set.
I figure you know this drill pretty well :) Also know "I owe you" for sticking so many extra drives in my pocket. May have enough here for 30 more years (hahahahaha).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would a slightly reduced array size and a single parity drive be sufficient for your simulation? I could get this to you sooner under those circumstances.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Backing up a SAN with beta 7 on two drives - ETA 24hrs.
Surprisingly, this new version is faster than 6.X - almost as fast as the bank with the direct connect parity drives ~96Mib...despite the fact the parity drives used are are of vastly inferior speed, and I haven't gotten around to installing that dedicated NIC for the parity drives.
Clearly there is a lot for me to learn here. I just don't understand where the bottlenecks are.....Thought writes were the problem but I really don't know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nope. This is an old X3430, and I just looked it up. No AVX. You must have improved something else too..because this does run slightly faster.
Think I'll take your advice about betas tho. Suspect you really wring them out before release - so I don't want to deprive myself of that final inspection :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
!00% completed, 117224MiB processed in 1:00
Everything OK
Error syncing parity file 'C:/Parity/ZZ/Documentary.parity' Bad file descriptor [1]
Danger! Unexpected sync error in 2-parity disk.
First bank of drives (not this one) was without incident, but this one has me stumped. No way to attach the screen prints here?
Including only because this may have some effect. With this bank, I used ATA-over-ethernet for the parity drives also, and these drives spin down after about 15 minutes of non use.
I've used a similar setup without incident on another drive tho...so I would tend to rule this out.
Has this array in fact synced? What do I need to do to be sure?
Hi Reciprocate,
My supposition is that for some reasons Windows doesn't provide a buffered access at parity in this configuration, and then the internal FlushFileBuffers() call fails.
To confirm this, could you please try with the 7.0 BETA ? Available at: http://snapraid.sourceforge.net/beta/
Note that also with this beta an error is expected, but from the error output I should be able to get more information. So, please report it.
If this is confirmed, the correct behavior would be to ignore this error.
Thanks,
Andrea
I'l gladly do this, but you'll need to forgive delays. Currently taking down our Raid 1 servers for replacement with your system. Every disassembled server yields more drives...and since I'd like to preserve my current backups for this array - need more recovered drives for a new parity drive set.
I figure you know this drill pretty well :) Also know "I owe you" for sticking so many extra drives in my pocket. May have enough here for 30 more years (hahahahaha).
Would a slightly reduced array size and a single parity drive be sufficient for your simulation? I could get this to you sooner under those circumstances.
Hi Reciprocate,
I don't know if single parity is enough. In your error report, it's the second parity drive that has the error.
But if you have time, you can try. I just need to reproduce the error one time with the 7.0 version, and see what error is reported.
Ciao,
Andrea
Backing up a SAN with beta 7 on two drives - ETA 24hrs.
Surprisingly, this new version is faster than 6.X - almost as fast as the bank with the direct connect parity drives ~96Mib...despite the fact the parity drives used are are of vastly inferior speed, and I haven't gotten around to installing that dedicated NIC for the parity drives.
Clearly there is a lot for me to learn here. I just don't understand where the bottlenecks are.....Thought writes were the problem but I really don't know.
No errors from Ver 7.0. Confirmed.
Used identical settings + new filenames for the content files and new path for the new parity pair.
Should I just keep using the beta :)
Hi Reciprocate,
Thanks for the report.
About the 7.0 beta, it could be faster if you have a new iCore Haswell CPU. In such case it uses new AVX2 instructions to compute the parity.
About continuing using it, I have no reason to expect problems. But I cannot recommend to use a beta for production. It's your call :)
Ciao,
Andrea
Nope. This is an old X3430, and I just looked it up. No AVX. You must have improved something else too..because this does run slightly faster.
Think I'll take your advice about betas tho. Suspect you really wring them out before release - so I don't want to deprive myself of that final inspection :)