October 9, 2025Oct 9 I feel like I've been digging myself into a hole that may be leading to corrupting my 8-bay nas, I was trying to swap out 2 hard drives in the array and followed the instructions and that went without a hitch but after rebooting the second disk in my array, one where I had used Unbalance to Gather all the data that was in the two drives I was trying to remove (after using that same command to fill up the first disk) the second disk ended up showing that it had no file system, it was originally in XFS and it gave me the option to give it one and misclicked it and applied it with ZFS, parity was re-synced after the two drives were removed and I had made a New Config for the array to show 6 drives for the time being, my plan was to install two other drives but I don't want to risk corrupting the parity (if not more) until I can fix the file system on the second disk, I've already tried running xfs repair but it doesn't seem to have done anything.I've already rebooted a few times trying to figure it out on my own, at this point I guess i'm just trying to figure out the best course, worried about my parity after already stopping/starting the array both in and out of maintenance mode with my priority to fix the second disk, succeeding that, adding/replacing the two disks I already removed (that were erased/zeroed out)long time lurker first time poster, not sure how to do formatting.root@Tower:~# xfs_repair /dev/md2p1Phase 1 - find and verify superblock...Phase 2 - using internal log - zero log... - 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 - process newly discovered inodes...Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 2 - agno = 1Phase 5 - rebuild AG headers and trees... - reset superblock...Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ...Phase 7 - verify and correct link counts...done tower-diagnostics-20251008-2235.zip
October 9, 2025Oct 9 Community Expert With the array running, post the output from wipefs /dev/md2p1Despite the name, as written, it won't wipe anything.
October 9, 2025Oct 9 Author 11 hours ago, JorgeB said:With the array running, post the output from wipefs /dev/md2p1Despite the name, as written, it won't wipe anything.here's what came from that: root@Tower:~# wipefs /dev/md2p1DEVICE OFFSET TYPE UUID LABELmd2p1 0x0 xfs 855c3e44-4b08-4ded-960a-1e4b609203b8 md2p1 0x3a381744000 zfs_member 10217424177862306645 disk2md2p1 0x3a381784000 zfs_member 10217424177862306645 disk2sorry for the late reply and thanks for taking the time to respond to my post 🫡
October 10, 2025Oct 10 Community Expert Solution The multiple filesystem signatures explain why the disk doesn't mount, based on the xfs_repair results, it looks like xfs is the actual filesystem, so click on that disk, change the fs from zfs to xfs, then start the array again to see if it mounts. If yes, and if you like, I can then post the instructions to clean the extra signature.
October 10, 2025Oct 10 Author It mounted! I was able to finally go in and use the file explorer to see what was specifically on that disk, stress level is now lower now, and yes I would greatly appreciate it if you could provide the instructions on how to do that, thank you in advance
October 10, 2025Oct 10 Community Expert If all looks good and you want to delete the extra zfs signature, start the array in maintenance mode and type:wipefs -a -t zfs_member /dev/md2p1
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.