I am currently doing a couple of parity-swap (disable), then will be removing a few of my 3TB drives and moving their data to the, soon to be, old parity drives.  I read the threads about xfs fragmentation and thought I would check mine while doing so much array work.  The command I found to check the frag level is failing through:

 

Defrag XFS Array Drives

 

root@Atlas:~# xfs_db -r /dev/md3p1
xfs_db: /dev/md3p1 is not a valid XFS filesystem (unexpected SB magic number 0x4c554b53)
Use -F to force a read attempt.

 

So I tried adding the -F:

root@Atlas:~# xfs_db -r -F /dev/md3p1     *(I tried other drive numbers and all return the same result)*
xfs_db: /dev/md3p1 is not a valid XFS filesystem (unexpected SB magic number 0x4c554b53)
xfs_db: V1 inodes unsupported. Please try an older xfsprogs.

 

When looked up the V1 inodes unsupported I found references to the drive being formatted with an old version of xfs.

 

Any ideas what is going on? I doubt this matters but it's xfs encrypted.

atlas-diagnostics-20240722-2344.zip

Are you sure this is the command you want to run?

https://linux.die.net/man/8/xfs_db

 

xfs_db is not for defragmentation, but seems to be for XFS diagnostic information.

 

Looking at this script, as an example, another command (xfs_fsr) seems to be used:

 

Honestly I'd not bother with XFS defragmentation, especially if you're not that proficient with Linux command-line or filesystems.

99% of users do just fine without any defragmentation, and it'd be included in Unraid if it were necessary or even recommended.

Also please reconsider randomly running force options like that in the future, that'll really mess things up if you're not 100% sure.

Running random filesystem commands on all of your disks and forcing operations when things don't work will screw up something.

 

Well, the first step was to determine the fragmentation level. As the tool states, the value is mostly meaningless, so unless I found reports of very high fragmentation, there would not be much of a reason to defragment. The thread you linked had a post with the encrypted drive parameter, which answered my original suspicion about why the command I was using wasn't working, my array is encrypted.  

 

For encrypted drives you need to run:

xfs_db -r /dev/mapper/mdXp1         #X is the drive number, and adding /mapper/ is for encrypted arrays in 6.12+

 

So a cheat sheet of commands

-r means read-only

For unRaid 6.12 and newer, non-encrypted arrays use /dev/mdXp1

For unRaid 6.12 and newer, encrypted arrays use /dev/mapper/mdXp1

For unRaid 6.11 and older use /dev/mdX

Not sure if /mapper/ applies to encrypted arrays in 6.11 or older as I cannot test that

 

My drives mostly returned values below 10% total or file fragmentation.  2 drives returned 30%.  With those two am I going to move some files off as they are approaching max capacity anyway.

 

And yes, the xfs_fsr is the defrag command ljm42 used in the thread I posted. I was still in the information-gathering stage.