5 hours ago, sybrwulf said:

But what isn't answered here is why crc alone is roughly double the documented allocated size

This would likley be due to the newer kernel, and some changes implemented by xfs.

So glad I found his post and could read into what I am seeing this evening on my new 16tb drives creating XFS- encrypted formats on Unraid 7 and "losing" 306GB per drive:

 

Please forgive the newbie queries:

 

1.) The manual format command setting crc to 0 now reports the below warning. Is this something those chosing to apply crc=0  may encounter as a blocking issue for supporting their drives in future Unraid versions?

 

2.) Are there additional steps to establish the crc=0 format and use the xfs encryption filesystem?

 

3.) If I deployed my new NAS under 6.12  formatting under xfs there and then upgraded to 7, would I see the more modest space reservations discussed earlier in the thread?

9 hours ago, Sethy432 said:

setting crc to 0

As mentioned above you should not use that option, it will remove metadata checksums and create a deprecated filesystem, that may stop working in a future kernel.

11 hours ago, Sethy432 said:

3.) If I deployed my new NAS under 6.12  formatting under xfs there and then upgraded to 7, would I see the more modest space reservations discussed earlier in the thread?

I do not think so as xfs v5 was introduced quite a long while ago.   You could always try it to see.   However, since that would remove the ability for xfs to detect metadata corruption not sure that it makes sense to do so if you consider your data integrity to be important.

Thanks for the thoughts both.

 

I thought I would give it a try on Unraid 6.12 and saw the reservation reduce by ~200GB per drive as shown below.

29 minutes ago, itimpi said:

However, since that would remove the ability for xfs to detect metadata corruption not sure that it makes sense to do so if you consider your data integrity to be important

Interesting, This would be the same position as the rest of the community upgrading existing disks from their 6.X instance upon upgrade to 7?

 

An additional thought, does that mean 6.x to 7.x upgraded users will have a mix of xfs version disks within their array when they add their next disk post upgrade?

Edited January 29, 20251 yr by Sethy432

39 minutes ago, Sethy432 said:

An additional thought, does that mean 6.x to 7.x upgraded users will have a mix of xfs version disks within their array when they add their next disk post upgrade?

It could do I guess.  Since parity does not care about file systems then it is definitely possible to mix them.   

 

However I think even on Unraid 6 (at least for most releases) xfs was on v5 so there may be some other non-obvious change in the more recent kernels..   What the long term effect of not being on the most recent version of the xfs format might be I have no idea.   I personally work on the idea that the small space saving is not worth the effort.

This is a very interesting topic. I was about to run defrag on my drives to figure this out...

For me, I'm seeing ~2% usage on an empty 24TB drive, which seems like a lot, since the 14TB drives these are replacing used 96GB or so.

As I understand it then, w/ reflinks and crc enabled, this 2% usage of an empty drive is operating as intended?

Yes

10 hours ago, Shadz said:

This is a very interesting topic. I was about to run defrag on my drives to figure this out...

For me, I'm seeing ~2% usage on an empty 24TB drive, which seems like a lot, since the 14TB drives these are replacing used 96GB or so.

As I understand it then, w/ reflinks and crc enabled, this 2% usage of an empty drive is operating as intended?

Look into the file system types. Ref Links are required to assist raid/snapraid and the fuse system of the data at the block level. Higer capacity requires more ref liniks to the data block available...

Review the File system XFS and the REFlink also known as "Data Block Sharing"
https://www.reddit.com/r/linuxquestions/comments/mdmxm0/what_are_reflinks/

https://blogs.oracle.com/linux/post/xfs-data-block-sharing-reflink

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-xfs

https://en.wikipedia.org/wiki/XFS

this assist unraid array and how disk 1 and parity operate.
https://docs.unraid.net/unraid-os/manual/storage-management/

Interestingly checking my array drives I have some that have reflink enabled and some that don't. I've never changed any settings to manipulate this myself. Was there a time when reflink wasn't enabled by default?

2 hours ago, warpspeed said:

Was there a time when reflink wasn't enabled by default?

Yes, don't remember the release, it was a few years ago, but any filesystems created before that won't have it enabled.

I have been observing a similar increase in reserved size going from Unraid 6 to 7. A 28 TB drive would reserve around 500 GB now, when it would only reserve 195 GB before.

By comparing the xfs_info output between a drive formatted in Unraid 6 (can't recall the exact version number, but it was one of the later ones close to 7.0 RC release date), I found that all my drives were already formatted using crc=1 and reflink=1, so this was not the cause of the increase in reserved space. However I noticed that Unraid 7 will set rmapbt=1 and nrext64=1, whereas in Unraid 6 these were both 0.

I manually reformatted a drive using
mkfs.xfs -m crc=1,finobt=1,rmapbt=0 -i nrext64=0 -f /dev/mdXp1

in Maintenance Mode and was able to get the reserved space down to 195 GB again.

Edited December 28, 2025Dec 28 by lumyhm
typos

Looking at the description of the rmapbt option it looks like like this might reduce the chance of files ending up in the lost+found folder in the event you get file system corruption and have to run xfs_repair to fix it. Is this correct, and if so maybe it is worth the overhead? If not what is the purpose of that option?

Also note that option will basically disable the online scrubbing ability for XFS, and that is supported by default from kernel 6.18, likely on Unraid 7.3, so not really sure it's a worthwhile tradeoff to gain a few GBs.