3

I have a Toshiba HDWA130 HDD that I am going to use to store exclusively files greater than 1GB.

I am going to format the disc with NTFS and use it only in Windows, connected via USB 3 (UASP).

My doubt: Any drawback in use an allocation unit size of 2048 kilobytes?

Thanks.

sawdust
  • 17,383
  • 2
  • 36
  • 47
Sprinter
  • 33
  • 1
  • 4
  • "the difference between SIZE and SIZE ON DISK may represent some wasted space because the cluster size is larger than necessary. You may want to use a smaller cluster size so that the SIZE ON DISK value is as close to the SIZE value as possible.">>>>>>>>>https://macrorit.com/partition-magic-manager/choose-cluster-size.html – Moab Jan 26 '20 at 21:28
  • Also read this>>>>>https://ejrh.wordpress.com/2012/10/26/cluster-size-experiment/ – Moab Jan 26 '20 at 21:30
  • The last link has solved my questions. Thanks, @Moab – Sprinter Jan 26 '20 at 22:45
  • You are welcome – Moab Jan 26 '20 at 22:47
  • 1
    @Moab since the OP is using the file exclusively for large files, it'll be more appropriate to use larger cluster sizes. That'll improve performance and reduce metadata overhead. A waste of 2KB is just negligible in a 1GB file – phuclv Jan 27 '20 at 01:57
  • This question is not a duplicate. This is a more focused question with a specific answer, whereas the other post seems to be answered with opinions (consider the numerous and various answers that disagree as well as several removed low-quality answers). – sawdust Jan 27 '20 at 02:50

1 Answers1

3

Any drawback in use an allocation unit size of 2048 kilobytes?

Since I wrote an answer to Downsides of a small allocation unit size, it would seem appropriate to consider the alternative.

The downsides of a large filesystem allocation unit (such as the proposed 2 megabytes) include:

  • Large I/O operations will consume long intervals of time.
    Assuming that the disk I/O for a cluster will be optimized by using a single (multi-sector) read or write ATA command, such an I/O operation would tie up the I/O channel (i.e. SATA or USB for an external drive) and delay any other operations.
    Other active processes could suffer delays in satisfying their I/O requests.
    Note that older versions of ATA (e.g. version 3) limited the sector count in a multi-sector operation to 255. Your proposed 2MB cluster size is equivalent to 4096 (512-byte) sectors.

  • Large memory buffers.
    Every open or active file will typically require system buffers matching the allocation size (unless direct I/O is performed).
    Modern DMA controllers have scatter/gather capability, so these buffers do not require physically contiguous RAM. X86 system (typically) do not have IOMMUs (yet), so there is some added overhead when dealing with such large DMA buffers.
    If your system has a lot of RAM (as some 64-bit systems do), then this may not be a significant concern at all.

  • Slack space is increased.
    This would probably be the most obvious downside of a very large allocation size. Every file is likely to have a remnant of unused space in its last cluster.
    As the allocation size is increased, the potential for more unused (and wasted) space as slack space is increased.
    But increased slack space is typically accepted as a tradeoff for increased storage capacity while maintaining a reasonable quantity of allocation units (i.e. avoiding an overly large allocation table).

The last link has solved my questions

Beware that the metrics were primarily the time to perform the I/O operations.
A large cluster size should reduce some CPU processing (e.g. fewer clusters to allocate, fewer I/Os to perform), which can result in improved multiprocessing performance, and may not be reflected in the time to perform the I/O operations.

sawdust
  • 17,383
  • 2
  • 36
  • 47
  • I should have said it in my question, sorry: The disc will be used as read-only. Almost exclusively, for random reads. Thanks. – Sprinter Jan 27 '20 at 11:16