Ezro Posted July 10, 2017 Share Posted July 10, 2017 Hi everyone, One of my (unused) drives went down over the weekend. It was sharing a cache drive with the rest of my array, but nothing else was put onto the drive. After I restarted unRAID, I haven't been able to even see the drive listed anywhere. I want to take it out of the system completely, but can't seem to figure out how. Also, I think because of the failed drive, it's telling me that my whole array is now unprotected. What steps should I take to remove the Not Installed drive from my array? Link to comment
SSD Posted July 10, 2017 Share Posted July 10, 2017 It is pretty rare for a drive to just die - like a light bulb. Not impossible, but rare. It is much more common that a drive would drop offline due to a bad or loose cable. If the disk was part of your array - then unRAID would be simulating that disk. So when you try to access the drive, behind the scenes unRAID is reading from parity and all of the other disks to dynamically reconstruct the requested information. Pretty slick to see it in action, actually. But when you are simulating a disk, your system cannot handle a second disks failure. If a second drive were to fail, your simulation would end and your array would go offline. That is why the system is telling you it is unprotected. It is doing all the protecting it is able with a single parity disk. You have two ways forward - one is to either fix the connection with the drive that dropped offline, or use another drive as big or bigger than that disk, to rebuild the disk that was dropped. The second is to do a new config, and redefine your array sans that disk. The second option would result in all of that data on that dropped disk to be potentially** lost. If any of that data is needed, you can copy it from the simulated disk to another disk, to cache, or even to a Windows workstation BEFORE you do a new config. Normally a person would rebuild the disk. But you seemed to be saying that it was not a disk you were using. ** I say potentially, because the disk that dropped may in fact be fine, and you would still have that disk and be able to mount it outside the array and access its data. Any data added to the disk as it was being simulated would be lost. Link to comment
Ezro Posted July 11, 2017 Author Share Posted July 11, 2017 14 hours ago, bjp999 said: It is pretty rare for a drive to just die - like a light bulb. Not impossible, but rare. It is much more common that a drive would drop offline due to a bad or loose cable. If the disk was part of your array - then unRAID would be simulating that disk. So when you try to access the drive, behind the scenes unRAID is reading from parity and all of the other disks to dynamically reconstruct the requested information. Pretty slick to see it in action, actually. But when you are simulating a disk, your system cannot handle a second disks failure. If a second drive were to fail, your simulation would end and your array would go offline. That is why the system is telling you it is unprotected. It is doing all the protecting it is able with a single parity disk. You have two ways forward - one is to either fix the connection with the drive that dropped offline, or use another drive as big or bigger than that disk, to rebuild the disk that was dropped. The second is to do a new config, and redefine your array sans that disk. The second option would result in all of that data on that dropped disk to be potentially** lost. If any of that data is needed, you can copy it from the simulated disk to another disk, to cache, or even to a Windows workstation BEFORE you do a new config. Normally a person would rebuild the disk. But you seemed to be saying that it was not a disk you were using. ** I say potentially, because the disk that dropped may in fact be fine, and you would still have that disk and be able to mount it outside the array and access its data. Any data added to the disk as it was being simulated would be lost. I agree with it being rare. That's why I don't really believe that it failed. My next step is to unplug it and put it in an external enclosure for testing on a different machine. In the meantime, though, is there no way to just... drop the drive from the array? I don't have a replacement drive yet, and I plan to add the "failed" drive back once I verify that it's working and format it. If another drive goes down, though, I don't want to risk losing my whole array... Link to comment
SSD Posted July 11, 2017 Share Posted July 11, 2017 3 minutes ago, Ezro said: I agree with it being rare. That's why I don't really believe that it failed. My next step is to unplug it and put it in an external enclosure for testing on a different machine. In the meantime, though, is there no way to just... drop the drive from the array? I don't have a replacement drive yet, and I plan to add the "failed" drive back once I verify that it's working and format it. If another drive goes down, though, I don't want to risk losing my whole array... Arg! This question implies a very basic lack of understanding of how parity works. In short, pulling a drive affects parity. The three options are ... 1 - Pull the drive and let unRAID continue to simulate the missing one. You are susceptible to another drive failure. I'd do this for only a short time (e.g., a week). 2 - Pull the disk, do a new config, reassign the drives you want to stay in the array, and rebuild parity. 3 - Replace the disk with a functioning drive, and let unRAID rebuild it. Doing anything else will result in a useless parity. HERE is a short wiki on parity that I suggest you read. I can't tell you how many unRAID potholes you will avoid by reading just a small portion of it. Link to comment
Ezro Posted July 11, 2017 Author Share Posted July 11, 2017 10 hours ago, bjp999 said: Arg! This question implies a very basic lack of understanding of how parity works. In short, pulling a drive affects parity. The three options are ... 1 - Pull the drive and let unRAID continue to simulate the missing one. You are susceptible to another drive failure. I'd do this for only a short time (e.g., a week). 2 - Pull the disk, do a new config, reassign the drives you want to stay in the array, and rebuild parity. 3 - Replace the disk with a functioning drive, and let unRAID rebuild it. Doing anything else will result in a useless parity. HERE is a short wiki on parity that I suggest you read. I can't tell you how many unRAID potholes you will avoid by reading just a small portion of it. Ah, I think I understand it better now. Please correct me if I'm misunderstanding the options: If I did option #2, it'd take a long time and would effectively be rebuilding my whole parity drive using all of the existing drives, minus the failed on; in doing that, I wouldn't lose any data on my current drives, but I'd still have to go through the motions when I want to add a new drive to replace the failed one. With option #3, I'd be replacing the failed drive, and rather than rebuilding the parity drive I'd be rebuilding the missing data using the existing parity drive + the rest of the array. Is it safe to assume that option 3 would be a faster operation than option 2? Link to comment
SSD Posted July 11, 2017 Share Posted July 11, 2017 Why would you think one would be faster? If you think about it, building parity or building a data drive - its the same thing from unRAID's perspective. It reads blocks from all of the drives except the one its writing, it computes the value based on having even parity on every bit, and then it writes the block to the drive being written. Repeat for all the blocks. If the data drive is smaller, it should go quicker. But if they are the same size - should take the same amount of time. BUT - if you are thinking about it more globally, and the long term plan is to add that drive back in, you'd save time doing it just once the first time. But parity does not take that long to build. So I would do what you need to do to have your array protected. I do not think researching your issue with the dropped disk would take very long. Could be as simple as a bad or loose cable. I'd check that out, and if the smart report looks good and you are able to bring the drive back online after re-securing both ends of its cable, I'd likely just rebuild that disk onto itself and be done. Link to comment
trurl Posted July 11, 2017 Share Posted July 11, 2017 2 minutes ago, bjp999 said: I do not think researching your issue with the dropped disk would take very long. In fact, just go to Tools - Diagnostics and post the complete diagnostics zip and we may be able to give you a better idea of the best way to proceed. Link to comment
Ezro Posted July 12, 2017 Author Share Posted July 12, 2017 4 minutes ago, bjp999 said: Why would you think one would be faster? If you think about it, building parity or building a data drive - its the same thing from unRAID's perspective. It reads blocks from all of the drives except the one its writing, it computes the value based on having even parity on every bit, and then it writes the block to the drive being written. Repeat for all the blocks. If the data drive is smaller, it should go quicker. But if they are the same size - should take the same amount of time. BUT - if you are thinking about it more globally, and the long term plan is to add that drive back in, you'd save time doing it just once the first time. But parity does not take that long to build. So I would do what you need to do to have your array protected. I do not think researching your issue with the dropped disk would take very long. Could be as simple as a bad or loose cable. I'd check that out, and if the smart report looks good and you are able to bring the drive back online after re-securing both ends of its cable, I'd likely just rebuild that disk onto itself and be done. That makes sense. I've also noticed that my Plex library has been acting odd (thumbnails go missing and Agent settings reset after a seemingly arbitrary amount of time). Do you think this could be related to the "Mover" running? I'm not too familiar with what that is doing, and what operations it could be running. My reasoning is that if it's touching the Plex appdata folder, it could be triggering something within the docker container. Link to comment
SSD Posted July 12, 2017 Share Posted July 12, 2017 trurl has a good suggestion! I doubt that your Plex would be impacted by the mover. If you appdata share is not cache only, it could cause issues. Link to comment
Ezro Posted July 12, 2017 Author Share Posted July 12, 2017 5 minutes ago, trurl said: In fact, just go to Tools - Diagnostics and post the complete diagnostics zip and we may be able to give you a better idea of the best way to proceed. I've attached the zip download for review. tower-diagnostics-20170711-1703.zip Link to comment
Ezro Posted July 12, 2017 Author Share Posted July 12, 2017 1 minute ago, bjp999 said: trurl has a good suggestion! I doubt that your Plex would be impacted by the mover. If you appdata share is not cache only, it could cause issues. I have my AppData Config Path pointing to /mnt/cache/appdata/PlexMediaServer/ currently. My appdata share itself, though, uses all drives + cache. Do you think I should create a share specifically for the Plex appdata, using only the cache disk? Link to comment
SSD Posted July 12, 2017 Share Posted July 12, 2017 You can change the appdata share to be cache only. I believe that the mover would then move it to the cache drive and leave it there. Link to comment
trurl Posted July 12, 2017 Share Posted July 12, 2017 58 minutes ago, bjp999 said: You can change the appdata share to be cache only. I believe that the mover would then move it to the cache drive and leave it there. No, mover will move cache-prefer shares to cache. Cache-only shares are never moved. Link to comment
trurl Posted July 12, 2017 Share Posted July 12, 2017 I don't see SMART for the missing disk, so you will have to try to fix its connection and post another diagnostic. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.