February 12, 20233 yr I recently had a sudden power outage on my server and when it came back up I had a write error to one of the drives which disabled that drive. I stopped the array, removed the drive from the array, and restarted it. I then stopped the array again, added the drive back, and restarted the array so it would rebuild. As it started to rebuild, I received a read error which caused the parity drive to disable. I assumed that that the data was toast at this point but followed the same steps as before with removing and re-adding the drive and it rebuilt correctly this time and then it recreated the parity data. This is when I noticed my current issue; as soon as I started the array I could read from the drive just fine but a short time later (typically less than 30-60 minutes but unsure of exact timing) it would no longer show the data on the drive. Clicking the icon on the far right of the drive in the list of drives in the array on the main tab to view the contents of the disk would instead take me to a directory listing of the root of the unRAID file system, and attempting to go directly to /mnt/disk10 (the disk that had the issue, would give an I/O error). I purchased a replacement drive to see if it was a failed drive, precleared the new drive, replaced the old drive with the new drive and let it rebuild the data but again it had the same issue. At this point I'm pretty sure it's the XFS file system on the drive that is not functioning properly and so tried running xfs_repair after starting the array back up with -n and I receive the error "bad primary superblock - bad magic number" and then it finds 7 candidate superblocks but is unable to verify them. At that point it just begins spitting out a huge amount of periods in the console window that goes on for a long time. Hopefully all of that makes sense and I can clarify if you have any questions. My main questions are since I am able to read from the disk, is it possible I might be able to move some of the data from it to another disk in the array and then remove the drive from the array, create a new config, and then just add the drive back and have it reformat it losing anything I don't move to another disk? Is there any change I might be able to fix it without having to lose any of the data? Edited February 13, 20233 yr by AlmostEpic89
February 12, 20233 yr Author 7 minutes ago, JorgeB said: Check filesystem on disk10. This is the same as running xfs_repair using -n which I've already tried. That is where I receive the "bad primary super block - bad magic number" error when running the command directly from the console. Edit - Based on the rest of that link it looks like there isn't much else I can do if the xfs_repair fails besides save the data and reformat the drive. Is there a safe way to do this with moving the data from that drive to another drive in the array or do I need to move the data to an external file system and then move it back afterwards? Edited February 12, 20233 yr by AlmostEpic89
February 12, 20233 yr Community Expert 57 minutes ago, AlmostEpic89 said: when running the command directly from the console. Exactly what was the command you ran from the console? It is easy to get it wrong when doing that. You should also post the output you got. 59 minutes ago, AlmostEpic89 said: Is there a safe way to do this with moving the data from that drive to another drive in the array If you cannot get the drive to mount then there would be no way to get any data off it
February 12, 20233 yr Author Solution On 2/12/2023 at 3:02 AM, itimpi said: Exactly what was the command you ran from the console? It is easy to get it wrong when doing that. You should also post the output you got. I attempted both xfs_repair -n /dev/md10 and xfs_repair -n /dev/sda Both returned output of Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... .found candidate secondary superblock... unable to verify superblock, continuing... It repeated that same found candidate and unable to verify 6 more times and then began outputting a large amount of periods. On 2/12/2023 at 3:02 AM, itimpi said: If you cannot get the drive to mount then there would be no way to get any data off it The drive is mounted when I first start the array and I can access files but anytime something tries to write new files to the drive, it still shows it's mounted but I cannot access the file system of the drive. I may have already solved my own issue though as I found this link Transferring Files within the unRAID Server. I am copying files from /mnt/drive10 to /mnt/drive11 now, and plan to switch the file system of drive 10 to riserfs and then back to XFS after the transfer is completed so I can reformat the drive as it states to do in the link that JorgeB posted under the section Redoing a drive formatted with XFS. EDIT - After finishing moving the files from one drive to another and redoing the drive following the two links the drive is back in the array and behaving correctly now. Marking this post as the solution to this thread. Edited February 13, 20233 yr by AlmostEpic89
February 12, 20233 yr Community Expert 1 hour ago, AlmostEpic89 said: md10 and xfs_repair -n /dev/sda The second one you mention (using /dev/sda)is incorrect and will always give an error (it should be /dev/sda1). When you used /dev/md10 did you allow it to search the whole disk for a valid superblock (this can take some time).
February 12, 20233 yr Author 2 hours ago, itimpi said: The second one you mention (using /dev/sda)is incorrect and will always give an error (it should be /dev/sda1). When you used /dev/md10 did you allow it to search the whole disk for a valid superblock (this can take some time). That makes complete sense since it would be searching the partition not the entire disk (figured xfs_repair would have accounted for that but I guess it is possible people could be using multiple partitions on a drive). I did let it complete the entire search both times when I ran the commands but it wasn't able to find a new superblock. I am not sure exactly how long they took to complete though as I left it running overnight and into the next day while I was at work (8tb drive).
February 12, 20233 yr Community Expert 2 hours ago, itimpi said: (it should be /dev/sda1) And even if you did it that way, if you did it without -n (nomodify) it would invalidate parity. 4 hours ago, AlmostEpic89 said: xfs_repair -n /dev/md10 This is the only correct way to do it with array disks. Doing it in the webUI will get it right.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.