According to this page [and several others I've read] exFAT is not used for HDDs:obviously NTFS needs to write something for 5TB.. but 300 for a not-ever-used New external drive seems odd and I just don't know how the NTFS file system works..
exFAT Versus FAT32 Versus NTFS | a Tech-Recipes Tutorial
From another forum about NTFS:Interestingly enough, exFAT is not used and was not designed for formatting hard drives. It is only recommended in flash memory storage and other external devices only. This is why it is currently not considered a huge competitor to NTFS on hard drives.
filesystems - Newly formatted (NTFS) external hard drive already has 'Used space'. What determines the used space's amount? Is it correlated to the HD's capacity? - Super User
Yes, thank you for that, I've already been through tons of reading with Ex-fat vs NTFS..
I may start again to read all that but all I remember is the major difference is that NTFS journals and writes all the time little bytes of info so you can more easily recover your file information..
exfat just is plain storage apparently.. but the funny thing is EX-fat is newer and fixes a lot of things that fat32 had missing etc...
ExFAT was designed as an improvement over FAT 32 for removable drives. It provides for files over 4 GB and some features of NTFS. NTFS was never designed for removable drives and has some issues when used this way.
NTFS is an advanced and complex file system and many of the details have never been publicly documented. The file system has some metadata used to manage the storage space, some of which is permanently allocated up front. In some cases the amount of space allocated is proportional to the disk size. But don't make the mistake of calling this bloat. In absolute terms 300 MB might seem large but compared to the total of 4.5 TB it is less than .01%. I would call that very efficient.
While not immediately apparent any file system has unusable space that far exceeds that. In FAT 32 and exFAT every file consumes a minimum of one cluster (usually 4096 bytes), even if the file has zero size. In NTFS it is rather more complicated than that and may be more or less. And that is only an example.
Roughly 137 MB on a 4.5 TB drive will be for the $Bitmap file. This is a special NTFS metadata file that cannot be shown by standard utilities. It contains one bit for each cluster on the drive used to keep track of which clusters are available. FAT 32 uses a different method using a linked list that uses 4 bytes for each cluster, 8 bytes for exFAT. But unlike NTFS this is allocated on an as needed basis.
NTFS has many metadata files, some of which are quite large. These files are created when the drive is formatted and are not visible to Windows Explorer or similar utilities.
The largest metadata file will usually be the $MFT. It has an entry for each file and directory on the drive. The size of this entry is not officially documented but I believe is a minimum of 1024 bytes. The MFT grows as files are added. The article linked to by Cliff s says that 12.5% to 50% of the volume will be reserved for the MFT to minimize MFT fragmentation. That is not what it may appear. This is a consecutive block of disk space that the file system will avoid using if possible. But this space is considered available and will be used if required.
But relatively speaking the space consumed by the metadata (excluding the MFT) is very small. On a 4.5 TB volume it initially consumes a mere 300 MB or less than .01%.
Just found this:
NTFS is a journaling file system and uses the NTFS Log ($LogFile) to record metadata changes to the volume. It is a critical functionality of NTFS (a feature that FAT/FAT32 does not provide) for ensuring that its internal complex data structures (notably the volume allocation bitmap), or data moves performed by the defragmentation API, the modifications to MFT records (such as moves of some variable-length attributes stored in MFT records and attribute lists), and indices (for directories and security descriptors) will remain consistent in case of system crashes, and allow easy rollback of uncommitted changes to these critical data structures when the volume is remounted.
The USN Journal (Update Sequence Number Journal) is a system management feature that records (in $Extend$UsnJrnl) changes to files, streams and directories on the volume, as well as their various attributes and security settings. The journal is made available for applications to track changes to the volume. This journal can be enabled or disabled on non-system volumes.source
Segment Number File Name Purpose $MFT Describes all files on the volume, including file names, timestamps, stream names, and lists of cluster numbers where data streams reside, indexes, security identifiers, and file attributes like "read only", "compressed", "encrypted", etc. 1 $MFTMirr Duplicate of the first vital entries of $MFT, usually 4 entries (4 Kilobytes). 2 $LogFile Contains transaction log of file system metadata changes. 3 $Volume Contains information about the volume, namely the volume object identifier, volume label, file system version, and volume flags (mounted, chkdsk requested, requested $LogFile resize, mounted on NT 4, volume serial number updating, structure upgrade request). This data is not stored in a data stream, but in special MFT attributes: If present, a volume object ID is stored in an $OBJECT_ID record; the volume label is stored in a $VOLUME_NAME record, and the remaining volume data is in a $VOLUME_INFORMATION record. Note: volume serial number is stored in file $Boot (below). 4 $AttrDef A table of MFT attributes that associates numeric identifiers with names. 5 . Root directory. Directory data is stored in $INDEX_ROOT and $INDEX_ALLOCATION attributes both named $I30. 6 $Bitmap An array of bit entries: each bit indicates whether its corresponding cluster is used (allocated) or free (available for allocation). 7 $Boot Volume boot record. This file is always located at the first clusters on the volume. It contains bootstrap code (see NTLDR/BOOTMGR) and a BIOS parameter block including a volume serial number and cluster numbers of $MFT and $MFTMirr. 8 $BadClus A file that contains all the clusters marked as having bad sectors. This file simplifies cluster management by the chkdsk utility, both as a place to put newly discovered bad sectors, and for identifying unreferenced clusters. This file contains two data streams, even on volumes with no bad sectors: an unnamed stream contains bad sectors—it is zero length for perfect volumes; the second stream is named $Bad and contains all clusters on the volume not in the first stream. 9 $Secure Access control list database that reduces overhead having many identical ACLs stored with each file, by uniquely storing these ACLs in this database only (contains two indices: $SII (Standard_Information ID) and $SDH (Security Descriptor Hash), which index the stream named $SDS containing actual ACL table). 10 $UpCase A table of unicode uppercase characters for ensuring case-insensitivity in Win32 and DOS namespaces. 11 $Extend A filesystem directory containing various optional extensions, such as $Quota, $ObjId, $Reparse or $UsnJrnl. 12–23 Reserved for $MFT extension entries. Extension entries are additional MFT records that contain additional attributes that do not fit in the primary record. This could occur if the file is sufficiently fragmented, has many streams, long filenames, complex security, or other rare situations. 24 $Extend\$Quota Holds disk quota information. Contains two index roots, named $O and $Q. 25 $Extend\$ObjId Holds link tracking information. Contains an index root and allocation named $O. 26 $Extend\$Reparse Holds reparse point data (such as symbolic links). Contains an index root and allocation named $R. 27— Beginning of regular file entries.
Great so I should attempt to disable journal on the non-os external drive and see if that has any difference..
It's also a 5 Terabyte drive.. not 4.5.. but maybe thats part of the scheme they use to sell the drive..