• Content count

  • Joined

  • Last visited

  • Days Won


RobJ last won the day on March 21

RobJ had the most liked content!

Community Reputation

34 Good


About RobJ

  • Rank
    The Cat in the Lime Hat
  • Birthday


  • Gender
  • Location
    Tampa, Florida
  • Personal Text
    Epox MF570 (nForce570)
  1. The SMART reports look OK, no obvious major issues, but a few are a little suspicious, show some wear and age. The parity drive is one I suspect may be close to having issues, because the seek error rate has dropped below average. The very old Seagates with over 60000 hours could also be wearing out, although their SMART numbers look OK. Several of the WD Reds seem to have a very long test time, *might* be a problem. What I recommend is try the Drive performance testing tool. Download the script to your flash drive and run it. Defaults are fine.
  2. Earlier, you executed the command as /dskt, indicating it was in the root, but that error says it's not there any more. Did you reboot? If so, it's gone, and you'll need to download another copy to the flash drive.
  3. The parity check ran for 12 hours, between 9:30 and 9:30. That's 4 hours per terabyte, which is too slow. It's normally 2 to 3 hours per terabyte, 2 or less for fast drives, and 3 for very slow drives. It's time to check the SMART reports for all of the drives, plus run a drive performance test using the disk_speed script. The syslog does not show any relevant errors at all. Instead of the syslog, we usually want the diagnostics, which includes the syslog plus all of the SMART reports and a lot more.
  4. Also, you have IDE emulation turned on for your onboard SATA drives. When you next boot, go into the BIOS settings and look for the SATA mode, and change it to a native SATA mode, preferably AHCI if available, anything but IDE emulation mode. It should be slightly faster, and a little safer. You have Disk 4 and Disk 5 on the same IDE channel, at limited speed.
  5. This looks like it might be an old issue returned, involving extended attributes and AFP. I'm guessing you have accessed this drive over AFP at some point? Read the discussions and fixes found in these threads: A "mover" issue? (Mover uses rsync too) Running mover does not successfully move items Extended Attributes Fix
  6. The reason I asked for diagnostics was there were so many things wrong with the file system structures, that I was afraid that either he had tried to repair the drive instead of the partition (sde instead of sde1 or md4), or it wasn't an XFS drive, but a drive with a similar file system, enough to find file system pieces and try to construct an XFS file system. I'm afraid the damage is so severe that it's too much for the current xfs_repair, and it's crashing. I really hope you have a backup for the data. I'm a bit intrigued by your statement of a 19 day old parity copy, but didn't understand what you mean by that. Is that a *separate* disk that you can put back in? And was Disk 4 fine at that time? What exactly do you have from 19 days ago?
  7. unRAID is an all RAM based OS, built from scratch each time it boots, so the unRAID boot flash drive provides both the copies of the distro to be expanded into RAM, plus the 'persistent storage' for all configuration and logging, in /boot/config and /boot/logs. Other user scripts and programs are generally also stored on the flash, although could be on a Cache or array drive if not needed until after array start. Probably best to move it back to the flash drive: mv /dskt /boot Then to run it, you would either run: /boot/dskt ... Or: cd /boot dskt ...
  8. Sorry, I didn't see that 68 or the "in the past". Good catch, Brian. 194 can be taken literally, 190 is "one hundred minus", so the 076 means it's currently 24C, the 045 means a max of 55C, and the 032 means it once reached 68C, well over 55C. I would Preclear it 3 times at least, and see if it holds up. If it does, then it survived the over-temp. I'd still monitor it for awhile.
  9. Please see Need help? Read me first!, and attach the diagnostics zip.
  10. Looks fine. If the 'Power on hours' of 1458 can be trusted (is it a refurb?), it's a young drive in good condition.
  11. I'll start by giving some background on the current wiki method, and then touch on a few things you may not have thought about. I had noticed already several users using unBALANCE, and had been thinking about adding a method based on it, but I won't be able to completely flesh out the steps as I've never used unBALANCE, and can't because I don't use User Shares (which of course partly explains my own methodology). I've always preferred knowing and controlling exactly where everything is, and I've a personal catalog file I keep open in an editor tab with all of my series and categories listed, with the drives they're on. For example, I know that my Alias shows are on Disk 1, and all my PBS stuff is on Disk 4. User Shares are convenient for many, but for me it just adds another layer to the access. Off-topic though ... But converting drives is a drive issue, only indirectly a User Share issue. It's drives that are formatted, and that dominates the problem. I don't know for sure, but I suspect if you wrote out the steps for doing the entire array with unBALANCE, it would be close to 19, or maybe even more. A general method for users at large has to handle every contingency and every situational variation, as safely as possible for the least technical of users. That always takes longer, and often more steps are involved, 'just in case'. It inevitably means lots more words! I do think my method is the most straightforward, safest, and fastest though, but then disk shares is what I work with and understand. It does have an extra step or two to accommodate User Shares. For User Share users, which is most or almost all unRAID users, unBALANCE sounds attractive, and I agree that it's a great plugin! It uses basically the same rsync command, so should have the same speed and file verification checksumming for the individual transfers. But in operation over multiple drives, it's likely to take longer, because it's moving the files off one drive to the others, then moving the files back when you do the next drive, and possibly moving some files multiple times, pushing them around the various drives to keep them out of the way of the next format operation. With my method, files only move once. The only way to make sure no files get moved more than once with unBALANCE is to carefully manage exactly where each file starts and where it ends up, and that sounds like something you wanted to avoid, if you don't want to care where the files are. To me, my method seems just as seamless, and allows full operation just as much. Both ways, you have to stop the array, make changes, then restart the array, just as many times. When I did it with 6.1, I didn't have to use New Config, just adjust the assignments and restart the array. Unfortunately in 6.2, something changed and it won't allow that, so we had to add the New Config step, which I agree does add a little extra hassle. 6.0 and 6.1 users don't have to do that. We have requested that to be corrected, so we can just restart the array, but as far as I know, it hasn't happened yet (haven't checked it recently though). The strong cautions though are just as important, for either method! How do you know for sure that there were not files lost when you did it? Because if there were any other processes (internal plugins, Dockers, scheduled scripts, or VM's, or externally scheduled backups) writing files to the array, they could very well have added files to the very drive you were emptying with unBALANCE. In fact, the emptying of a shared drive makes it the most attractive target for writing new files to. Either you make absolutely sure that nothing else could be writing to the array, or you should run unBALANCE a final time, just to make sure that nothing is left on the drive (written to it after unBALANCE had swept across it), before you format it. Does unBALANCE after moving folders come back and check if they have reappeared on that drive, with more files in them? So I'll add a general unBALANCE-based method, and I think many users may prefer it, as it does hide some of the detail, but it will take longer to perform. And they will have to manually configure unBALANCE for each drive emptying. The steps will have to have just as many warnings. Users who aren't running anything else at all will obviously have a simpler time, can ignore the warnings, but that's a special case. I really don't want any of this to be daunting or nerve-wracking, but each time we hear of a user doing something we hadn't thought of and getting into trouble, the word count increases. The more words, the more daunting it appears ... (just look at this post for instance!)
  12. To fully understand what's happening, we would need to see both diagnostics, one where it's seen and one where it's not seen. Then we can see what the kernel is seeing (or not seeing). You will also want to make sure it's seen by the BIOS at bootup.
  13. In this case, the yellow is a false positive, nothing wrong, although it's a little odd. Some devices need a kick to initialize them, a hard reset to start them up. You won't see any speed degradation with only one drive attached.
  14. Please see Why do I see csrf errors in my syslog?
Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.