Anyone tested NTFS performance at 8KiB+ allocation unit size?

[taltamir]

Since modern SSD's NAND is no longer 4KiB sectors but now 8KiB sectors internally, wouldn't using 8KiB allocation size unit improve performance on those?

Modern OS align to 1KiB which should result in correct alignment of the 8KiB FS allocation units and the 8KiB sectors on the drive.

 

[thm1223]

I'm going to bump this and if anyone can opine on the subject of allocation size and its effect(s) on SSD performance.

I just formatted a second SSD that I'm using as a separate partition, and selected a default allocation size. I would also like to know if anyone feels that RAID0 would provide greater benefits than 2 solo SSDs that can still use TRIM (not available in RAID0). I previously created a thread on this issue in which no clear consensus emerged.

 

[Brahmzy]

I don't know about consumer SSDs, but VMware and EMC's best practice guides both strongly recommend 8k ua sizes for W7 for VDI/View gold images. Those are some pretty big recommendations. They typically don't put stuff in their best practice guides unless it has been proven in labs and production environments. All of my W7 VM images are 8k.
Since this is all on Enterprise SAN storage, I have been less concerned about using it on my home boxes, but I've definitely thought about it. I'd be willing to experiment.
I wonder if its a significant enough change for a benchmarking tool to measure?

(not available in RAID0)

TRIM is available in RAID0. Yes, there are huge potential gains from RAID0.

 

[jolancer]

my ignorant 2c... cause havn't used'm and still learning the technical side of ssd's

my guess would be though, in all likely hood that software allocation size *within reason for all practical purposes is just as irrelevant for SSD's as it was for HDD's.... you still see people trying to align hdd's partitions accoding to the reported mfg reported /cylinders/heads/units/whatever etc, but in reality its a complete waist of time because the physical dimentions have no real translation into software optimization after all the data is jumbled through the bios and firmware. as long as they use a FS allocation size reasonable for there disks desired usage.

more of my assumption would be, that since random access time is what SSDs accel at, larger alocation to try and match whatever sector dimentions you think the SSD physically has would be moot. It may save space and lifespan though by keeping allocation size within reason of the hardware in question. 8k for a MBR HDD is just above normal, low for a GPT, but if 1k is realy the norm for a SSD, 8k im guessing would only be optimal for specialized circomstances if there is one all.

thm1223 - the brain works in mysterious ways... i see people doing things all the time that dont make any sense, yet they swear up and down about this or that makes such and such so much better, you gota try it etc etc. I say if you want SSD in Raid0, go for it. as others i think have already said tho you just need to use SSDs with native GC

 

[westrock2000]

I was in the process of moving my Intel G2 160 to serving music on my server and was surfing the web to see if there was any difference between block size. Since there was no direct evidence I decided to just try both ends and see what the benchmarks say.

There was really no discernable difference between 4K (4096) and 64K either at sequential or 4K random. This disc will only used for hosting MP3/MP4's so all the files will be megabytes in size and data throughput really doesn't matter, I'm only interested in the music being accessed instantly.

 

[groberts101]

Literally tens of thousands have played with these settings through the years now and as always..the main effect has more to do with amount of slack space/fragmentation/overhead created by varying allocation sizes and the typical/average size of the data stored. Also consider that the SSD controllers speed(processing power), sata controller/CPU processing power(especially critical for raids), and data size tested have everything to do with what positive result can be achieved by some systems. In theory, you could also affect the recovery/TRIM speed as the processor/firmware is likely tuned for a particular law of averages.

In my personal experience.. and the others I've seen so far(which go well into the hundreds by now), and beyond what looks good on paper, all we really do is move the PEAK speeds of the drive/array up or down the graph, is all. Although, I have seen some slight variances in latency which may prove more important for some workflows than few more MB's peak speeds at any given data size on a chart.

Each system is different and if you're into spending hours to find those last few MB/s?.. you just need to test, test, and retest to find the perfect balance. "Balance".. being the key word there as it'll never be perfect for all hardware and file usage. And.. if the drive will be used as an OS drive?.. testing it as an empty spare will only give you a blurry perspective for the bigger picture when the filesystem and OS are actually running from it.