Linux block alignment

[swilton]

I'm using a deduplicated filesystem in Linux with an 8kB block size, and noticed that when Veeam runs a merge operation it writes a lot of new blocks (i.e. it is not able to deduplicate the blocks as they are re-written to the filesystem). The repository has the "Align backup file data blocks" and "Decompress backup data blocks before storing" options selected. I have looked in the .vbm file, and can see BlockAlignmentSize="4096" repeated next to each file in the backup chain which would explain why the re-written data is not being deduplicated.

The first thing I would like to confirm is whether I have correctly interpreted the contents of the .vbm file regarding the filesystem block alignment?
If I am correct, I would like to know if Veeam uses the fstat() system call to determine the correct block size for the filesystem alignment, or if it's hard-coded at 4kB?
If it's not hard-coded, what alignment sizes are supported on Linux?
If it is hard-coded, would it be a big change to make it use fstat() to find the correct alignment? I know both 4kB and 64KB alignments are supported in ReFS

This question has been raised in case #02420347

[foggy]

Hi Steven, your support engineer should approach you with some recommendations on changing the block size used for alignment soon. Please check and share the results here. Thanks!

[swilton]

The response I got back from support was that the 4kB alignment is hard coded.

We're having performance issues with GFS restore points taking a long time to create because the data is stored in 4kB chunks. One fix would be for fast clone support to be brought to Linux (as discussed here veeam-backup-replication-f2/fast-clone- ... 38841.html), and the other would be to align the data in bigger blocks for deduplication.

Assuming the fast clone operation is not easy to implement (based on the discussion in the other thread), is there any chance that the data alignment can be made dynamic by using fstat() on the newly created file?

[foggy]

Hi Steven, I've noted your request. Btw, just for reference, what kind of dedupe storage do you have?

[swilton]

Hi Alexander, we've been using ddumbfs (http://www.magiksys.net/ddumbfs/) with some patches that improve performance. Having said this, this request would improve any deduplicated filesystem on linux (e.g. zfs/opendedup) as long as the filesystem uses a fixed block size and returns the correct block size to the fstat() system call.