May 24, 201610 yr So a few days ago, I noticed I wasn't able to reach my server at all (through any of my dockers or ssh). I plugged in a monitor and saw that there was a missing file (I don't recall the name, but the boot one... Linux.something?). Anyways I took the USB stick and just recreated it on my computer as a bootable and reinstalled it to the USB stick. When I went to boot it back up however, it would hang when trying to mount the drives (the web browser, not ssh though). So I started in maintenance mode and did a xfs_repair -n and I see this "unraid Metadata corruption detected at xfs_agf block 0x105fc7a89/0x200 flfirst 118 in agf 3 too large (max = 118)" So I took off the "-n" to let it auto repair and it gives me a warning to use -L beacuse of some log file (can't replicate this right now to give the exact error and I"ll explain why in a bit). I didn't want to bother the forum without at least doing a bit of searching so I found a thread that said to do these commands: mkdir /mnt/tmp mount /dev/md2 /mnt/tmp umount /mnt/tmp xfs_repair /dev/md2 This is what I get instead though. root@Tower:~# mkdir /mnt/tmp root@Tower:~# mount /dev/md2 /mnt/tmp Killed root@Tower:~# umount /mnt/tmp umount: /mnt/tmp: not mounted root@Tower:~# xfs_repair /dev/md2 After this it hangs... I can no longer do anything in the ssh window (Can open another ssh session) and I can't do any xfs_repair commands at all. I thought that it just needed time, but I let it run overnight and it is still in the same condition. Any help would be greatly appreciated and please let me know if there's any additional information I can provide.
May 24, 201610 yr I'm not sufficiently skilled in Linux to know what someone was trying to do with those steps. It looks like they want to mount it a second time then unmount the second, but that seems like it would leave the first mount alive, not what you want for xfs_repair. xfs_repair works on unmounted drives. In unRAID, we have a special mode called Maintenance mode, a check box when you start the array. It starts the array and sets up the drive symbols and other behind-the-scenes stuff, but leaves the drives unmounted and doesn't start any file system access. Please use the Check Disk File systems wiki page, to do what you were trying to do, either from within the webGui or at the command line, your choice. In the webGui, you can put the -L option into the options box. I probably need to add it to the page.
May 24, 201610 yr Author Hey Rob. I've tried setting the field to blank (to repair it) and it returns with the log issue saying that I should try -L. When using -L the process seems to hang and I can't get any xfs_repair options to work after that until a hard reboot. (Reboot command doesn't take either). All of this done in maintenance mode.
May 25, 201610 yr xfs_repair is not a very polished tool. Any possibility it was still working, just no progress info displaying? You might try it again at the command line, then monitor the Main screen for reads and possibly writes to the drive. And check if you can see an activity light for the drive. This process IS going to take a long long time.
May 25, 201610 yr Author I've done it at both CLI as well as through the GUI. I let it run overnight (about 7 hours). Should I continue to let it run? It is a 3TB drive.
May 25, 201610 yr I'm sorry, I don't know. I would have expected to see *something* after 7 hours. Is your data retrievable from the drive, all or most? You may have to redo the drive, something along the lines of what I wrote for the BTRFS section, when *its* repair tools aren't up to the job. * By the way, I'm sorry, I missed the fact earlier you were already using Maintenance mode.
May 25, 201610 yr Really sorry. There's a recent thread somewhere here, where a user had an unmountable drive, and was able to recover much of it. I suggested TestDisk, bubbaQ suggest several others, including File Scavenger, and the user was able to use File Scavenger to find and save quite a few files. It's a lot of time consuming work, but is likely to help.
May 25, 201610 yr Author According to the SMART tests, the drive didn't fail though and is relatively new. That's what I'm not understanding. Do you think a fresh format is all it needs then?
May 25, 201610 yr I've assumed the physical drive was fine. All we have been talking about is a severely corrupted file system, and I assumed you might want to recover the files. If you have the files backed up elsewhere, then there's no need for data recovery, and you can go ahead and reformat it. Easiest way (I think) to reset the format is change the file system format to ReiserFS, start the array and let it format (it's quick), then stop the array, change the format back to XFS, and restart the array again and let it format again.
May 25, 201610 yr Author Alright sounds good. Hopefully my parity drive will replace my missing files.
May 25, 201610 yr Alright sounds good. Hopefully my parity drive will replace my missing files. NOOOOO!!!!!! STOP!!!!!!!!!!!!!!!!!!!!!!!!! Parity does not contain any individual files. It only recreates the entire drive, as it is, corruption included. Formatting will create a new blank filesystem which will be reflected in the parity information. Do you have backups?
May 25, 201610 yr Author I do not. I thought that Unraid was a way it would keep backup of files if a drive failed. Also since my USB key got corrupt, I lost all my docker settings and VMs, is there a way to restore those?
May 25, 201610 yr Community Expert I do not. I thought that Unraid was a way it would keep backup of files if a drive failed. Also since my USB key got corrupt, I lost all my docker settings and VMs, is there a way to restore those? The usual way to fix flash drive corruption is to put it in your PC and let it checkdisk. Did you reformat the drive or did you just run make_bootable on it again? unRAID or indeed any RAID is not a backup. The only thing that counts as a backup is another copy of your files. If you think about it, there is no way a single parity drive could contain a backup of all of the data of all of the other disks. Parity + all the other disks are required to rebuild a disk. Parity is not very complicated and understanding it will help keep you from making mistakes that will result in data loss. And as jonathanm said, rebuilding a corrupt filesystem will result in a corrupt filesystem, and rebuilding a formatted disk will result in a formatted disk.
May 25, 201610 yr Author Hey Trurl. I tried the scandisk, but no luck so I formatted the drive and used make_bootable again (make_bootable wasn't on the thumb drive so I had to actually download the entire thing again). Hmm I guess that makes sense. So I guess my only option would be to try to recover the files?
May 25, 201610 yr Author When attempting a xfs_repair with no options I get this. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... 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. The -L option seems to just hang and nothing happens. I can wait longer, but 7 hours is the longest I've waited with no changes.
May 25, 201610 yr When attempting a xfs_repair with no options I get this. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... 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. The -L option seems to just hang and nothing happens. I can wait longer, but 7 hours is the longest I've waited with no changes. You can increase the verbosity by passing xfs_repair it the -v option as well. I suggest you look over the man page, it might tell you more about what xfs_repair can and can't do. Also perhaps before running xfs_repair in destructive mode, run it with the -n (no modify) mode to get a sense of what xfs_repair would have fixed if it were allow to make modifications. (Then you can run it again without the -n flag to have it execute the modifications) Depending on your views of this... might be totally not required.
Archived
This topic is now archived and is closed to further replies.