XFS - Discard Option for Repository

[EricinIT]

We're using some Linux XFS repositories for immutable backup storage with hardened repositories backing Cloud Connect Tenants. Our new storage vendor (Pure Storage) recommends mounting Linux file system with the discard option set. This sends UNMAP to the storage array so it knows to clear the blocks that were previously used by deleted files.

In the setup documentation for Configuring a Linux Repository, the discard option is not present - https://helpcenter.veeam.com/docs/backu ... repository. Is there a reason that adding the discard option would cause issues within Veeam?

mount /dev/sda1 /backups -o discard

It seems like it's just sending a command to the storage array if its set.

[jorgedlcruz]

Hello,
There is not much information around about XFS reflink, plus discard option. And even about the discard flag there can be found not that promising threads and some interesting discussions.

As it is an operation that requires the storage array to support it, is better not to add it to the general guidance, as we tend to see the likes of HPE Apollos, or Dell servers plus storage/DAS, etc.

Perhaps Pure can give a bit more examples and experiences with Customers using XFS with reflink and the discard flag.

[EricinIT]

Ok, thanks for the info.

[tsightler]

Last I checked, even the man page of XFS still recommends against using this option due to the negative performance impact, so I'm quite surprised Pure recommends it, although I will admit that Pure's trim operations are significantly faster than, for example, a basic SSD. Still, I think I'd recommend scheduling fstrim during low activity periods instead. That should be safe and you can be sure it will have no performance impact during backup or fast clone operations.

[DonZoomik]

reflinks is about stuff within XFS and discard is about XFS interaction with underlying block device. It works just the same with reflinks - if a block becomes unused (and is within aligment), a TRIM(SATA)/UNMAP(SCSI)/Deallocate(NVMe) command is sent to the block device.

In my experience, the warning about discard is largely due to old SATA SSD-s where TRIM was a blocking exclusive non-queueable command that many devices didn't handle well. Most newer stuff handles it pretty good.
Some older SANs choke when hundreds of GBs are UNMAP-ed at once - VMware's UNMAP throttling plays an important mitigating role here, a feature that is not present on Linux and Windows. Some cheap QLC SSD-s (Samsung 870 QVO...) also seem slow down.

But on Pure, go ahead, it doesn't skip a beat on it (I run Pure as well, but on primary workloads).

PS! IMHO it's advantageous to enable both discard and fstrim (scheduler). Inline discard may not be able to do it's job due to alignment problems (deleting 4K file does nothing as alignment might be 256K or 1M) but by the time fstrim runs, the range might be big enough (a lot of small files were deleted to free up whole 256K or 1M block) to do the job. You might get some space back immediately but fstrim will clean up the rest.

[beshka]

Hi Mihkel,

As you mentioned, it's a matter of communication between os and storage, meaning - transparent for VBR itself. And it was a bit thing on a start of SSD era.
However, with modern controllers and overprovisioned spare space, it's pretty disputable if you need TRIM at all.

Fully agreed with Tom that the community is still skeptical about discard. Partially because of initial performance issues, critical data corruption bugs and current devices blacklist). Again, multiply it on "do you really need trim?" question

Considering the type of Veeam data, I don't see a huge improvement in using both options for Veeam repository. The general approach is one or another.