Comprehensive data protection for all workloads
Post Reply
spiritie
Service Provider
Posts: 193
Liked: 40 times
Joined: Mar 01, 2016 10:16 am
Full Name: Gert
Location: Denmark
Contact:

Server 2019 NTFS Allocation unit size

Post by spiritie »

Hi Veeam Forums

I can see in Server 2019, it it now possible to create NTFS block sizes above 64K (Can now choose, 128K, 256K, 512K, 1M, 2M).
I don't remember seeing this in Server 2016, so must be new for 2019 only?

When using stripe size of 256KB on my RAID6, is it then recommended to use 256KB in Windows aswell? Or keep this at 64K as
recommended here on forums and on VeeamBP: https://www.veeambp.com/repository_serv ... em-formats

\\Gert
Egor Yakovlev
Product Manager
Posts: 2578
Liked: 707 times
Joined: Jun 14, 2013 9:30 am
Full Name: Egor Yakovlev
Location: Prague, Czech Republic
Contact:

Re: Server 2019 NTFS Allocation unit size

Post by Egor Yakovlev » 1 person likes this post

Hi Gert,
Yes, higher block sizes are new to Windows Server 2019 with potential volume size maximum of 8PB with 2MiB block size!
Note that Best Practices guide also recommends to keep block size\stripe size aligned with Veeam backup chunk size as much as possible too - having that said, you might easily get 4x improvement in required write IO with default 1MB(local target) Veeam chunks. "Might" in my previous statement heavily relies on your RAID controller and it's ability to handle big stripes at ease. I would strongly recommend to put your RAID to test before implementing it for production use - create 2 volumes and format one with 64K block size, another with 256K - add both volumes as a repositories to Veeam, perform backup and compare load on your storage with both. It's also worth testing synthetic operations(like Retention or Synthetic Full) to see read performance difference with bigger block size.
Hope that helps!
DonZoomik
Service Provider
Posts: 372
Liked: 120 times
Joined: Nov 25, 2016 1:56 pm
Full Name: Mihkel Soomere
Contact:

Re: Server 2019 NTFS Allocation unit size

Post by DonZoomik »

I saw these new cluster sizes some time ago and though that they were a bug. Is there any documentation on them? Are they backwards compatible?
Gostev
Chief Product Officer
Posts: 31804
Liked: 7298 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Server 2019 NTFS Allocation unit size

Post by Gostev » 1 person likes this post

Egor Yakovlev wrote: Jan 21, 2020 5:10 pmNote that Best Practices guide also recommends to keep block size\stripe size aligned with Veeam backup chunk size as much as possible too
@Egor Yakovlev don't confuse "NTFS block size" with "RAID stripe size", or use them interchangeably. These are two absolutely different things! The first one does not have material impact on backup performance even with low values (as all I/O goes through Windows system cache anyway). However, the second one is extremely important for performance (recommended values are 128KB or 256KB).

For "NTFS block size" (file system cluster size), previous recommendation was 64KB. This was not from performance perspective (it makes no difference there), but just because it helps to avoid excessive file system fragmentation.
Egor Yakovlev
Product Manager
Posts: 2578
Liked: 707 times
Joined: Jun 14, 2013 9:30 am
Full Name: Egor Yakovlev
Location: Prague, Czech Republic
Contact:

Re: Server 2019 NTFS Allocation unit size

Post by Egor Yakovlev »

Sorry for confusion with "keep block size\stripe size aligned" it was meant to be "and" operator here, of course, without idea of interchanging one into another. In terms of block size influence for performance, I will have it double checked.
Borg
Enthusiast
Posts: 26
Liked: 3 times
Joined: Nov 20, 2017 7:51 am
Full Name: Borg Eternal Emperor
Contact:

Re: Server 2019 NTFS Allocation unit size

Post by Borg »

Choosing the block size depends on what files you want to hold there.
If you use very large files that you don't alter very often, you can safely use the most large block size you can select.
If you use dozens of thousands of small files and/or if your data modifies a lot, then you should select the smallest available block size.
This helps both performance and space allocation (as in not wasting it).
YouGotServered
Service Provider
Posts: 176
Liked: 53 times
Joined: Mar 11, 2016 7:41 pm
Full Name: Cory Wallace
Contact:

Re: Server 2019 NTFS Allocation unit size

Post by YouGotServered »

Just to clarify here -

Veeam processes data in 512KB chunks, then after compression, we're looking at about 256KB, right?

As long as all is happy with the RAID controller, it would make the most sense to use 256KB allocation unit size (or RAID stripe size), correct? And even if there isn't a big performance impact, I may as well use 256KB NTFS block size, right? Or should I use something smaller if we have a lot of small files?

If I were to use 64KB NTFS block size, would that still take up a 256KB stripe on the RAID array, or would I just be able to fit 4x 64KB chunks on the RAID stripe?

Thanks for the help - I didn't major in storage in school :)
Egor Yakovlev
Product Manager
Posts: 2578
Liked: 707 times
Joined: Jun 14, 2013 9:30 am
Full Name: Egor Yakovlev
Location: Prague, Czech Republic
Contact:

Re: Server 2019 NTFS Allocation unit size

Post by Egor Yakovlev »

Veeam's Default block size is 1024 KB(tuned in job settings Storage - Advanced tab), so after compression it will be roughly 512 KB.
And yes, you will be able to fit enough chunks to fill the stripe, RAID controller will take care of it.
/Cheers!
YouGotServered
Service Provider
Posts: 176
Liked: 53 times
Joined: Mar 11, 2016 7:41 pm
Full Name: Cory Wallace
Contact:

Re: Server 2019 NTFS Allocation unit size

Post by YouGotServered »

Ah duh, thanks. Would I be crazy to set NTFS block and RAID stripe size to 512KB? Would that give better performance but usually end up with a lot of wasted space? So Veeam would suggest that a 256KB size is the best mix of space utilization and performance?

Source, for anyone interested: https://www.veeambp.com/repository_serv ... y_planning
Post Reply

Who is online

Users browsing this forum: laurentG, peeky1323 and 142 guests