DanTheMan827

So, I was installing a brand new 4TB drive into my NAS and one of the screws broke off in the mounting hole of the hard drive... I made sure that I wasn't using a ODD screw either since I know those have a different TPI The head broke off cleanly so there's no extra outside the screw hole to attempt to use a pliers to manually turn the screw out... I was thinking of using a screw extractor but I'm concerned about any potential vibrations or metal shavings... Or would I just be fine with 3 screws? I prefer to secure the drives as much as possible...

As it is right now it's very possible to pass-through a full hard drive to the VM by setting the file path to /dev/disk/by-id/<disk id here> The thing is, it's a manual process and I'd have to imagine adding a drop down box with unassigned drives would be a relatively easy thing to do

I do realize this has been asked previously but some time has passed (and versions) and I'm wondering if it's still the case... Is there any benefit to using BTRFS over XFS? It's my understanding that BTRFS has check-summing to detect data corruption. But I've also read that BTRFS has more issues with data corruption than XFS... I have some free space so I would have enough to convert to BTRFS if it is in fact a better option... But IS it a better option for anything other than future-proofing?

This is the exact same problem I have, same card and everything. In my case, the host will also occasionally hard lock when attempting to start rather than an error message. I didn't seem to have the "Device or resource busy" error if I chose OVMF over SeaBios though but there were still occasional hard locks happening randomly. For now I just pass through the individual devices but that obviously isn't ideal with the VM USB controller only being USB 2.0

That's excellent to hear! I still think just to be safe I'll run a recursive md5sum on the reconstructed and original drives... I can just put the failed drive into another computer and boot a linux live cd for hashing that right? Obviously I can run the same hash command on /mnt/disk1 after the rebuild...

To rebuild, would I then just swap the drives and then assign the replacement? Yes So, what are the chances of corrupt files given the fact that there is always light write operations going on with reconstruct-write selected? Would it drop the drive if it weren't able to read that bit from disk1 to create the new parity? or is that not how reconstruct write works?

To rebuild, would I then just swap the drives and then assign the replacement?

I plan on picking up a replacement from best buy after work but in the meantime should I stop the array and remove the failed disk from it through the web interface? That would still let the array be used but be very slow correct?

definitely lucky! I do have re-construct write on though... how would that work if a file were written to any drive position that shared the same as the bad sectors on disk1? Would it drop the drive with the read error or something else? Looks like a file checksum may still be in my future though even after I replace the disk...

Really hope I can just buy a replacement drive and drop it into the array... partially corrupted parity would not be nice... unraid-diagnostics-20161118-1520_anonymized.zip

I'm really hoping it was a non-correcting one... In my push notifications the scheduled sync says "Parity sync: started" where this one it said "Parity check started" so hopefully it's non-correcting... Avoid using disk1, reads or writes, or it may get disabled. If you need to access disk1 contents probably best. With a binary file compare utility, you can also copy all the files you can from the old disk, all files successfully copied should be OK, you should be able to copy most of them. For those you'd use the rebuilt files, hopefully there are only a few, and those would be the only suspect ones. You can't, only the schedulle scheck can be changed, if this check was after an unclean shutdown it's possible that some or all of the sync errors are from that, upload your diagnostics if you haven's rebooted yet. I prefer XFS with the checksum plugin. Yeah, I kind of need disk1 since that has the docker data... (cache is only used for a VM) It was caused by a host hard-lock when passing through a expansion PCIE USB 3 controller to the VM (not the unraid controller) Is the power loss parity scan just a check instead of a sync? if that's the case I should be fine since the drive hadn't reported any errors during my last scheduled sync operation I'm pretty sure the drive is toast though... http://i.imgur.com/ev1Xq1Z.png

You know... I just realized... it says "Parity-Check in progress" does this mean that it didn't actually write any parity? Is that the default on unclean shutdown, to check instead of sync? Would it say "Parity-Sync" if it were writing new parity?

So I could continue to use the array normally until the replacement? Or should I drop the failed disk out in the meantime? How would I compare the data between the drive and array when I replace it? recursive md5sum? Would that work if it was unable to read the data due to bad sectors? Sorry if I'm sounding very "noob" right about now... I just don't want to risk a 3TB drive worth of data that is almost full... And where do I change parity sync on power loss to parity check only? that's actually what it's running from... normally I had a sync run Monday at 4AM... (this is the first time one has ever written anything) I guess once everything is normal again I should probably re-format my disks one-by-one to btrfs (for the hashing) huh... or is there some way to convert XFS?

Couple more questions... (I don't have checksums... :'() I know it'd be risky but could I pull drive 1 and continue to run the array unprotected? (to avoid any more damage to the parity) The way I see it is I could do it one of two ways... Scan the drive in another computer to find unreadable files or rebuild the array using whatever parity data is available and then copy the contents off the drive to the while skipping unreadable files (to let me know what is corrupt) Am I right in thinking this or is there some other way to go about it? Also, any tools I should use? linux isn't really my forte so I'm learning as I go... Also, does unraid log the position that was synced during the check? Couldn't that info be used to find which file(s) are currently occupying that region of the disk (from another computer) In theory everything that wasn't synced to the parity should still be valid right?

When it says 30 sync errors, does that mean that 30 sectors were invalid or is it some other kind of size? Is there any way to find out what files would be affected? Well... the good thing is that I've been running CrashPlan so all of my most important stuff is backed up... The only things I might lose are backups of another functional computer and some other non-critical stuff... (probably a few ripped movies...) If I try copying a corrupted file from the disk share will unraid report a disk read error or attempt to reconstruct from the (probably invalid) parity? Is there any way to find out what files have the bad sectors? (probably not but it doesn't hurt to ask...)

So, disk 1 in my array appears to be toast... that's a given... The thing is, I have scheduled parity scans and it has detected and written found 30 sync errors... Does that mean that at least part of the parity data is no longer valid? I know the best option now would be to get a replacement drive ASAP but I'm not sure what to do at this point... The errors are pending / reallocated sectors so yeah... The parity sync is still running but at this point it's past the 3TB of the failing drive... Of course this couldn't have happened NEXT week... that would have been too convenient... I should also mention, I don't have a spare drive on hand...

When I pass through a PCIE USB 3.0 controller (Fresco Logic) many times when I restart the virtual machine it will fail to attach the controller and sometimes will hard-lock the host system. I currently have the controller stubbed in the syslinux boot config file. I have a hard drive, keyboard, wmc ir receiver, and some other devices occasionally plugged in to the controller. There is also a GTX 650 ti being passed through to the VM in addition to the USB 3.0 card The current VM is using SeaBios and running Windows 7 64-bit I did have another VM running OVMF that didn't appear to have this issue PCI Devices 00:00.0 Host bridge [0600]: Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] (rev 06) 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06) 00:01.1 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x8 Controller [8086:0c05] (rev 06) 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 04) 00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04) 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-V [8086:153b] (rev 04) 00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 04) 00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 [8086:8c10] (rev d4) 00:1c.4 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev d4) 00:1c.5 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #6 [8086:8c1a] (rev d4) 00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 04) 00:1f.0 ISA bridge [0601]: Intel Corporation Z87 Express LPC Controller [8086:8c44] (rev 04) 00:1f.2 SATA controller [0106]: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c02] (rev 04) 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller [8086:8c22] (rev 04) 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK106 [GeForce GTX 650 Ti] [10de:11c6] (rev a1) 01:00.1 Audio device [0403]: NVIDIA Corporation GK106 HDMI Audio Controller [10de:0e0b] (rev a1) 02:00.0 USB controller [0c03]: Fresco Logic FL1100 USB 3.0 Host Controller [1b73:1100] (rev 10) 04:00.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 41) 06:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller [1b4b:9172] (rev 11) IOMMU Groups /sys/kernel/iommu_groups/0/devices/0000:00:00.0 /sys/kernel/iommu_groups/1/devices/0000:00:01.0 /sys/kernel/iommu_groups/1/devices/0000:00:01.1 /sys/kernel/iommu_groups/1/devices/0000:01:00.0 /sys/kernel/iommu_groups/1/devices/0000:01:00.1 /sys/kernel/iommu_groups/1/devices/0000:02:00.0 /sys/kernel/iommu_groups/2/devices/0000:00:02.0 /sys/kernel/iommu_groups/3/devices/0000:00:03.0 /sys/kernel/iommu_groups/4/devices/0000:00:14.0 /sys/kernel/iommu_groups/5/devices/0000:00:16.0 /sys/kernel/iommu_groups/6/devices/0000:00:19.0 /sys/kernel/iommu_groups/7/devices/0000:00:1a.0 /sys/kernel/iommu_groups/8/devices/0000:00:1c.0 /sys/kernel/iommu_groups/9/devices/0000:00:1c.4 /sys/kernel/iommu_groups/9/devices/0000:04:00.0 /sys/kernel/iommu_groups/10/devices/0000:00:1c.5 /sys/kernel/iommu_groups/11/devices/0000:00:1d.0 /sys/kernel/iommu_groups/12/devices/0000:00:1f.0 /sys/kernel/iommu_groups/12/devices/0000:00:1f.2 /sys/kernel/iommu_groups/12/devices/0000:00:1f.3 /sys/kernel/iommu_groups/13/devices/0000:06:00.0 internal error: process exited while connecting to monitor: 2016-11-14T06:17:33.252370Z qemu-system-x86_64: -device vfio-pci,host=02:00.0,id=hostdev2,bus=pci.0,addr=0x8: vfio: Error: Failed to setup INTx fd: Device or resource busy 2016-11-14T06:17:33.252732Z qemu-system-x86_64: -device vfio-pci,host=02:00.0,id=hostdev2,bus=pci.0,addr=0x8: Device initialization failed

I could capture the current syslog but I've already restarted the system... I've also tried connecting a monitor to the system before restarting but there was no response so I couldn't take a picture of any kernel panic or copy the syslog... I guess I'll try the Fix Common Problems plugin in troubleshooting mode and post when it does it again... (unless you want the current syslog that is...)

So, my NAS seems to randomly hard lock and in the process causes my router to be non-functional for wired traffic... My guess is that when it hard locks it sends out garbage network traffic but the only "proof" I have is that when I unplug the network going to the NAS my router starts responding again... I'm running 6.2 but it has been doing this for every version I've had (stable) It's not extremely frequent (sometimes months between) Is there any log that gets saved on a crash? I have one Windows 8.1 Pro + Media Center VM with a PCIE USB card and video card passed through Docker Containers: CrashPlan FoldingAtHome mysql Bittorrent Sync Transmission BT A private NodeJS web server proxy System Specs: Model: Custom M/B: Gigabyte Technology Co., Ltd. - Z87X-UD3H-CF CPU: Intel® Core™ i7-4770 CPU @ 3.40GHz HVM: Enabled IOMMU: Enabled Cache: 256 kB, 1024 kB, 8192 kB Memory: 16 GB (max. installable capacity 32 GB) Network: eth0: 1000 Mb/s, full duplex, mtu 1500 Kernel: Linux 4.4.19-unRAID x86_64 OpenSSL: 1.0.2h

I have the same problem except I have a GTX 650ti and a i7 4770k Connected over HDMI the audio has issues and a USB PCIE card passed through also has issues