Which built in (if any) tool can I use to determine the allocation unit size of a certain NTFS partition ?
-
7This Q clearly belongs to SuperUser. – Free Consulting Mar 06 '17 at 03:25
12 Answers
Open an administrator command prompt, and do this command:
fsutil fsinfo ntfsinfo [your drive]
The Bytes Per Cluster is the equivalent of the allocation unit.
-
hand command but I think that just gives bytes per sector of your drive rather than the actual allocation unit? – dublintech May 25 '12 at 09:59
-
As far as I can tell, "Bytes Per FileRecord Segment" is what you can specify as the "Allocation unit size" in the Format dialog. – Kirill Osenkov Oct 19 '12 at 02:30
-
4@KirillOsenkov: Nope, William is correct, it's "Bytes Per Cluster". I just formatted a drive and checked. – Allon Guralnek Jun 09 '14 at 12:45
-
6You have to have Administrator privilege to execute the command – Andrea Antonangeli Jun 30 '15 at 15:23
-
5This is great but doesn't work for removable drives: "The FSUTIL utility requires a local NTFS volume." – Gaia Dec 14 '16 at 23:26
-
Use diskpart.exe
.
Once you are in diskpart select volume <VolumeNumber>
then type filesystems
.
It should tell you the file system type and the allocation unit size. It will also tell you the supported sizes etc. Previously mentioned fsutil
does work, but answer isn't as clear and I couldn't find a syntax to get the same information for a junction point.
-
4Great answer! Since this method doesn't require NTFS volume and can be other types. +1 – Chef Pharaoh May 19 '17 at 14:27
-
-
It does work with USB flash drives. I use this method almost exclusively for portable storage devices. I just used it today to get the allocation unit size of my 15 years old (year 2006 model) 2 GB SanDisk Cruzer Titanium USB flash drive, using Windows 10 build 21390.2025 (Dev channel Insider build). This has worked with USB flash drives at least since the age of Windows XP. – Samir Jul 24 '21 at 13:12
I know this is an old thread, but there's a newer way then having to use fsutil or diskpart.
Run this powershell command.
Get-Volume | Format-List AllocationUnitSize, FileSystemLabel

- 581
- 4
- 6
-
1
-
1For Windows 10 users that come across here, in powershell: `Get-Disk | Format-List` – David d C e Freitas May 29 '19 at 14:30
-
this came up today for me in a forensics class when discussing how to figure out cluster size on a drive.. people where trying the 'make small file and look at properties' method described on one answer, and that no longer works on modern versions of windows. – Chuck van der Linden Jun 13 '20 at 21:56
-
1@ChuckvanderLinden it still works, you just have to write plenty more data. NTFS now stores content up to 1KB right next to the file record in the attribution table thus, on disk, there is nothing to store. If you do exceed 1KB you'll see that the size on disk will probably jump to 4096 bytes (or whatever your unit size is). – Frankie Oct 25 '22 at 19:57
Another way to find it quickly via the GUI on any windows system:
create a text file, type a word or two (or random text) in it, and save it.
Right-click on the file to show Properties.
"Size on disk" = allocation unit.

- 271
- 2
- 2
-
5Probably obvious to most people but the "random text" needs to be smaller than your cluster size, ie don't put in a few KB of random text. For the moment a single character should be fine. – thomasrutter Mar 09 '15 at 11:47
-
If you're adverse to creating a file, a shortcut will almost certainly be smaller than your cluster size, and so could be used instead. – FuriousFolder Aug 06 '15 at 16:04
-
3I tried this, but it shows size on disk = 0 bytes, while size = 15 bytes (i.e. the number of characters i wrote). : \ – KeyC0de Feb 06 '16 at 20:56
-
2This doesn't work on Windows Server 2012 R2. Size is shown as 9 bytes, Size on disk 0 bytes – Boris Hurinek Oct 07 '16 at 20:07
-
15@BorisHurinek, this is because answer is catastrophically invalid. NTFS stores tiny files directly into MFT's FileRecord.trailer. – Free Consulting Mar 06 '17 at 03:28
-
1
-
1@FreeConsulting. They are not stored in a separate file up to 696 bytes. Over that, it will be in an explicit file, and will stay that way, even if some contents deleted to below 696. However, if that lesser content is then written to a new name, it will not be an explicit file. – Patanjali Sep 19 '19 at 05:11
-
@Patanjali, any citation on this exact number? Its been a long time since I did that research but IIRC amount of free trailer space depends on the other FileRecord content which is variable too. – Free Consulting Jan 28 '20 at 17:36
-
@FreeConsulting. Just empirically derived from direct experimentation. However, I cannot remember if I took path size into account. I have used non-content linearly-structured (. separated) file entries for things like status or logging, but this shows that it can contain a fair amount of content, so can be used for small xml or json files for more complex structured data. – Patanjali Jan 30 '20 at 00:08
-
Under Windows 10, allocation units can be 512B up to 2MB. The default is 4kB, which is mandatory for the C: drive when installing Windows, as it now reformats the drive rather than just install into the existing format like it used to. – Patanjali Jan 30 '20 at 00:22
-
Larger allocation unit sizes can result in much faster reads and writes, even on hard drives. Transferring a GB of mixed sized files between hard drives was 30-50% faster with 64kB units compared to 4kB. It appears that there is substantial OS overhead in handling drive IO, so the less the better. If using SSDs, 256kB units mean no blocks share files, so no write amplification. Audio and video files are substantially bigger than this, so there should be below 0.5% wasted space due to incomplete blocks at the end of files. – Patanjali Jan 30 '20 at 00:30
-
@Patanjali: Just tested on Windows 10 on the root of a NTFS volume and the switchover from saving in the MFT to a separate file was 729 bytes (no line endings). For 728 characters and fewer, the `Size on disk` was 0. The file name was `fred6.txt`. Probably the path and filename all count towards the switchover point. – AlainD Mar 24 '20 at 18:24
-
@AlainD. I suspect that there is a fixed amount of memory allocated to each directory entry, as that allows fast processing without lookup tables, saving a step. Any memory not used for paths and status information will be available for alleviating the extra disk access to get small amounts of content. – Patanjali Mar 26 '20 at 00:58
-
1This answer is wrong and misleading. I've seen cases where an NTFS volume was formatted with an Allocation Unit Size of 16KB but the Size on Disk still reads as 4KB, 8KB (when a bit more is added), etc. Stick to the `fsinfo` or `diskpart` answers. – rkagerer Feb 13 '21 at 09:11
-
1God forbid you have a 1MB allocation unit size (as was default on this SanDisk 1TB SSD purchased in June 2022) and 1,000,000 small files, say 1KB each. 1GB size becomes 1TB and you run out of space (would be 4GB at default 4KB). – john v kumpf Jun 25 '22 at 22:49
The value for BYTES PER CLUSTER - 65536 = 64K
C:\temp>fsutil fsinfo drives
Drives: C:\ D:\ E:\ F:\ G:\ I:\ J:\ N:\ O:\ P:\ S:\
C:\temp>fsutil fsinfo ntfsInfo N:
NTFS Volume Serial Number : 0xfe5a90935a9049f3
NTFS Version : 3.1
LFS Version : 2.0
Number Sectors : 0x00000002e15befff
Total Clusters : 0x000000005c2b7dff
Free Clusters : 0x000000005c2a15f0
Total Reserved : 0x0000000000000000
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Bytes Per Cluster : 4096
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x0000000000040000
Mft Start Lcn : 0x00000000000c0000
Mft2 Start Lcn : 0x0000000000000002
Mft Zone Start : 0x00000000000c0000
Mft Zone End : 0x00000000000cc820
Resource Manager Identifier : 560F51B2-CEFA-11E5-80C9-98BE94F91273
C:\temp>fsutil fsinfo ntfsInfo N:
NTFS Volume Serial Number : 0x36acd4b1acd46d3d
NTFS Version : 3.1
LFS Version : 2.0
Number Sectors : 0x00000002e15befff
Total Clusters : 0x0000000005c2b7df
Free Clusters : 0x0000000005c2ac28
Total Reserved : 0x0000000000000000
Bytes Per Sector : 512
Bytes Per Physical Sector : 512
Bytes Per Cluster : 65536
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x0000000000010000
Mft Start Lcn : 0x000000000000c000
Mft2 Start Lcn : 0x0000000000000001
Mft Zone Start : 0x000000000000c000
Mft Zone End : 0x000000000000cca0
Resource Manager Identifier : 560F51C3-CEFA-11E5-80C9-98BE94F91273

- 51,713
- 20
- 123
- 112

- 81
- 1
- 1
-
1My favorite though this assumes a drive letter is assigned and won't work for "drives" if mounted with a path. As a workaround, of course a drive letter can be assigned temporarily. – rainabba Dec 17 '16 at 19:31
Easiest way, confirmed on 2012r2.
- Go to "This PC"
- Right click on the Disk
- Click on Format
Under drop down "allocation unit size" will be the value of what the Allocation of the Unit size disk already is.

- 71
- 1
- 1
-
Not working on my Win 10 Pro v2004... Just says "Default" for all drives. – n00dles Aug 06 '20 at 19:34
-
2Wow, this is a good answer that shows this info, `Get-Disk | Format-List` does not show this info, but `Get-Volume | Format-List` does. It's interesting because, you would think that Allocation Unit would correlate with Blocksize on `Get-Disk | Format-List` but it does not. The Allocation Unit is why your files are larger on disk than the actual data they represent. – Timothy L.J. Stewart Mar 24 '21 at 17:52
In a CMD
(as adminstrator), first run diskpart
. In the opened program, enter list disk
. It'll list all connected disks.
Select the right disk based on its size. If it is flash memory, usually it'd be the last item in the list. In my case, I select the Disk 2
using this command: select disk 2
.
After selecting your disk, list the partitions using list partition
command. You'll get a list like the one in the image below.
Now, it is time to select the right partition, based on its size. In my case, I select Partition 1 using this command: select partition 1
.
Finally, you can run the filesystem
command to get the Allocation Unit Size
.
Note: This procedure works on both NTFS and FAT32 file systems.

- 103
- 3

- 385
- 6
- 10
According to Microsoft, the allocation unit size "Specifies the cluster size for the file system" - so it is the value shown for "Bytes Per Cluster" as shown in:
fsutil fsinfo ntfsinfo C:

- 742
- 10
- 10
The simple GUI way, as provided by J Y in a previous answer:
- Create a small file (not empty)
- Right-click, choose Properties
- Check "Size on disk" (in tab General), double-check that your file size is less than half that so that it is certainly using a single allocation unit.
This works well and reminds you of the significance of allocation unit size. But it does have a caveat: as seen in comments to previous answer, Windows will sometimes show "Size on disk" as 0 for a very small file. In my testing, NTFS filesystems with allocation unit size 4096 bytes required the file to be 800 bytes to consistently avoid this issue. On FAT32 file systems this issue seems nonexistent, even a single byte file will work - just not empty.

- 158
- 1
- 6
start > run > MSINFO32
goto components
goto storage
goto disk
on the right look for Bytes/Sector

- 29
- 1
-
3This is a property of your disk and not the allocation size of a specific partition on that disk. – Sebastian Wahl Mar 28 '14 at 18:53
-
This will not show cluster size for filesystems, but rather sector size of underlying physical media. – Free Consulting Mar 06 '17 at 03:43