August 4, 20241 yr Hey everyone. I had an array disk that was on REISERFS and I was continually being warned that it was getting deprecated. I've been avoiding it for ages and thought I should bite the bullet. I was considering how I was going to shuffle all my data around, which was going to end up requiring a larger drive to be bought/installed, when it dawned on me that all I should need to do is just treat it like a disk replacement and the parity drive would take care of it. I think I was a little clumsy with the order of proceedings, which may have caused me to bollocks it up completely. From dodgy memory... I stopped the array. Changed the FS on the disk. Started the array. I figured this is where it would ask me to format the disk, which I would, then it would re-build the array. I saw that the disk was unmoutable and didn't check down the bottom to format the disk with the new FS. I stopped the array again. Unassigned the disk. Started the array. Why? I figured I needed to tell unraid that the disk wasn't being used and to rely on the parity drive. "I'll get you a new disk in a minute" Stopped the array again. Assigned the drive back again. Either started the array or formatted the disk and then restarted the array, which ever way that has to happen. The disk was formatted. Then I saw that the array or disk was being rebuilt. Huzzah! ... I thought. I confirmed that LOTS of writes to the disk in question were being performed, and I thought I was off to the races. I monitored it for a few minutes, and I started to get hot all of a sudden when I noticed that although there were lots of writes, the disk wasn't getting any fuller. Be patient, the UI just might not be a proper reflection of things. Next morning... my disk usage is the same as it was when the rebuild started (despite the writes) and I seem to have lost all the data that was on the disk. What did I do wrong?
August 4, 20241 yr Author Parity to Disk 2 read/write would indicate that it should have rebuilt the disk. Did something I did delete the data from the Parity drive and it rebuilt empty blocks? Edited August 4, 20241 yr by ifihaffto
August 4, 20241 yr Community Expert 32 minutes ago, ifihaffto said: What did I do wrong? You formatted the drive. This erases everything. Parity is only able to do one thing, rebuild a drive exactly as it last was. You formatted the drive then rebuilt it, which rebuilt the last state i.e. a freshly formatted empty drive. To change filesystems you have no choice but to copy everything off, format, then copy the data back. You only did the format so all that data is now lost. You might be able to use data recovery software on the drive, don't know about options for reiserfs though. Edited August 4, 20241 yr by Kilrah
August 4, 20241 yr Author Argh. Bugger. I figured taking it out of the array would stop the parity in place? Restart array > rebuild. As though it was a swapped drive? OK. Thanks
August 4, 20241 yr The only good thing reiserfs has going for it is the extreme resiliency for recovery. If you change the file system type back to reiserfs, start the array in maintenance mode, then run the reiserfs check command reiserfsck --check /dev/md2 Note that there is a space between --check and /dev/md2 Hopefully it will give further instructions, I'd capture that output and post it here before proceeding further. This command may take a long time to analyze the drive since it was formatted with another filesystem, let it finish the check.
August 4, 20241 yr Author Thank you! I will give that a try and report back. Exactly as written, or replace md2 with the disk assignment for Disk2? EDIT: NVM, I did some googling ... md2 Edited August 5, 20241 yr by ifihaffto I did some research
August 5, 20241 yr Author 3 hours ago, JonathanM said: This command may take a long time to analyze the drive since it was formatted with another filesystem, let it finish the check. Where will I find evidence of the check taking place? After running the command I got a message telling me where the log will be (kind of - it just said it will be in sdout but not where to find it), but nothing else to indicate something is actually happening.
August 5, 20241 yr 1 minute ago, ifihaffto said: After running the command Where did you run the command?
August 5, 20241 yr Community Expert 18 hours ago, ifihaffto said: I figured taking it out of the array would stop the parity in place? Restart array > rebuild. As though it was a swapped drive? If you formatted the drive while it's out of the array it'd rebuild, but from what you said you formatted it in the array, so updated parity. But as mentioned a rebuild can only restore exactly what was there anyway so it'd have rebuilt the original reiserfs disk, not a conversion.
August 5, 20241 yr Author 2 hours ago, Kilrah said: If you formatted the drive while it's out of the array it'd rebuild, but from what you said you formatted it in the array, so updated parity. But as mentioned a rebuild can only restore exactly what was there anyway so it'd have rebuilt the original reiserfs disk, not a conversion. Yeah, it appears I didn't quite get it right.
August 5, 20241 yr Author 3 hours ago, JorgeB said: Which Unraid release? If > 6.12.0 it's /dev/md2p1 6.12.10 I ran the amended code you provide and got this: Failed to open the device '/dev/md2p1': Unknown code er3k 127
August 6, 20241 yr Author No Sir, I did not. Unfortunately I know barely enough to scrape by (as you have seen ). Does that get appended to the reiserfsck command or is it run separately?
August 6, 20241 yr Author It was. And I've left it that way to reduce the chance of me making anything worse.
August 6, 20241 yr Community Expert You will likely need to rebuild the superblock first, then use the rebuild tree option: https://docs.unraid.net/legacy/FAQ/check-disk-filesystems/#rebuilding-the-superblock Don't forget to add p1 to the device, since those instructions were for older released, after rebuilding the superblock run reiserfsck --rebuild-tree /dev/md2p1
August 9, 20241 yr Author On 8/6/2024 at 4:00 PM, JorgeB said: You will likely need to rebuild the superblock first, then use the rebuild tree option: https://docs.unraid.net/legacy/FAQ/check-disk-filesystems/#rebuilding-the-superblock Don't forget to add p1 to the device, since those instructions were for older released, after rebuilding the superblock run reiserfsck --rebuild-tree /dev/md2p1 Thanks for your help so far. I get Failed to open the device '/dev/md2p1': Unknown code er3k 127 when I attempt to rebuild the superblock. reiserfsck --rebuild-sb /dev/md2p1 Does it need to be an UNASSIGNED disk? It's currently in the array, which was started in maintenance mode.
August 9, 20241 yr Community Expert 3 hours ago, ifihaffto said: Does it need to be an UNASSIGNED disk? Nope, but if the command is failing, only option would be using a file recovery app, like UFS explorer.
August 16, 20241 yr Author Thanks @JorgeB So, stop the array, power down the nas and physically remove the disk. Use UFS explorer or similar to try and recover any data. Copy that somewhere (I'll get a replacement disk as it could do with some extra space). This is where I'm unsure of the order... Replace the disk, fire up the nas and add it back to and start the array (changed file system and formatted). This is effectively adding a blank disk to the array. Copy the files back to either the replaced disk or the share. How did I go?
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.