Hi,
My system is a little unstable and will eventually crash if I let sync or scrub run long enough (~3 to 5) hours. To get around this I just stop the sync/scrub operation using ctrl-c in two hours and restart. This seems to work just fine for sync and scrub.
But I am worried about the FIX command. Does it have to run un-interrupted? Or will ctrl-c do a graceful shutdown? Will FIX continue from where it stopped when restarted?
Also I set the auto-save content file during sync to a lower level than the standard.
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are restoring a lost disk or missing files you can workaround that by using the -m parameter to only restore missing files, which will be decreasing in number for each file restored.
You will also need to be vigilant regarding partially fixed files that were in progress of being written during the crash and delete them in order to include them again in the next fix attempt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can use the -S and -B args with fix. And you could script a sequence of such fix runs, with an appropriate sleep time between each run (to regain stability).
OR you could try to rectify the instability :)
Are you still running USB drives?
Last edit: UhClem 2022-01-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And this card is driving them:
Ableconn PEX-SA134 4-Port eSATA III 6Gbps PCI Express Four Lanes Host Adapter Card - AHCI Port-Multiplier PCIe 2.0 x4 Controller Card
I then read that the controller on this card has known stability issues. Not sure if it's true, but I never had any issues when using the 6 internal sata connectors.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I get the picture now. I did a lot of playing around with port multipliers, including with SnapRAID, about 8-10 years ago. Freeze-ups after a period of sustained operation often/usually occurred. I did not attempt to do a rigorous study of the phenomenum, but my guess is that the companies designing/making the port multiplier chips only tested them with their own SATA controllers. And your situation fits right in to that suspicion.
Your HF2-SU3S2 boxes use a JMicron JMB321 PM chip, and your PEX-SA134 uses (two) Asmedia ASM1062 SATA controller chips. Also, even when the same company's controller is paired with their own PM chip, they often still need a custom/non-standard SATA driver for happiness. (The whole idea of Industry Standards is to eliminate that kind of crap.)
I don't know what to suggest for you. If you feel comfortable with the status quo, but just want to streamline/automate the do-it-in-chunks procedure, my suggestion above should be workable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
My system is a little unstable and will eventually crash if I let sync or scrub run long enough (~3 to 5) hours. To get around this I just stop the sync/scrub operation using ctrl-c in two hours and restart. This seems to work just fine for sync and scrub.
But I am worried about the FIX command. Does it have to run un-interrupted? Or will ctrl-c do a graceful shutdown? Will FIX continue from where it stopped when restarted?
Also I set the auto-save content file during sync to a lower level than the standard.
Thanks.
Fix will start over each time.
If you are restoring a lost disk or missing files you can workaround that by using the -m parameter to only restore missing files, which will be decreasing in number for each file restored.
You will also need to be vigilant regarding partially fixed files that were in progress of being written during the crash and delete them in order to include them again in the next fix attempt.
Thanks! That is good news!
You can use the -S and -B args with fix. And you could script a sequence of such fix runs, with an appropriate sleep time between each run (to regain stability).
OR you could try to rectify the instability :)
Are you still running USB drives?
Last edit: UhClem 2022-01-13
They were 10 8-TB USB drives from costco - I removed the package and placed them in four of these:
https://www.amazon.com/Mediasonic-ProBox-HF2-SU3S2-SATA-Enclosure/dp/B003X26VV4/ref=pd_rhf_ee_s_rp_c_2_29/145-4456699-1679615?pd_rd_w=adNPe&pf_rd_p=b84519b4-0dcf-432b-8d9a-2d8045a876e9&pf_rd_r=QGGPD7G0TQTRV4D5MPJY&pd_rd_r=19fa90f9-1274-45d8-966a-8a4974773d3d&pd_rd_wg=ke4Eq&pd_rd_i=B003X26VV4&psc=1
And this card is driving them:
Ableconn PEX-SA134 4-Port eSATA III 6Gbps PCI Express Four Lanes Host Adapter Card - AHCI Port-Multiplier PCIe 2.0 x4 Controller Card
I then read that the controller on this card has known stability issues. Not sure if it's true, but I never had any issues when using the 6 internal sata connectors.
OK, I get the picture now. I did a lot of playing around with port multipliers, including with SnapRAID, about 8-10 years ago. Freeze-ups after a period of sustained operation often/usually occurred. I did not attempt to do a rigorous study of the phenomenum, but my guess is that the companies designing/making the port multiplier chips only tested them with their own SATA controllers. And your situation fits right in to that suspicion.
Your HF2-SU3S2 boxes use a JMicron JMB321 PM chip, and your PEX-SA134 uses (two) Asmedia ASM1062 SATA controller chips. Also, even when the same company's controller is paired with their own PM chip, they often still need a custom/non-standard SATA driver for happiness. (The whole idea of Industry Standards is to eliminate that kind of crap.)
I don't know what to suggest for you. If you feel comfortable with the status quo, but just want to streamline/automate the do-it-in-chunks procedure, my suggestion above should be workable.