June 8, 20251 yr Author Sorry for late response, but had the same problems, multiple times during this time.Last week, the same hdd, gave the same problem, and after repair, had 16 current pending sectors, and increasing.Because i had a new hdd, replace him.Stopped array, remove hdd, started array, stopped, added new one, and with docker and vm off, leave to rebuilding it.After all the work, some series (i received notification that had been deleted) didnt shows up, so i ran Compute All and have 667Gb of data in lost+found.How can i recover that data, if i cannot access? Edited June 8, 20251 yr by Vitor Ventura lost text
June 9, 20251 yr Author ran via webUi multiple timesran xfs_repair -L and then -v, nothing changed Edited June 9, 20251 yr by Vitor Ventura
June 9, 20251 yr Community Expert Run it manually from the CLI, start the array in maintenance mode and type:xfs_repair -v /dev/md4p1Then post the output from that.
June 9, 20251 yr Author root@VenturaNas:~# xfs_repair -v /dev/md4p1Phase 1 - find and verify superblock... - block cache size set to 1475600 entriesPhase 2 - using internal log - zero log...zero_log: head block 66 tail block 66 - scan filesystem freespace and inode maps... - found root inode chunkPhase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - process newly discovered inodes...Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 10 - agno = 0 - agno = 2 - agno = 6 - agno = 4 - agno = 3 - agno = 8 - agno = 9 - agno = 7 - agno = 5Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - reset superblock...Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - traversal finished ... - moving disconnected inodes to lost+found ...Phase 7 - verify and correct link counts... XFS_REPAIR Summary Mon Jun 9 11:21:35 2025Phase Start End DurationPhase 1: 06/09 11:20:28 06/09 11:20:28Phase 2: 06/09 11:20:28 06/09 11:20:30 2 secondsPhase 3: 06/09 11:20:30 06/09 11:21:02 32 secondsPhase 4: 06/09 11:21:02 06/09 11:21:02Phase 5: 06/09 11:21:02 06/09 11:21:04 2 secondsPhase 6: 06/09 11:21:04 06/09 11:21:34 30 secondsPhase 7: 06/09 11:21:34 06/09 11:21:34Total run time: 1 minute, 6 secondsdoneroot@VenturaNas:~#
June 9, 20251 yr Community Expert Have you tried restarting the array in normal mode since running xfs_repair?
June 9, 20251 yr Community Expert No corruptions so far, try accessing the folder/share that was giving the invalid path error, and if you see the same post new diags and the complete path.
June 9, 20251 yr Author 40 minutes ago, JorgeB said:No corruptions so far, try accessing the folder/share that was giving the invalid path error, and if you see the same post new diags and the complete path.The folder is giving invalid path error is the lost+found folder.i had lost files, example, i had the season 18 completed of Naruto Shippudenis not possible to recover all files in lost+found? venturanas-diagnostics-20250609-1533.zip
June 9, 20251 yr Community Expert 6 minutes ago, Vitor Ventura said:is not possible to recover all files in lost+found?Files are put into lost+found when the recovery process cannot find the directory entry to give them their correct name. If you want to try and recover them then it is a manual process to look at each in turn to work out what name it should have, although the Linux ‘file’ command can help by telling you at least what the content type is for a given file.You will probably need to run Tools->New Permissions on the lost+found share if you want to be able to access the contents over the network.
June 9, 20251 yr Author 8 minutes ago, itimpi said:Files are put into lost+found when the recovery process cannot find the directory entry to give them their correct name. If you want to try and recover them then it is a manual process to look at each in turn to work out what iname it should have, although the Linux ‘file’ command can help by telling you at least what the content type is for a given file.You will probably need to run Tools->New Permissions on the lost+found share if you want to be able to access the contents over the network.well, after analysing a few files, checked my Immich, and is completely broken... 😭in 10 years, 6 with unraid, never had something like this...many thanks for your effort @itimpi and @JorgeB
June 9, 20251 yr Author i havent touched the hdd i removed.its possible to added to array again to parity pick everything, and them swap again the hdds?Connected via usb and cannot mount. maybe have a possibility to recover the corrupted filesystem, even with the new one swapped?Jun 9 20:00:04 VenturaNas kernel: XFS (sdn1): Corruption warning: Metadata has LSN (-977856008:384760175) ahead of current LSN (16:23420). Please unmount and run xfs_repair (>= v4.3) to resolve.Jun 9 20:00:04 VenturaNas kernel: XFS (sdn1): Metadata CRC error detected at xfs_inobt_read_verify+0x12/0x60, xfs_finobt block 0x5767c1e0 Jun 9 20:00:04 VenturaNas kernel: XFS (sdn1): Unmount and run xfs_repairJun 9 20:00:04 VenturaNas kernel: XFS (sdn1): First 128 bytes of corrupted metadata buffer:Jun 9 20:00:04 VenturaNas kernel: 00000000: 24 1a 9c 92 6d 85 ce 6d 6f 93 4c d2 44 fc dc 3b $...m..mo.L.D..;Jun 9 20:00:04 VenturaNas kernel: 00000010: 98 25 67 cf 3f 77 ea c1 c5 b7 19 f8 16 ee f9 6f .%g.?w.........oJun 9 20:00:04 VenturaNas kernel: 00000020: 76 48 30 f5 c9 61 87 35 a3 da 2a ee a0 d8 92 c3 vH0..a.5..*.....Jun 9 20:00:04 VenturaNas kernel: 00000030: cc 6c cd 9b 9b 53 a0 69 79 01 e4 94 72 d5 4f 37 .l...S.iy...r.O7Jun 9 20:00:04 VenturaNas kernel: 00000040: aa 93 9e 81 25 4c 5d dd d7 25 b1 ba 1c c7 68 6b ....%L]..%....hkJun 9 20:00:04 VenturaNas kernel: 00000050: 00 b6 ab b7 f7 3e 76 31 ad 48 42 a3 ae b1 05 df .....>v1.HB.....Jun 9 20:00:04 VenturaNas kernel: 00000060: de da 64 5c 81 28 13 65 0b 6f 1f 49 78 a2 3e 33 ..d\.(.e.o.Ix.>3Jun 9 20:00:04 VenturaNas kernel: 00000070: b4 01 36 42 53 25 cc d8 e1 93 28 7f 0a 9c db 66 ..6BS%....(....fJun 9 20:00:04 VenturaNas kernel: XFS (sdn1): metadata I/O error in "xfs_btree_read_buf_block+0xa7/0x110" at daddr 0x5767c1e0 len 8 error 74Jun 9 20:00:04 VenturaNas kernel: XFS (sdn1): Error -117 reserving per-AG metadata reserve pool.Jun 9 20:00:04 VenturaNas kernel: XFS (sdn1): Corruption of in-memory data (0x8) detected at xfs_fs_reserve_ag_blocks+0xbe/0xd0 (fs/xfs/xfs_fsops.c:546). Shutting down filesystem.Jun 9 20:00:04 VenturaNas kernel: XFS (sdn1): Please unmount the filesystem and rectify the problem(s)Jun 9 20:00:04 VenturaNas kernel: XFS (sdn1): Ending recovery (logdev: internal)Jun 9 20:00:04 VenturaNas kernel: XFS (sdn1): Error -5 reserving per-AG metadata reserve pool.Jun 9 20:00:05 VenturaNas unassigned.devices: Mount of 'sdn1' failed: 'mount: /mnt/disks/G-DRIVE_USB: can't read superblock on /dev/sdn1. dmesg(1) may have more information after failed mount system call.' Edited June 9, 20251 yr by Vitor Ventura
June 10, 20251 yr Community Expert You can try repairing the filesystem on that disk, to see if it's any better:zfs_repair -v /dev/sdn1
June 10, 20251 yr Author try xfs_repair -L /dev/sdn1 ??root@VenturaNas:~# xfs_repair -v /dev/sdn1 Phase 1 - find and verify superblock... - block cache size set to 1475600 entries Phase 2 - using internal log - zero log... zero_log: head block 23420 tail block 23416 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 the filesystem is a snapshot of a mounted filesystem, you may need to give mount the nouuid option. 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.tried mount with mount /dev/sdn1 /mnt/tempJun 10 12:35:34 VenturaNas kernel: XFS (sdn1): Mounting V5 Filesystem de2938bc-64f2-48e4-ba45-8581ad427d31Jun 10 12:35:34 VenturaNas kernel: XFS (sdn1): Starting recovery (logdev: internal)Jun 10 12:35:35 VenturaNas kernel: XFS (sdn1): Corruption warning: Metadata has LSN (-977856008:384760175) ahead of current LSN (16:23420). Please unmount and run xfs_repair (>= v4.3) to resolve.Jun 10 12:35:35 VenturaNas kernel: XFS (sdn1): Metadata CRC error detected at xfs_inobt_read_verify+0x12/0x60, xfs_finobt block 0x5767c1e0 Jun 10 12:35:35 VenturaNas kernel: XFS (sdn1): Unmount and run xfs_repairJun 10 12:35:35 VenturaNas kernel: XFS (sdn1): First 128 bytes of corrupted metadata buffer:Jun 10 12:35:35 VenturaNas kernel: 00000000: 24 1a 9c 92 6d 85 ce 6d 6f 93 4c d2 44 fc dc 3b $...m..mo.L.D..;Jun 10 12:35:35 VenturaNas kernel: 00000010: 98 25 67 cf 3f 77 ea c1 c5 b7 19 f8 16 ee f9 6f .%g.?w.........oJun 10 12:35:35 VenturaNas kernel: 00000020: 76 48 30 f5 c9 61 87 35 a3 da 2a ee a0 d8 92 c3 vH0..a.5..*.....Jun 10 12:35:35 VenturaNas kernel: 00000030: cc 6c cd 9b 9b 53 a0 69 79 01 e4 94 72 d5 4f 37 .l...S.iy...r.O7Jun 10 12:35:35 VenturaNas kernel: 00000040: aa 93 9e 81 25 4c 5d dd d7 25 b1 ba 1c c7 68 6b ....%L]..%....hkJun 10 12:35:35 VenturaNas kernel: 00000050: 00 b6 ab b7 f7 3e 76 31 ad 48 42 a3 ae b1 05 df .....>v1.HB.....Jun 10 12:35:35 VenturaNas kernel: 00000060: de da 64 5c 81 28 13 65 0b 6f 1f 49 78 a2 3e 33 ..d\.(.e.o.Ix.>3Jun 10 12:35:35 VenturaNas kernel: 00000070: b4 01 36 42 53 25 cc d8 e1 93 28 7f 0a 9c db 66 ..6BS%....(....fJun 10 12:35:35 VenturaNas kernel: XFS (sdn1): metadata I/O error in "xfs_btree_read_buf_block+0xa7/0x110" at daddr 0x5767c1e0 len 8 error 74Jun 10 12:35:52 VenturaNas kernel: XFS (sdn1): Error -117 reserving per-AG metadata reserve pool.Jun 10 12:35:52 VenturaNas kernel: XFS (sdn1): Corruption of in-memory data (0x8) detected at xfs_fs_reserve_ag_blocks+0xbe/0xd0 (fs/xfs/xfs_fsops.c:546). Shutting down filesystem.Jun 10 12:35:52 VenturaNas kernel: XFS (sdn1): Please unmount the filesystem and rectify the problem(s)Jun 10 12:35:52 VenturaNas kernel: XFS (sdn1): Ending recovery (logdev: internal)Jun 10 12:35:52 VenturaNas kernel: XFS (sdn1): Error -5 reserving per-AG metadata reserve pool. Edited June 10, 20251 yr by Vitor Ventura
June 10, 20251 yr Author didnt work well :(i have to manual recover all files, via script.many thanks again
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.