[Roxor McOwnage]

If you have a SSD... with no moving parts... does that mean there's no speed penalty from having files fragmented in many different chunks? i.e. it's the same speed to read 10 chunks of data that are all "beside each other" (does that even make sense in solid-state drives?) as it is to read 10 chunks of data in random locations.

Think of all the work that has gone into drive logic to reorder IO to reduce seeks... all the work put into OS's to try to collect reads/writes into contiguous chunks... all the work done by filesystems to try to "do the right thing" to reduce fragmentation...

...is that all wasted effort if SSDs become popular?

(related question: does that mean I could fill a SSD to 100% full and it wouldn't get slower as it fills?)

Rox

[Bicster]

Fragmentation will still slow down an SSD, but it would be a lot harder to notice / measure. By way of example, it's faster to request one 64KB block of data than eight 8KB blocks. That said, I doubt I'd bother to defrag any SSD's I own.

[K15]

Defrag is already almost a thing of the past. With NTFS, it prevents horrible fragmentation most of the time anyhow. And if you leave your computer on long enough (like me, 24/7), then the disk never gets very fragmented since, as I understand it, windows does some tidying up when the computer sits idle for some amount of time.

But I'm sure with SSDs, even "bad" fragmentation wouldn't cause any major problems.

[imsabbel]

Bicster, on Apr 14 2007, 08:53 PM, said:

Fragmentation will still slow down an SSD, but it would be a lot harder to notice / measure. By way of example, it's faster to request one 64KB block of data than eight 8KB blocks. That said, I doubt I'd bother to defrag any SSD's I own.

Thats irrelevant, dont you think?
Where exactly should that delay take place?
A 64Kb request will be broken down into x*blocksize requests in the ssd controller, no matter in what form those are present on the medium.
The position of those x blocks is of no convern for the controlelr for reading purposes.
In fact, giving wear leveling algorithms, its a safe bet that your blocks are pseudo-randomly distributed in any case.

[bfg9000]

If the SSD is based on flash memory then defrag can help writing speed by keeping large contiguous blocks of open space available.

Flash is traditionally slow with writing because it is block-erased immediately before write operation. Having more contiguous open space available increases the odds that all the required space will already carry 1s or can be block-erased in one go, and that data bits will not need to be read then rewritten into a block.

[Roxor McOwnage]

I think imsabbel is right: there's no benefit to having contiguous blocks of data. Contiguous would really only mean the chunks of data are side-by-side logically in some address space... the bits themselves could be sprayed randomly all over a collection of flash chips and the speed would be the same.

[imsabbel]

bfg9000, on Apr 15 2007, 06:57 AM, said:

Flash is traditionally slow with writing because it is block-erased immediately before write operation. Having more contiguous open space available increases the odds that all the required space will already carry 1s or can be block-erased in one go, and that data bits will not need to be read then rewritten into a block.

Thats true, but consider:
Wear leveling will cause all this not to get exposed to the OS at all.
If you are writing block 00001 1000 times, it will always point to a different physical block.
If you overwrite block 0815, then the physical block the data was initally in might not be touched at all, as the wear leveling will point the write to another block.
"contiguous open space", as seen by the OS, and the filesystem, has no meaning on physical layer.

All this logic (distributing writes towards most suitable memory regions, regarding block health status, bursts, ect, will entirely be in the domain of the controller.

[TheR]

He, he. SSD is fragmented by default , since it's logic tries to spread writes trough the available space because flash cell can be written only about million times before it dies.

by

TheR

[HMTK]

Quote

Defrag is already almost a thing of the past. With NTFS, it prevents horrible fragmentation most of the time anyhow.

Really? Then why did I have four exceedingly slow machines last week with horribly fragmented disks that suddenly became usable again after a mere defrag? XP with NTFS and 50% or more free space.

[imsabbel]

HMTK, on Apr 16 2007, 06:27 AM, said:

Quote

Defrag is already almost a thing of the past. With NTFS, it prevents horrible fragmentation most of the time anyhow.

Really? Then why did I have four exceedingly slow machines last week with horribly fragmented disks that suddenly became usable again after a mere defrag? XP with NTFS and 50% or more free space.

Problem in front of the screen?