Sign in with
Sign up | Sign in
Your question

Question about SSD file saves using NTFS file structure (2)

Last response: in Storage
Share
December 29, 2009 3:34:31 PM

SSD Refresher: Per Anandtech "ssd anthology mar 18 2009",

single SSD cells contain either 1 or 2 bits; groups of cells form 4kb pages and 32 pages form 128kb blocks.

the SSD reads from and writes to 4kb pages, but the SSD can only erase a 128kb block - It can not erase single pages - It must erase 32 pages at one time. So, erasing a 4kb file is far less efficient than writing a 4kb file --

To erase a 4kb file (1 page), the ssd must move the entire 128kb block to which the 4kb page belongs, then the ssd invalidates the 4kb page, then writes the block back (without the 4kb invalidated file page) to its original 128kb block space without including the 4kb file (page) that you inend to erase.

This is why SSD write times are much slower than SSD read times.

Here is my Question - What happens when using an 8kb NTFS file system with SSD's, instead of a 4kb NTFS file system? Does the SSD use two pages (2 x 4kb) to write one NTFS 8kb file? How about a 16kb NTFS file system, e.g. does the SSD use 4 pages (4 x 4kb) to write one 16kb NTFS file?

Thanks for your input.

Jeff
Michigan
December 30, 2009 3:13:52 PM

Hi Jeff!

Pages size certainly vary from one model to another, and write blocks must be smaller on Slc, so just keep the general idea from Anandtech.

Then, cluster size is NOT the amount of data read nor written each time. It's the area unit the file system won't split. The OS will read and write data smaller and bigger than one cluster in a single command.

Also, what makes recent SSD better is that they have Ram onboard (like 64MB) and a good controller that, combined with wear levelling, will wait to have enough written data in the Ram to write a complete block (regardless of sector positions the OS told).

Both tell that cluster size won't change write size. And as bigger clusters have only drawbacks with Ntfs, I stick to the standard 4kB size.

What you can try is DisableNtfsLastAccessUpdate. Ntfs writes in every directory each time it has read from it, which is not desireable for Flash; DisableEtc improves this behaviour. Try to compare after fresh boot the search of a file name in a huge directory.

As well, aligning the volume's beginning (and hopefully the clusters then) is said to improve SSD operation provably.
https://kb.wisc.edu/images/group14/4556/diskpar.exe
http://support.microsoft.com/?scid=kb%3Ben-us%3B927229&...
and I believe GPartEd does it at least as well:
http://gparted.sourceforge.net/livecd.php
this should improve Raid-0 operations also, but I've never read about it.

At least on Compact Flash, defragmenting improved speed a lot, so I still use it.

Prefetch is always very useful, with SSD as well, keep it.

No opinion about Superfetch.
December 30, 2009 5:24:08 PM

Pointertovoid said:
Hi Jeff!

Pages size certainly vary from one model to another, and write blocks must be smaller on Slc, so just keep the general idea from Anandtech.

Then, cluster size is NOT the amount of data read nor written each time. It's the area unit the file system won't split. The OS will read and write data smaller and bigger than one cluster in a single command.

Also, what makes recent SSD better is that they have Ram onboard (like 64MB) and a good controller that, combined with wear levelling, will wait to have enough written data in the Ram to write a complete block (regardless of sector positions the OS told).

Both tell that cluster size won't change write size. And as bigger clusters have only drawbacks with Ntfs, I stick to the standard 4kB size.

What you can try is DisableNtfsLastAccessUpdate. Ntfs writes in every directory each time it has read from it, which is not desireable for Flash; DisableEtc improves this behaviour. Try to compare after fresh boot the search of a file name in a huge directory.

As well, aligning the volume's beginning (and hopefully the clusters then) is said to improve SSD operation provably.
https://kb.wisc.edu/images/group14/4556/diskpar.exe
http://support.microsoft.com/?scid=kb%3Ben-us%3B927229&...
and I believe GPartEd does it at least as well:
http://gparted.sourceforge.net/livecd.php
this should improve Raid-0 operations also, but I've never read about it.

At least on Compact Flash, defragmenting improved speed a lot, so I still use it.

Prefetch is always very useful, with SSD as well, keep it.

No opinion about Superfetch.


Thank you so much for the feedback - it really helps..just ordered my first ssd - going to play around with it to get a better understanding of how it works before going into raid (also easier on cashflow!)... will look up everything you've recommended to understand exactly what you are saying, but in general, you certainly have redirected my thoughts about how ssd handles write function...thanks again...


January 27, 2010 12:36:45 AM

Before you invest much money in a Raid of Ssd, you may want to make the same trial as I did...

I measured the boot time (end of Bios to responsive menu key) at different Cpu frequencies. With my X25-E (very impressive, probably overkill) and E8600 @4GHz, any change in Cpu speed reflected 1 to 1 in boot time.

From which I deduced that the Ssd awaits the Cpu here, and improving the Ssd would be useless. It may well be the same with other Ssd.
!