AlphaBravo

Members
  • Posts

    47
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Location
    The Netherlands

AlphaBravo's Achievements

Rookie

Rookie (2/14)

0

Reputation

  1. Long time user, built my original unraid box (version 4.7, upgraded all the way to current on the same USB stick)) 11 years ago and finally upgraded/migrated from that original hardware to new mainboard/cpu/disks last week. All that time, I haven't been using a cache pool as such, I did have a pool named cache, and I have my docker persistent files there in /mnt/cache/.appdata (not sure how that came to pass, but it's been working for me). With the new build, I figured I'd gradually move my dockers over to use the proper appdata share, starting with a new one. Appdata is set to Prefer, but when I add a new docker using the appdata share, it puts everything on the array instead of on cache. Also, when I run the mover manually, I get a syslog message "Mover: cache not enabled". Clearly something's wrong with my config, but I'm unable to figure out what. I've attached the diag zip, hope someone will be able to shed some light. *edit* Some steps I've already tried: - Rebooted - Unassigned the cache drive from the pool, started then stopped the array, assigned the drive, started the array - Set all shares cache option to 'no', removed the cache pool and recreated it, then set the appdata share to 'prefer' again. I've also had some weirdness replacing the cache drive (upgraded from a sata ssd to an m.2 nvme). As per the faq, I removed the ssd from the pool and added the nvme, but nothing happened that I could see when I started the array. The stop array button also wasn't disabled (I don't confidently recall if I was seeing any read/write activity on either the old or the new cache drive), so I stopped the array. When I swapped the ssd back in and started the array, it complained about an unreadable filesystem. Had to recover the contents with 'brtfs restore'. garfield-diagnostics-20221105-1908.zip
  2. I guess you managed to convince me I'll just need to think of a way to automate this, as most of the stuff that would suck if I'd lost it is placed onto the array automatically (sickbeard, mostly). Perhaps I could somehow hook into the mover script
  3. I hear what you're saying about backups, and I can't say I disagree, but at the same time I'm unsure if I'm prepared to spend the dough on and extra set of storage for backup purposes. Maybe a subset. Guess I'll browse your post history to get an idea of how you've approached the actual process, if you feel so strongly about it I'm sure you've posted your setup more than once As for my situation: the rebuild completed overnight and everything looks ok, no errors at all in syslog. Of course, the previous two times things ran for about a day before something started failing, so I'm not celebrating just yet Only thing I'm not too sure about now is if I should run an fsck against disks 7 and 8 (and maybe even all others?) Even without any crashes normal linux filesystems tend to run an automatic fsck every so many days or mounts, but UnRAID so far hasn't done any as far as I can tell...
  4. You're correct, I don't have backups. It is simply too much (and not nearly important enough) to backup effectively, although it would of course still suck if I'd lost it My worry about rebuilding disk8 from parity is that I'm not sure parity is valid. But I suppose if I replaced the disk, I would still have the data on it and the only disk affected by the rebuild would be disk8. I'll probably know soon enough if the parity turns out to be invalid because that'll likely leave me with an unreadable (or at least very corrupted) disk8. Your advice seems sound, I guess I was overthinking it, thanks As for the reason it got red-balled, I'm reasonably sure it's because of controller/cable fault, not drive fault. Still, there too your advice is sound. I'll just grab the old parity 2TB that has just finished pre-clearing with no errors, let unRAID work its magic and shelf the current disk8 as fall-back.
  5. Sorry for the slow response, life got in the way. Thanks for the confirmation, I've replaced the cables. Now when I boot the system, I still have a red ball for disk8, all other disks are green and all are in the correct positions according to my pre-5.0 screenshot. smart output for disk8 reports all's well, short self test completes without error. Right now, I'm not entirely sure how to proceed. Here's what I'm thinking the current state is: - All data drives are probably (mostly) intact, disk7 and disk8 might have some filesystem corruption, but nothing fsck won't be able to fix; - Because of the dual disk failure (and possible writes to the array after this happened), I'm going to assume parity is invalid. As per Joe's response in this thread, I'm thinking initconfig might be the way to go for me as well, assuming that will automatically mark the red balled drive blue as well. I also need to run an fsck against at least disk7 and disk8. Should I do this after I start the array, or would it be better to run it against /dev/sdd1 outside of the array? I'm thinking stressing the drive before starting the array may also give an indication of its stability. Any guidance will be much appreciated One thing's for sure: had this been a traditional raid, my life would've been a lot simpler by now: I'd just have to redownload all 26TB that's on the array (needles to say, I'm quite happy with unRaid ) syslog.txt
  6. Been happily running unRaid for a bit over two years now, stuck with 4.7 because I never felt the need to upgrade to >2TB drives. My hardware specs are in this post, all unchanged except for some drive changes (most of the EADS and some of the EARS drives have been replaced with WD Red 2TB EFRX drives). Last friday, I finally upgraded to unRAID 5.0 and on saturday I upgraded my parity drive to a 4TB WD Red (which, I should add, involved opening the case, unplugging that drive and pushing some other cables aside). Sunday early morning, I found two drives missing with a bunch of errors in the syslog. After some reading, digging and searching, I figured it was a cabling issue, and indeed after reseating the offending cables, things seemed happy again (well, except for the parity drive which completely lost track of things with the two failed drives). However, today, after about 22 hours uptime, the same drives started acting up again. Syslog shows things like this: Oct 7 13:51:56 garfield kernel: ata4: exception Emask 0x10 SAct 0x0 SErr 0x180000 action 0x6 frozen Oct 7 13:51:56 garfield kernel: ata4: edma_err_cause=00000020 pp_flags=00000001, SError=00180000 Oct 7 13:51:56 garfield kernel: ata4: SError: { 10B8B Dispar } Oct 7 13:51:56 garfield kernel: ata4: hard resetting link Oct 7 13:51:57 garfield kernel: ata4: SATA link down (SStatus 0 SControl 310) Oct 7 13:51:57 garfield kernel: ata4.00: link offline, clearing class 1 to NONE Oct 7 13:51:57 garfield kernel: ata4: hard resetting link Oct 7 13:51:58 garfield kernel: ata4: SATA link down (SStatus 0 SControl 310) Oct 7 13:51:58 garfield kernel: ata4.00: link offline, clearing class 1 to NONE Oct 7 13:51:58 garfield kernel: ata4: hard resetting link Oct 7 13:51:59 garfield kernel: ata4: SATA link down (SStatus 0 SControl 310) Oct 7 13:51:59 garfield kernel: ata4.00: link offline, clearing class 1 to NONE Oct 7 13:51:59 garfield kernel: ata4.00: disabled Oct 7 13:51:59 garfield kernel: ata4: EH complete Oct 7 13:51:59 garfield kernel: sd 4:0:0:0: rejecting I/O to offline device Oct 7 13:51:59 garfield kernel: sd 4:0:0:0: [sde] killing request Oct 7 13:51:59 garfield kernel: sd 4:0:0:0: rejecting I/O to offline device Oct 7 13:51:59 garfield kernel: sd 4:0:0:0: [sde] Unhandled error code Oct 7 13:51:59 garfield kernel: sd 4:0:0:0: [sde] Oct 7 13:51:59 garfield kernel: Result: hostbyte=0x01 driverbyte=0x00 Oct 7 13:51:59 garfield kernel: sd 4:0:0:0: [sde] CDB: Oct 7 13:51:59 garfield kernel: cdb[0]=0x28: 28 00 48 7b 86 18 00 01 e0 00 Oct 7 13:51:59 garfield kernel: end_request: I/O error, dev sde, sector 1216054808 Oct 7 13:51:59 garfield kernel: md: disk8 read error, sector=1216055232 Oct 7 13:51:59 garfield kernel: ata4.00: detaching (SCSI 4:0:0:0) Oct 7 13:51:59 garfield kernel: md: disk8 read error, sector=1216054744 Oct 7 13:51:59 garfield kernel: md: disk8 read error, sector=1216054752 and similar for ata3/disk7. Full syslog obviously attached. At some point, both drives (which were /dev/sdd and /dev/sde) get re-detected as /dev/sds and /dev/sdt. After yesterday's incidents, I ran fsck on both drives and everything seemed in order. Also, smart doesn't show any problems for either drive (or at least as far as I can tell), so for now I'm going to assume the drives are fine. But then what is the issue here? My initial hunch was cabling, and messing with the relevant cables did seem to solve the problem briefly, but it returned today. My current list of candidates for causing this problem, in order of likeliness: 1. SATA cables (moving them about after they've been in the exact same position for 2+ years may have harmed them) 2. Controller issues - both troublesome drives are connected to the same Adaptec, I'm not quite sure why this would start acting up now though 3. Icy dock trouble - both drives sit next to each other in the same dock Based on the syslog and smart output (all smart outputs are mashed together in a single file), does anyone have any other ideas/suggestions? Oh, there's one drive that has some serious issues: /dev/sdo, which is my cache drive. Also noticed this yesterday, so that drive is obviously now also up for replacement but not currently my biggest worry, as you can imagine syslog.zip 20131007_smart_summary.txt
  7. My write speed to the cache drive (WD Green 2TB) is in the 80MB/sec range using samba. Haven't used NFS a lot, so no figures there. When I wasn't using a cache drive yet, writes to the parity protected array ran at about 25MB/sec.
  8. My experience with NFS on UnRaid hasn't been great either. I decided to not waste any time and instead just apt-got smbfs on the linux clients and mounted stuff that way Add the following line to /etc/fstab: //tower/data /data smbfs noatime,nodiratime,username=anything,password=,uid=1000,gid=1000 0 0 where //tower/data obviously is the sharename on UnRaid and /data is the mountpoint. The uid and gid options are required to make the mount userwritable (1000 is the uid for the default user on ubuntu and debian, if you use a different distro, use id to verify)
  9. Shouldn't be a problem, only downside is that the parity check will take longer (but I don't care about that, that check can run all night while i want to watch that movie now )
  10. I think that would only work when you set the user share to split level 0 (the special case). You'd then need to create the Zappiti directory only on the SSD and the Movies and TVSeries directory on all other disks you want to include. Keep in mind that writes to any disk in the array will still require writes to the parity disk as well, so you'll always be waiting for that even when writing to the SSD. I'm not entirely sure when split level 0 was introduced, you may need to upgrade.
  11. No idea on the first question, but.. 2. Single writes to the parity protected array are as fast as the slowest drive, if you're doing writes to multiple data disks at once, a fast parity drive may have some benefit. On the other hand, if you're adding a cache drive as well, writes to the array happen during offhours anyway, so write speed probably isn't an issue at all then. Speed of the cache drive is completely unrelated, a faster cache drive will give faster writes to the shares. 3. The image and articlecode suggest that it's a boxed cpu, so that includes everything to mount it on the mainboard, including the fan. Boxed cpu's (at least the Intel ones, haven't touched amd for years) come with thermal paste attached to the heat sink.
  12. The seagates are 7200rpm so they'd naturally run a bit hotter than the greens that run at 5500ish, although 45 is about as high as you'd ever want it to go. Are you sure they're receiving the same airflow?
  13. EADS drives seem to easily run up to that temperature. I have 7 of them in my raid and during parity check they're all in the 40-42 range. Doesn't seem to harm them and spec sheet says they're rated up to 60C. If the temperatures are stable at 41ish, I wouldn't worry about it too much.
  14. I added the following to /boot/config/go: echo "export TERM=xterm" > /root/.bashrc This seemed to fix most issues I encountered.