wishie

Ok, thanks for the input. I ended up disabling the cache for that share and doing the transfer.. that reminds me.. I should re-enable the cache for that share now.

So I'm about to start copying a fairly large amount of data (around 2TB) to my unRAID server, and it has a 128GB SSD for a cache drive. My question is: Should I leave the cache drive enabled? Once its filled the cache drive, will unRAID automatically start writing directly to the array, or will it error with a 'disk full' message or something? Or am I better off disabling the cache and writing directly to the array, albeit at a much slower rate?

Yeah, this is going to be based on an i3-7100 which im quite sure has the new AES instruction set.

So the best solution would be a modem/router/switch that can run the VPN server itself I guess.. I am going to nee to make this remote access as easy for these guys as possible (they are mostly 50+ yr old women with not much computer experience) For the cloud backups, ill look into backblaze and duplicati. Thanks

Hi all, I've recently been asked to set up a 'file server' for a small business. They were originally going to use a laptop with an external usb hard disk as their solution. I've talked them into setting up an unRAID machine to store their documents instead, which is good. But, as we know, while unRAID helps with hardware failures, it is NOT a backup. So, I've been thinking about how to also store their data in the cloud. Things like CrashPlan Pro etc look promising. Are there any other services I should also check out? Also, another requirement they have just hit me with, is remote access to the files on the machine. They want several committee members to be able to connect remotely to open/edit/delete files (hopefully) using the same username/password system that unRAID already employs across user shares. Is there a handy way to do this, or is using a VPN (will be a pain to setup and configure on end users machines) the only real way to go? Any advice and help appreciated.

51 errors in total. Not too bad.

Well, it looks like I did almost everything wrong, and you all helped me sort it out, again. Thank you very much.

Just over 2hrs in, and there have been 31 corrections.. is it fairly safe to assume these were caused by my xfs_repair on the disk itself?

Running now.. will check back in when its finished. Thanks

So simply going to the "Main" page, "Array Operation" tab and clicking "Check" ?

I tried it on the md device first. It said it was 'mountable' and 'mountable & writable' but then exited with an error: xfs_repair -v /dev/md5 xfs_repair: /dev/md5 contains a mounted filesystem xfs_repair: /dev/md5 contains a mounted and writable filesystem fatal error -- couldn't initialize XFS library So I stopped the array, and ran it on the actual device. Nothing ended up in lost+found (there is no lost+found on that disk)

root@wishie:~# xfs_repair -v /dev/sdd1 Phase 1 - find and verify superblock... - block cache size set to 326328 entries Phase 2 - using internal log - zero log... zero_log: head block 68262 tail block 68262 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... XFS_REPAIR Summary Fri Mar 16 11:39:12 2018 Phase Start End Duration Phase 1: 03/16 11:39:09 03/16 11:39:09 Phase 2: 03/16 11:39:09 03/16 11:39:10 1 second Phase 3: 03/16 11:39:10 03/16 11:39:11 1 second Phase 4: 03/16 11:39:11 03/16 11:39:11 Phase 5: 03/16 11:39:11 03/16 11:39:11 Phase 6: 03/16 11:39:11 03/16 11:39:11 Phase 7: 03/16 11:39:11 03/16 11:39:11 Total run time: 2 seconds done

Ok, so rebuild finished, 0 errors. Does this mean I got away with it?!

Yeah, I should have mentioned, check power and sata cables first.. replace if you think you need to. I did all of that, but mine ended up being the power supply not providing nice clean power when all disks spun up for a parity check.

lots of this in syslog: Mar 10 00:53:14 unRAID kernel: sd 4:0:2:0: [sdd] tag#1 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Mar 10 00:53:14 unRAID kernel: sd 4:0:2:0: [sdd] tag#1 Sense Key : 0x2 [current] Mar 10 00:53:14 unRAID kernel: sd 4:0:2:0: [sdd] tag#1 ASC=0x4 ASCQ=0x0 Mar 10 00:53:14 unRAID kernel: sd 4:0:2:0: [sdd] tag#1 CDB: opcode=0x8a 8a 00 00 00 00 00 74 70 8e 38 00 00 00 08 00 00 Mar 10 00:53:14 unRAID kernel: print_req_error: I/O error, dev sdd, sector 1953533496 followed by lots of: Mar 10 00:54:06 unRAID kernel: md: disk0 write error, sector=2091053720 Mar 10 00:54:06 unRAID kernel: md: disk0 write error, sector=2091053728 Mar 10 00:54:06 unRAID kernel: md: disk0 write error, sector=2091053736 Mar 10 00:54:06 unRAID kernel: md: disk0 write error, sector=2091053744 Mar 10 00:54:06 unRAID kernel: md: disk0 write error, sector=2091053752

I'm no expert, but it looks like a bunch of 'drive not ready' errors, followed by a heap of write errors.. I had a similar issue a while back, and in my case, it ended up being a power supply issue.. did your system recently try to do a parity check by chance?

So back to this: mdcmd set invalidslot 5 29 I get that 'invalidslot 5' likely tells unRAID that the disk is 'invalid' and perhaps should be rebuilt.. but what does the '29' mean?

At this stage, the data of disk 5 is being 'emulated' by the parity, right? So I should be able to use the system? My kids are bugging me to turn on Plex.

Yeah, been on 6.4.1 for ages.. never had that issue before. Will check flash drive.

Ideally, I should have a spare disk on hand for these moments, so I can replace straight away.. any idea why I lost my configuration when I rebooted the server?

Well I assume so, since its rebuilding.. 'mount' shows: /dev/md5 on /mnt/disk5 type xfs (rw,noatime,nodiratime)

Can you explain the: mdcmd set invalidslot 5 29 for me please

Ok, done that, and it appears to be rebuilding..

Here are the diagnostics. wishie-diagnostics-20180315-2018.zip

FWIW, the 'failed' drive is now only being recognised (in an external dock on another machine) as an 'uninitialised 4.14Gb' disk