97

Which built in (if any) tool can I use to determine the allocation unit size of a certain NTFS partition ?

splattne
  • 102,760
  • 52
  • 202
  • 249

12 Answers12

175

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.

FireFaced
  • 102
  • 11
William
  • 1,945
  • 2
  • 14
  • 19
56

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.

Paul B.
  • 2,394
  • 27
  • 47
steven
  • 561
  • 4
  • 2
  • 4
    Great answer! Since this method doesn't require NTFS volume and can be other types. +1 – Chef Pharaoh May 19 '17 at 14:27
  • It works great, except it does not see any USB flash or hard drive. – dev101 Jun 20 '19 at 11:49
  • 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
32

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

SQLing4ever
  • 581
  • 4
  • 6
  • 1
    nice solution, but I would add DriveLetter as parameter too – Thomas Franz Apr 09 '19 at 15:44
  • 1
    For 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
19

Another way to find it quickly via the GUI on any windows system:

  1. create a text file, type a word or two (or random text) in it, and save it.

  2. Right-click on the file to show Properties.

  3. "Size on disk" = allocation unit.

J Y
  • 271
  • 2
  • 2
  • 5
    Probably 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
  • 3
    I 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
  • 2
    This 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
    20 years as a windows admin and TIL. – John Homer Oct 19 '17 at 14:47
  • 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
  • 1
    This 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
  • 1
    God 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
8

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
Dan Lowe
  • 51,713
  • 20
  • 123
  • 112
Aman Arora
  • 81
  • 1
  • 1
  • 1
    My 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
7

Easiest way, confirmed on 2012r2.

  1. Go to "This PC"
  2. Right click on the Disk
  3. Click on Format

Under drop down "allocation unit size" will be the value of what the Allocation of the Unit size disk already is.

Topsy K
  • 71
  • 1
  • 1
  • Not working on my Win 10 Pro v2004... Just says "Default" for all drives. – n00dles Aug 06 '20 at 19:34
  • 2
    Wow, 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
7

In a CMD (as adminstrator), first run diskpart. In the opened program, enter list disk. It'll list all connected disks. list disk

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. list partition

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. Allocation Unit Size

Note: This procedure works on both NTFS and FAT32 file systems.

Peter
  • 103
  • 3
Khalil Youssefi
  • 385
  • 6
  • 10
4

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:
robertcollier4
  • 742
  • 10
  • 10
3

You can use SysInternals NTFSInfo by Mark Russinovich from the command line and it converts fsutil fsinfo ntfsinfo into more readable information, especially MFT Table info.

Markus
  • 829
  • 7
  • 15
2

The simple GUI way, as provided by J Y in a previous answer:

  1. Create a small file (not empty)
  2. Right-click, choose Properties
  3. 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.

LinusSch
  • 158
  • 1
  • 6
1

from the commandline:

chkdsk l: (wait for the scan to finish)

sizdir32 http://www.ltr-data.se/opencode.html/

eadmaster
  • 1,347
  • 13
  • 23
-2

start > run > MSINFO32

goto components

goto storage

goto disk

on the right look for Bytes/Sector