Sector size and performance

[Juddog]

How big of a difference in performance is there from optimizing sector size?

After reading through some of the posts here, I ran the HD Tune on my Intel SSD and noticed that it says the sectors are 512 bytes. I'm wondering now whether it's worth going through the trouble of changing the sector size to be optimal and how much boost in performance this would give.

 

[mv2devnull]

Logical sector size of filesystem? I thought that one cannot change the physical sector size.

Furthermore, isn't the main focus of SSD optimizations in alignment?

 

[Nothinman]

As long as it's aligned it shouldn't be that big of a deal. Your filesystem clusters are probably 4K so if they're aligned properly they'll cover 8 512b clusters evenly, you get performance issues with misalignment because the overlap causes more read/write cycles.

 

[tweakboy]

Cluster size for drives is usually 4KB. It should say on specs... my F4 is 512 bytes in specs so I had to format it properly and the speed boost was amazing from 4KB. But that is my drive,, its specs say 512 bytes ,, I would leave yours alone you may lose performance by tinkering with it.

 

[Voo]

Cluster size for drives is usually 4KB. It should say on specs... my F4 is 512 bytes in specs so I had to format it properly and the speed boost was amazing from 4KB.

Except since 4kb is a multiple of 512byte it won't harm at all as long as it's still aligned (which incidently is true for every OS out there and could also be a problem with 512byte) so I pretty much doubt that.

 

[sub.mesa]

Sector size is not the same as Cluster size. Sector size is the smallest block size the storage drive would accept; you can only write in chunks of 512 bytes. Thus if you need to write 600 bytes, the filesystem would read the 412 bytes and then write a total of 1024 bytes. So all I/O done to a block-level storage device must be in multiples of the sector size!

The cluster size is different, it's the smallest size for the filesystem to store one file. If a cluster is 8KiB and your file is only 1KiB, it will use the other 7KiB as slack space; unused wasted space. Normally cluster size is better kept rather low.

Third there is stripesize, which applies to RAID0 or other striping RAIDs (4,5,6).

To benchmark your SSD use either AS SSD or CrystalDiskMark. The random scores would be most important for your system disk function.

 

[Voo]

The cluster size is different, it's the smallest size for the filesystem to store one file. If a cluster is 8KiB and your file is only 1KiB, it will use the other 7KiB as slack space; unused wasted space. Normally cluster size is better kept rather low.

Well that and it should be a multiple of the sector size - and not too low to keep overhead in check.

 

[Juddog]

Sector size is not the same as Cluster size. Sector size is the smallest block size the storage drive would accept; you can only write in chunks of 512 bytes. Thus if you need to write 600 bytes, the filesystem would read the 412 bytes and then write a total of 1024 bytes. So all I/O done to a block-level storage device must be in multiples of the sector size!

The cluster size is different, it's the smallest size for the filesystem to store one file. If a cluster is 8KiB and your file is only 1KiB, it will use the other 7KiB as slack space; unused wasted space. Normally cluster size is better kept rather low.

Third there is stripesize, which applies to RAID0 or other striping RAIDs (4,5,6).

To benchmark your SSD use either AS SSD or CrystalDiskMark. The random scores would be most important for your system disk function.

Crystal mark results (I still haven't signed up with a free image host):
Read / Write
Seq: 236.7, 96.97
512K: 179.4, 67.91
4K: 11.86, 20.21
4K QD32: 153.5, 40.78

 

[sub.mesa]

The 4K random writes show heavy degradation; a non-degraded Intel would show all write scores about the same, random write or sequential write wouldn't make that much difference.

Check if you are running with TRIM enabled; download AS SSD and check if you see msahci.sys/pciide.sys or iastor.sys on top; the storage driver in use. If you see something else, then you won't have TRIM capability.

How full is your intel SSD's filesystem?

 

[Juddog]

The 4K random writes show heavy degradation; a non-degraded Intel would show all write scores about the same, random write or sequential write wouldn't make that much difference.

Check if you are running with TRIM enabled; download AS SSD and check if you see msahci.sys/pciide.sys or iastor.sys on top; the storage driver in use. If you see something else, then you won't have TRIM capability.

How full is your intel SSD's filesystem?

TRIM is enabled, as is the proper AHCI drivers.

The drive is encrypted, however, which probably takes a big hit on performance.

 

[Juddog]

Cluster size for drives is usually 4KB. It should say on specs... my F4 is 512 bytes in specs so I had to format it properly and the speed boost was amazing from 4KB. But that is my drive,, its specs say 512 bytes ,, I would leave yours alone you may lose performance by tinkering with it.

Someone on the Intel forums mentioned that they had better results using a 4KB format, so I'm debating whether I should repartition or not.

 

[sub.mesa]

4KiB should be the default; did you override this number when creating your partition? If not, you would not have to change it.

Also again: cluster size is something different than sector size; do not confuse these two things! Repartitioining has nothing to do with cluster size; cluster size is an NTFS property, and as such can be changed when reformatting an existing partition with a different cluster size; but this is very different from partition alignment which deals with sector sizes instead.

The partition alignment at 2048 sectors (1MiB) is good and no reason to change it. But you can play with changing the cluster size. Seriously; leave it at 4KiB! Your SSD has 4KiB pages so this should be the best value.

The cluster size essentially is the guessed average file size on the filesystem. For your system volume, this should be rather low. For a volume storing only large files, a higher cluster size would be more efficient. The higher the cluster size, the more space is wasted to 'slack'; only one file can occupy a cluster. So 64KiB clusters would mean 100 files of 1 byte instead of 100 bytes, consume 100*64KiB or 6,4 megabyte.

 

[Juddog]

4KiB should be the default; did you override this number when creating your partition? If not, you would not have to change it.

Also again: cluster size is something different than sector size; do not confuse these two things! Repartitioining has nothing to do with cluster size; cluster size is an NTFS property, and as such can be changed when reformatting an existing partition with a different cluster size; but this is very different from partition alignment which deals with sector sizes instead.

The partition alignment at 2048 sectors (1MiB) is good and no reason to change it. But you can play with changing the cluster size. Seriously; leave it at 4KiB! Your SSD has 4KiB pages so this should be the best value.

The cluster size essentially is the guessed average file size on the filesystem. For your system volume, this should be rather low. For a volume storing only large files, a higher cluster size would be more efficient. The higher the cluster size, the more space is wasted to 'slack'; only one file can occupy a cluster. So 64KiB clusters would mean 100 files of 1 byte instead of 100 bytes, consume 100*64KiB or 6,4 megabyte.

I didn't override any numbers when performing the format; I just went with the windows default.

Bytes per sector: 512
Bytes per Cluster: 4096
Bytes per FileRecord Segment: 1024

 

[Nothinman]

I didn't override any numbers when performing the format; I just went with the windows default.

Bytes per sector: 512
Bytes per Cluster: 4096
Bytes per FileRecord Segment: 1024

So you already have 4K clusters in the filesystem. Unless your SSD has an option, jumper, etc to switch between 512b and 4K sectors, you're stuck with 512b.

 

[Juddog]

So you already have 4K clusters in the filesystem. Unless your SSD has an option, jumper, etc to switch between 512b and 4K sectors, you're stuck with 512b.

Ah ok, thank you for the advice.

 

[tweakboy]

1 sector is 512 bytes 8 sectors is 4KB.

and yes Defragging is a must.

 

[mv2devnull]

1 sector is 512 bytes 8 sectors is 4KB.

No. In OP's case one sector happens to be 512 bytes. That is not true for all media. Although, 8*n naturally makes 8*n for every value of n.

and yes Defragging is a must.

OP has SSD, and more generally fragmentation has not been discussed in this thread -- not even for hard-drives -- so what do you mean by that claim?

 

[Voo]

OP has SSD, and more generally fragmentation has not been discussed in this thread -- not even for hard-drives -- so what do you mean by that claim?

You know, he just likes gibe advice even he knows is wrong and for whatever reason can do that times after times :/
Other obvious trolls usually get banned after their third dozen posts or so *cough*

 

[Juddog]

I grabbed my drive info from the command line: "fsutil fsinfo ntfsinfo c:"

I'm not sure what defragging would do, as this is an SSD. I had mentioned the sector size question because I've seen conflicting info regarding optimizing sector size, but if it's best to leave at 512 bytes I'll leave it there. TRIM is enabled, AHCI installed and enabled, and the TRIM is verified running via command line.

 

[tweakboy]

Oh yea Juddog 512 bytes is perfect for your drive cuz its small size. The larger the capacity then you use default 4KB

Leave it at 512 bytes youll get the proper performance... thx gl

 

[Nothinman]

Oh yea Juddog 512 bytes is perfect for your drive cuz its small size. The larger the capacity then you use default 4KB

Leave it at 512 bytes youll get the proper performance... thx gl

Read again, He's got 4K clusters, which is the default for NTFS and will almost always perform better than 512b clusters.

 

[Emulex]

i suggest for your application - ie sql server you regression test for yourself.

believe it or not you want very little read ahead cache (sql server) and alot of write back cache and both the underlaying stripe size and cluster size have a huge impact.

the paradigm of storage is changing - and it will come to low-end pc nas - but some old rules still apply - having a FWBC raid controller is nice because you can re-stripe a drive online or migrate from raid-10 to raid-5 online (and back if you have the disks) - and test your throughput.