I'm formatting a drive using NTFS which will be dedicated as a file share for users to centrally store their files. The files will likely be large (10's to 100's of megabytes).
Someone suggested that using a large allocation unit size than the default 4k (e.g. 64k) will make it perform better. I think I understand the basic principle behind it, but I'm not sure if its valid in practice. Will this truly make a difference or is this something that may cause more problems than it solves?
A larger allocation size will increase performance when using larger files. If they are all going to be large files then it might pay to increase the allocation size to 32KB or 64KB.
Be aware that the larger the allocation unit size, the more disk space that will be wasted. This is true regardless of the sizes of the files stored on the volume. If the allocation unit size is 64K and you save a 50K file, 14K will be wasted. If you save a 800K file, it will be divided into 13 chunks, but the 13th chunk will only have 32K of data resulting in 32K of wasted disk space.
A resource for performance tuning of NTFS drives can be found here: https://web.archive.org/web/20090724155321/http://www.windowsdevcenter.com/pub/a/windows/2005/02/08/NTFS_Hacks.html
Good luck, any further questions dont hesitate in asking.
Lima
Setting the allocation block size can improve performance for accessing large files, but it is unlikely to improve the performance of a network fileshare noticeably as other bottlenecks will dwarf any local benefit.
There are some things to look out for:
My gut suggests that you would not notice much benefit (or detriment) performance wise in must use cases, and my gut is quite large so I don't tend to argue with it, so I would stick with smaller cluster sizes for space use efficiency.
I think the general idea is that larger = better performance at the cost of disk space.
There is a rumble online that changing the default size will cause badly coded disk utilities to error or fail, so you might want to keep that in mind if you plan not to plan for backups ;-)