• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Fatal_Flaw

  • Rank


  • Gender
  1. Thanks, will do. I definitely have a rats nest of power splitters, so that's a good bet.
  2. Here's what happened. Disk 4 has read/write errors and gets disabled. Ran long SMART test on disk 4 with no errors. Rebuild disk 4 on same physical disk. Completes successfully. ~14 hours after rebuild completed successfully, disk 4 has read/write errors again and gets disabled. ~3 hours after disk 4's errors, disk 5 has read errors but is not disabled. At this point, I'm guessing I should replace the cables on disk 4 and disk 5, but am wondering if there's anything else I should try/do. Diags attached. filebox-diagnostics-20210715-1153
  3. Thanks, that clarified it for me. It didn't occur to me that xfs_repair would be run against the emulated disk rather than the physical disk. Nah, I know what formatting is. My point was that the disk was disabled with the unmountable error due to file system corruption, but the emulated disk was accessible and the data seemed to be intact. So presumably re-assigning that disabled disk as a new one in the config and rebuilding it from parity would write a useable filesystem to the disk. SOLUTION: What I ended up doing Because the drive wasn't being written to w
  4. Thanks for the reply, but I'm confused. I thought rebuilding the drive overwrote everything on it bit for bit regardless of the existing data or file system on it? Why would it matter if I do it before or after xfs_repair? And if I'm going to rebuild the drive, why would I run xfs_repair at all instead of just reformatting it? These sata add-on cars have been a huge pain for years now. They do drop disks a lot when there's heavy read/write activity on them. Last time I looked at the list of "recommended" controllers, there weren't good options given my setup and requirements. Th
  5. I'm getting the error "Unmountable: No file system" for one of my drives. Syslog says Nov 3 18:32:34 Filebox emhttpd: shcmd (86): mkdir -p /mnt/disk9 Nov 3 18:32:34 Filebox emhttpd: shcmd (87): mount -t xfs -o noatime,nodiratime /dev/md9 /mnt/disk9 Nov 3 18:32:34 Filebox kernel: XFS (md9): Mounting V5 Filesystem Nov 3 18:32:34 Filebox kernel: XFS (md9): Corruption warning: Metadata has LSN (1:63423) ahead of current LSN (1:63186). Please unmount and run xfs_repair (>= v4.3) to resolve. Nov 3 18:32:34 Filebox kernel: XFS (md9): log mount/recovery failed: error -22 Nov
  6. I've tried it on two different machines, different OSes, with different files. Neither is hitting it's head on the RAM or processor, and I've tried disabling compression. The data being backed up is nearly incompressible anyway. Both were nearly maxing out my upload connection before the migration, now they're both under 2Mbps. The only two constants between the two machines are CrashPlan and my ISP. The only thing I can think of that I haven't tried is using a vpn to eliminate ISP throttling as an issue. **Just tried through a VPN. It didn't improve upload speed at all. I don't kn
  7. I will, but frankly I've had better luck with the community then I've had with Code42 so I decided to start here. Anyways, thanks for the great container and the help. If they give me anything of use I'll post it here in case it's helpful to anyone else.
  8. I just tested the windows client on a different machine and it's uploading at a similarly slow speed, so it's unlikely it's a client issue. I've also tested uploading to google drive and it's uploading at full speed so it's not an issue with my internet connection. I can only assuming they're throttling. Which really sucks.
  9. I have double checked my config file and it does still have dedupe disabled. It is uploading at the speed I would expect it to if dedupe were enabled. But with the config file being correct, I don't know where to go from here. <compression>OFF</compression> <dataDeDupAutoMaxFileSize>1</dataDeDupAutoMaxFileSize> <dataDeDupAutoMaxFileSizeForWan>1</dataDeDupAutoMaxFileSizeForWan> <dataDeDuplication>MINIMAL</dataDeDuplication> I went and looked at some old logs I 10/01/17 12:16AM [XXXXX
  10. I've gotten much lower speeds since migrating to small business from home. I doubt it's the container because I've been getting terrible speeds since the migration on both gfjardim's container and this one. It rarely goes about 2Mbps. Before the small business migration I'd get 4.5-5.5Mbps. I don't know if they're throttling me since the migration or if small business is inherently slower, but it's a real problem.
  11. Altering the allocated cores has not fixed the problem. It recurred today. Does anyone have other suggestions?
  12. unRAID had cores 0-3 and the vm had 4-7. I've now changed it to unRAID 0-5 and vm 6-7.
  13. I'll try it, though that seems unlikely to me. I've run unRAID on far less than 4 threads from a Core i7-4790 without issue.
  14. I've been struggling with this issue for a while and have finally figured out (at least broadly) what is causing the problem. About once every 24 hrs, unRAID interfaces (both web and ssh) become unresponsive and the SMB share can't be accessed, but my Win8.1 VM keeps running and I can access it through RDP w/o issue. There's been no errors in the syslog. I haven't been able to find a hardware problem. I started suspecting the VM. So I left the VM off for a few days and the problems disappeared. I then tried to narrow it down further by starting the VM but limiting the programs that ran. B
  15. I've still been unable to solve this issue. I'm having to hard reboot it every 24-48 hours. I've moved the one virtual hard disk file from my VM off of the data array and onto the cache drive. That didn't change anything. I ran extended SMART tests on all of my drives and they all came back without errors. Does anyone have any ideas what else I could try? At this point I don't know what else to check.