December 1, 20169 yr I was doing some updating and changes on my unRAID setup and at some point, one of my data drives is unable to mount. I ran a check on the drive (-vf flag) and this is what came back. Phase 1 - find and verify superblock... - block cache size set to 712736 entries Phase 2 - using internal log - zero log... zero_log: head block 1160183 tail block 1155834 - scan filesystem freespace and inode maps... Metadata corruption detected at xfs_agf block 0x105fc7a89/0x200 flfirst 118 in agf 3 too large (max = 118) agf 118 freelist blocks bad, skipping freelist scan block (0,103405884-103405884) multiply claimed by cnt space tree, state - 2 agf_freeblks 6400825, counted 6396917 in ag 0 agi unlinked bucket 41 is 567774825 in ag 3 (inode=7010225769) agi_freecount 2858, counted 2979 in ag 0 sb_ifree 490, counted 11859 sb_fdblocks 38755985, counted 38879664 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 imap claims a free inode 255650321 is in use, would correct imap and clear inode imap claims a free inode 255650322 is in use, would correct imap and clear inode imap claims a free inode 255680755 is in use, would correct imap and clear inode - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Wed Nov 30 18:04:19 2016 Phase Start End Duration Phase 1: 11/30 18:01:26 11/30 18:01:26 Phase 2: 11/30 18:01:26 11/30 18:01:30 4 seconds Phase 3: 11/30 18:01:30 11/30 18:04:19 2 minutes, 49 seconds Phase 4: 11/30 18:04:19 11/30 18:04:19 Phase 5: Skipped Phase 6: Skipped Phase 7: Skipped Total run time: 2 minutes, 53 seconds Before running the check I thought about just replacing the drive and rebuilding the data from the parity but the parity I am guessing also may just restore the same issue. If it was any other of the drives in my array it sucks but its fine. This drive I things like photos and other documents that are personal which is my only copy. Most is backed up offsite but some of it was still in progress while this happened. Any advice on what steps I should take?
December 1, 20169 yr Author Prior to posting I have read a couple of other threads that are similar and I think my answer is to run the file check with -L but I just want to confirm before I do so. Also to confirm the proper way, such as through the GUI (Main tab, click the drive and run from their or run it command line with /dev/sdx or /dev/mdx which I see an error on the console for mdx. XFS (md1): Corruption of in-memory data detected. Shutting down filesystem. XFS (md1): Please unmount the filesystem and rectify the problem(s)
December 1, 20169 yr Community Expert I was doing some updating and changes on my unRAID setup and at some point, one of my data drives is unable to mount. I ran a check on the drive (-vf flag) and this is what came back. Did you mean -vn? You need to run it without the -n (no modify flag), just run: xfs_repair -v /dev/mdX
December 1, 20169 yr Author I was doing some updating and changes on my unRAID setup and at some point, one of my data drives is unable to mount. I ran a check on the drive (-vf flag) and this is what came back. Did you mean -vn? You need to run it without the -n (no modify flag), just run: xfs_repair -v /dev/mdX Yes sorry, -vn. What exactly should happen if running it with just -v? It seemed like -L was the way to go but maybe at least not yet?
December 1, 20169 yr Community Expert Running with -v only will attempt to fix the filesystem, with -n (or -vn) it will run in read only mode and not fix anything.
December 1, 20169 yr Community Expert When running any flesystem repair tools there's always a chance of data loss, but in this case less than if you had to use -L.
December 1, 20169 yr Author I tried running xfs_repair -v /dev/md1 and received the following message. Phase 1 - find and verify superblock... - block cache size set to 712736 entries Phase 2 - using internal log - zero log... zero_log: head block 1160183 tail block 1155834 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.
December 1, 20169 yr Author Okay thanks. What it be worth trying to clone or restore the drive to another disk before attempting -L?
December 1, 20169 yr Okay thanks. What it be worth trying to clone or restore the drive to another disk before attempting -L? Chances of data loss are pretty low, but not non-existent. How valuable or hard to recreate is the data?
December 1, 20169 yr Author Okay thanks. What it be worth trying to clone or restore the drive to another disk before attempting -L? Chances of data loss are pretty low, but not non-existent. How valuable or hard to recreate is the data? Most of the data is backed up (CrashPlan) but not all and at this point I am not entirely sure what hasn't since it had a couple more hours of backing up to do. The biggest thing are family photos (priceless) that I recently moved over which I don't have another copy.
December 1, 20169 yr Okay thanks. What it be worth trying to clone or restore the drive to another disk before attempting -L? Chances of data loss are pretty low, but not non-existent. How valuable or hard to recreate is the data? Most of the data is backed up (CrashPlan) but not all and at this point I am not entirely sure what hasn't since it had a couple more hours of backing up to do. The biggest thing are family photos that I recently moved over which I don't have another copy. If you wanted to have another shot at recovery if these attempts fail, you could pull the physical disk and rebuild to a new drive, then do the file system repair on the new drive. When was the last time you had a clean parity check? If all your other drives are physically fine and parity accurately reflects what is on the rest of the drives, rebuilding to a new drive will clone what is on there currently. There are several options and permutations with varying levels of safety and repeatability to work with your data. How much trouble do you want to go through to ensure the best possible outcome? Repairing the current file system in place is the easiest, but permanently changes the only copy of the data, for better or worse.
December 1, 20169 yr Author If you wanted to have another shot at recovery if these attempts fail, you could pull the physical disk and rebuild to a new drive, then do the file system repair on the new drive. I'll give that a try first. When was the last time you had a clean parity check? If all your other drives are physically fine and parity accurately reflects what is on the rest of the drives, rebuilding to a new drive will clone what is on there currently. I ran a check over this past weekend so it should be good. There are several options and permutations with varying levels of safety and repeatability to work with your data. How much trouble do you want to go through to ensure the best possible outcome? I'm willing go through whatever hassle needs to be done as well as it could be. All in all sounds like the next step is to rebuild the drive from the parity and trying the -L flag. I should know then sometime this weekend if that will work.
December 1, 20169 yr I'm willing go through whatever hassle needs to be done as well as it could be. All in all sounds like the next step is to rebuild the drive from the parity and trying the -L flag. I should know then sometime this weekend if that will work. That is almost the safest option. The safest IMHO would be to use dd to clone the drive to another physical drive and run the file system repair on the clone. That way your current system is not disturbed in any way. Do you have hot swap bay drive connections that allow you to add and remove drives without physically messing with the SATA and power cables? I've seen multiple cases of people making things worse by disturbing cabling. All this may seem overboard and paranoid to some people, but you did state you wanted to know the best possible options.
December 1, 20169 yr Author I do have externally swappable bays. If I were to use dd to clone it; is it possible to than take that clone and try running the file check in lets say Ubuntu?
December 1, 20169 yr I do have externally swappable bays. If I were to use dd to clone it; is it possible to than take that clone and try running the file check in lets say Ubuntu? Absolutely. That fact is one of the BEST features of unraid, each drive has a completely independent file system that can be manipulated in any compatible OS.
December 1, 20169 yr Author I do have externally swappable bays. If I were to use dd to clone it; is it possible to than take that clone and try running the file check in lets say Ubuntu? Absolutely. That fact is one of the BEST features of unraid, each drive has a completely independent file system that can be manipulated in any compatible OS. While doing a check through Ubuntu, do I need to use /mdx (mdx1 showing in unRAID) or do I go with /sdbx? I don't actually understand what /mdx means, I never saw this until I saw it on the console and read a mention of it in another thread. Also wondering. Does 'Creating partition image' in Disks truly create a disk image which than can be restored?
December 1, 20169 yr I do have externally swappable bays. If I were to use dd to clone it; is it possible to than take that clone and try running the file check in lets say Ubuntu? Absolutely. That fact is one of the BEST features of unraid, each drive has a completely independent file system that can be manipulated in any compatible OS. While doing a check through Ubuntu, do I need to use /mdx (mdx1 showing in unRAID) or do I go with /sdbx? I don't actually understand what /mdx means, I never saw this until I saw it on the console and read a mention of it in another thread. You would use whatever /dev/sd?1 that shows up when you connect it to your ubuntu box. /dev/md? are RAID volumes, in the context of unraid they are used to operate on the block device that is created and maintained with the parity and data /dev/sd? devices. The md devices exist whether or not a physical drive is currently connected, as long as your failure tolerance has not been exceeded. (single parity, one missing drive, dual parity, two missing drives) If you alter the /dev/sd? devices that are part of the parity protected array, parity will not be maintained, so any parity generated data will be corrupt, and parity will need to be rebuilt with the newly altered drive.
December 1, 20169 yr Author I did try running xfs_repair -v /dev/sdc in Ubuntu and it is going through a bit different that what in unRAID did. Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ........................................................................... ........................................................................... ........................................................................... (and repeats) Not sure if it is doing something, stuck, or what to do.
December 1, 20169 yr Author You have to specify the partition, eg, /dev/sdc1 Okay thanks, I wasn't entirely sure. Same error in Ubuntu as unRAID with the correct command so I will wait until I get home with a new drive and clone it before preceding. I work IT (network) and probably should know more Linux but don't so I really appreciate the help. Last question I think for now. The Disks utility in Ubuntu. How well does the Create Partition Image and than Restore Partition Image work? Going to assume it does not work the same as dd.
Archived
This topic is now archived and is closed to further replies.