Solid State Disks (SSD's) - Worth defragging ?

[theshepherds]

SSD's are now appearing in the desktop/laptop market and the price/performance is quite appealing. On studying these I see little benefit from defragging them unless otherwise corrected, in terms of  noticeable performance gains from coalescing/defragmenting and optimizing. However, my system gets very sluggish when accessing heavily fragmented drives and I seem to notice a correllation between high/excessive numbers of fragments (20K plus, Blame the App, they might all be contigous , but they are still fragments...) It seems than an excessively populated MFT has extra resource requirements in the System pools and extra overhead on the NTFS MFT reads.  Will SSD's with high number of fragments benefit from fragmenting in terms of file system performance and system overhead reduction , in fact, does defragmentation in general reduce system overhead over and above the NTFS recursive behaviour ? i.e. again, are there noticeable performance tuning areas such as PAGE/NON PAGED POOL allocations, mftmirrorzone settings via fsutil , or registry settings for NTFS etc etc...

A general broad question I know, but I am sure there is benefit to be had from soft tuning as well as hard defragging, if so, they will go well with JKD and IO tuning in general. HAs anyone done any research into the soft side of IO tuning that will aid JKD , either in runtime performance or post defragmentation filesystem performance ? My music folder is chokka ,  and I fear metadata operations are sluggish beyond what JKD can fix.

[jeroen]

Users have reported that JkDefrag makes solid state disks (memory sticks and such) faster. The benefit seems to come mainly from defragmentation (making files contiguous) and not so much from optimization (moving all the files together at the beginning of the disk).

[Esprit]

SSD's have much faster access time than HDD's but still some remains. You can notice slower reading when files has fragments smaller than hundreds of kB. Total number of fragments does not play a big role in reading speed. The position of a file on SSD doesn't affect reading speed at all, which is great difference against HDD's so I recommend using only defragmentation (-a 2).

[WHRoeder]

I recommend using only defragmentation (-a 2).

As it fills you'll get more and more frags and eventually wont be able to defrag.  A fast packing (-a3) wont take much longer and will prevent frags until almost full.

[poutnik]

Current Flash NAND technology writes and reads blocks of memory. ( well, erasure on blocks and writes on pages )
If fragment sizes are comparable to block/pages sizes, actual amount of data to be read / write / erased increases.

see wikipedia

Another thing is excessive writes stresses flash memory.
I would recommend just defragmentation ( -a 2 ) or fast one ( -a 3 -f 0 -u "Disabledefaults" ).
IMHO  keeping extra zone for spacehogs does not make sense on flashes and would cause extra moving.
So I would avoid zone gaps for similar reasons.

further more, SSD based on flash technology always use at least internal memory controller
to manage memory wear leveling and dealing with corrupted blocks.
Some systems use internally even specialized flash file systems. 

So, reported and real position of file can be very different.

[nsalta]

Since the position on the Drive is irrelevant I agree with the previous posts, disable spacehogs and just use -a 3.

[SledgeHammer]

[...] wear-levelling-controller integrated in ssd [...]
So, reported and real position of file can be very different.

I agree with that. As a result, all defrag and optimization done by the OS will be wasted ressources.

[jeroen]

By the way, JkDefrag by default will not process removable volumes. Only fixed volumes. Solid state disk are usually removable disks (such as memory sticks), but it depends on the driver of the solid state disk. Removable disks can be processed by JkDefrag by explicitly specifying their name on the JkDefrag commandline.

[cquinn]

I think the SSD's that theshepherds was referring to are the ones manufacturered with an IDE or SATA controller, and are designed to appear as a standard drive to the system and OS.

I just ran an analysis phase defrag on a thumbdrive that I use fairly regularly; and show little relative fragmentation on that drive.    14 files that have 2 to 3 fragments each, and the 25 largest files show no fragmentation at all.

[poutnik]

I think the SSD's that theshepherds was referring to are the ones manufacturered with an IDE or SATA controller, and are designed to appear as a standard drive to the system and OS.

It is expected from them, pretending to be normal disk.

E.g. well known compact flash memory card has de facto IDE interface, only geometry is smaller.
There exist reductions for it and you can use CF as IDE solid state drive.

But internally they perform many relocations, progressing in time by memory controller decisions.
E.g. If one uses ony 1/3 of total capacity, and performing many rewrites,
files are written in the all area of the disk, differently during time.
As result all blocks have similar write/erase counts history, what is the purpose.

Relocation applies especially for File allocation tables.
Small, byte or even bit scope writes cause need of frequent block erasure.

Any external utility has no idea, how files are really placed.