Jump to content

ratmice

Members
  • Content Count

    313
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ratmice

  • Rank
    SubGenius
  • Birthday 08/28/4

Converted

  • Gender
    Undisclosed
  • Location
    West O' Boston
  • Personal Text
    Give me slack!, or give me death.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. OK, thanks. I think I will just not tempt fate and leave everything alone until the new controllers get here. That should be an adventure, as well. O_o
  2. So, one last question, now that the repair has proceeded, and lots of items placed in Lost + Found, indicating, I think, that there was a lot of corruption, should i bother to try mounting it? or, will that screw up things when I go and try to rebuild the disk. My thinking here is that if it is actually mountable, then unraid will think that it's current state is what it's supposed to be and adjust parity accordingly, thus giving me a screwed up rebuild. As it is it appears that the emulated disk works OK.
  3. That's what I thought, i can wait a few days for the controllers to arrive. Here goes nothing Thanks again.
  4. So, I attempted to run xfs_repair and got this output, seems like the disk is really borked. However is there a way to attempt mounting a single disk while in maintenance mode, or is starting the array and having it choke on this disk enough to just jump to ignoring the log while repairing? I am too *nix illiterate to know this. root@Tower:~# xfs_repair -v /dev/md17 Phase 1 - find and verify superblock... - block cache size set to 349728 entries Phase 2 - using internal log - zero log... zero_log: head block 449629 tail block 449625 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Also, 2 new controllers on the way. If this attempt to repair disk17 is unsuccessful, would the best course of action be to shut down the array, install the new controllers, and then try to rebuild disk 17 to a new drive? or would it be OK to do that now?
  5. Thanks for the prompt reply. As always, Johnny, you are a superb asset to the forums. I am going to replace the controllers ASAP. I currently have a SuperMicro X8SIL-F motherboard. looks like I'm limited to x8 PCI-e cards (but it seems the SASLP are x4 cards). Any recommendations for direct replacements for the SASLP controllers? seems like: LSI 9211-8i P20 IT Mode for ZFS FreeNAS unRAID Dell H310 6Gbps SAS HBA might be a reasonable replacement, I'm just a bit fuzzy on the bus/lane deal. Are there more stable, proven replacements that have the SFF-8087 SAS connector so I can just plug and play?
  6. Here are the post-reboot diagnostics. Also the disabled dis has a note that it in "unmountable: no file system". Not sure if that is SOP for disabled disks, or not. tower-diagnostics-20200625-1540.zip
  7. Unraid - 6.7.2 So I woke up this morning to an array that has a disabled disk (single parity system) and seven disks all with millions of read errors. The array isn't mounted, and is unreachable from the network. In the shares pane only the disk shares are showing up, none of the other shares. I pulled a diagnostic report (attached below), and now wonder what the safe thing is to do. I did start a read test as indicated on the main page, but paused it almost immediately, not knowing if it would screw things up. Last night I rebooted the server, as I was having some trouble with the TV system, as well. All seemed OK, and Plex was able to rescan the TV shows to find some new items that had been added. Watched a couple of episodes, and went to bed. My inclination is that I need to shut it down and check cabling, reseat controllers, etc... as that seems the most likely cause for millions of read errors all of a sudden, but I don't want to do anything that might compromise the system. I need to figure out if all the disks are on the same controller, but need to shut it down to get at the disks to see. In poking through the forums, this morning, I see that Marvell controllers can be an issue, so I assume it's due to one of those. The trouble appears to start around 5:59 in the log, and there are indications that the controller is the issue. I am woefully deficient at understanding these logs, however. This server has been running faithfully for many years, with the current HW, just FYI. Also, I am assuming that the system disabled that one particular disk just because it can only do one with single parity, and it randomly chose it when the array crapped out. Additionally, the system log tool has only one entry: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 134115360 bytes) in /usr/local/emhttp/plugins/dynamix/include/Syslog.php on line 20 Any help in how to proceed would be greatly appreciated, I am not very knowledgable about the deep inner working of the UnRAID system, and Linux, in general, but I am a quick learner. Hopefully some of you forum denizens will be able to help me out and point me in the right direction. Thanks for listening. tower-diagnostics-20200625-1429.zip
  8. Thanks again Johnnie. Just to be extra clear (paranoid) the UnRAID managed device number should always be the same as the disk number, correct? So if I need to zero disk 16, I would use md16. Sorry for the cluelessness.
  9. OK, so back again. I am trying to use the 'clear array drive' script in order to shrink my array. I added a drive to the array earlier today and shortly realized that another drive was acting up. I am in the process of trying to remove the newly added drive by the clear drive and then redeploy it for the dodgy drive to be rebuilt. When I run the script, it finishes instantly and the folder 'clear-me' still remains on the drive in question. This drive was only added to the array and formatted (to do so) so does not have any data on it. I don't see any pesky hidden files, so I am wondering how to get it to zero the drive?
  10. Thanks, Johnnie. You always seem to be around to answer these questions and I really appreciate it. Have a great day.
  11. Thanks for the explanation. Also, what happens if I screw up the exclusion/inclusion thing?
  12. Thanks. Just one stupid question, where the clear and remove option says "Make sure that the drive you are removing has been removed from any inclusions or exclusions for all shares, including in the global share settings." Does this apply to settings that are set to "all", as well. SO basically just change all the inclusions and exclusions to "none".
  13. So, I had a precleared disk laying about and decided to add it to a open slot in my array. No problem there, it formatted and I was off to the races. However, just after (of course), I noticed one of my older disks is showing signs of age. Is there an easy (safe) way to remove that newly added, empty disk and just rebuild the dodgy disk onto it without having to rebuild parity. Nothing has been written to the array since adding the new disk.