What Allocation Unit Size Should VMS Drives Use?

Avatar
Ethan Ace
•Jul 31, 2018

This topic came up as I was formatting new archive drives in test servers this morning. Milestone's documentation recommended allocation unit be set to 64 KB for archive drives. I hadn't really ever considered the topic before.

What's your opinion? Do you use larger size or stick with default (4KB)? Why/Why not?

For those unfamiliar, allocation units (aka "clusters" or sometimes/possibly incorrectly "blocks") defines the size of individual "containers" on disc. So if you have a file that is 100 KB using 64 KB allocation units, it is stored in two allocation units, one full (64 KB) and another containing 36 KB, with the remaining 28 KB of that allocation unit wasted, as a separate file cannot be stored there (64 - 36 = 28 KB). Theoretically, the larger allocation units could speed up read speeds, but there also may be little practical difference.

UI
Undisclosed Integrator #1
•Jul 31, 2018

Simply based on the old Milestone recommendation I have stuck with 64K allocation size with all VMS.  There may be some usable storage loss because of this.  However, I would prefer to maximize performance at the cost of a little bit of usable storage every time.  AFAIK no other VMS makes recommendations on the allocation unit size.

(1)
(2)
U
Undisclosed #2
•Jul 31, 2018

I have stuck to reading the white paper recommendations and constraints regarding KB size writing. This way should an issue arise I have the MFG support if things go awry.

Example, Had a customer supplying, growing multiple LUNS in flash storage array prior to HPE acquire: https://www.nimblestorage.com/partners/ and the limitation of Nimble Array was a less than 64KB write size. I noticed anomalies with different FPS, Cam Resolutions in H.264. During playback sometimes within the H.264 frames people would be missing a hand, or be cut in half. Wish I had more time to analyze the degraded frame by frame comparisons but life moves too fast. This was on Milestone Xprotect 2014.  

Anyone else have anomalies?   

UI
Undisclosed Integrator #3
•Jul 31, 2018

We used to change this on systems we configured but our VMS' developers now state that they have no preference and recommend leaving it at default. We ran some performance tests for fun and found negligible difference either way.

(1)
SC
Sean Chang
•Jul 31, 2018
Rasilient Systems

Go with 64K. It helps the recording performance, but this would only matter when the recording load is close to the limit.

In general, we want to match the application data size with the storage size to reduce the overhead going through the system. For database and general office apps, it is 4K. For video, it is much bigger, and the biggest allocation size from NTFS is 64K.

There is also the overhead from NTFS meta-data. If the volume is huge with many files, the meta-data grows with them. Microsoft has to lay out the expanded locations of meta-data to ensure the performance. Smaller allocation size would need more meta-data and all the management associated with it.

(2)
(4)
Avatar
Josh Hendricks
•Jul 31, 2018
Milestone Systems
In reply to Sean Chang

but this would only matter when the recording load is close to the limit.

Exactly this. I wish I had some performance metrics handy, but I've definitely witnessed performance improvements using 64 KiB instead of 4/8 KiB allocation unit size. That said, most of the time a well-designed storage system is not going to be maxed out under normal circumstances so you shouldn't see much difference in most cases.

We don't use SQL for media storage, but FWIW Microsoft recommends 64 KiB allocation unit size for SQL databases, logs, and tempdb.

SQL Server Best Practices

One of the effects of 64 KiB vs 4 KiB allocation unit size is that the minimum allocation of disk space for data is 64 KiB. That means a 1 KiB file will use 64KiB of disk space and a 65 KiB file will use 128 KiB of disk space.

Because of the "lower resolution" of storage (same file is broken into fewer chunks) when using 64 KiB, there will be slightly more storage space wasted if not all files are filled to a 64 KiB boundary.

In Milestone software, block files containing media data are pre-allocated in 16 MiB blocks by default and filled to capacity before allocating the next block. When a period of data is archived, the last block will be truncated, so the last block may have up to 63 "empty" kibibytes. But there are not typically a massive number of truncated blocks. Some of the metadata files (indexes and such) are not necessarily aligned to 64 KiB boundaries, but again it's not a lot of wasted space and I haven't yet heard of a situation where the extra unusable space was more important than optimizing I/O.

(5)
(3)
SD
Shannon Davis
•Jul 31, 2018
IPVMU Certified

With the cost of storage coming down drastically in the past several years the amount of storage you might lose due to the block sizes to me isn't really even a consideration when it comes to the better performance you will get.

(4)
New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions