Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

All Solid State Drives Suffer Performance Drop-off

CmdrTaco posted more than 5 years ago | from the storage-slows-down-as-you-approach-5pm dept.

Data Storage 150

Lucas123 writes "The recent revelation that Intel's consumer X25-M solid state drive had a firmware bug that drastically affected its performance led Computerworld to question whether all SSDs can suffer performance degradation due to fragmentation issues. It seems vendors are well aware that the specifications they list on drive packaging represent burst speeds when only sequential writes are being recorded, but after use performance drops markedly over time. The drives with better controllers tend to level out, but others appear to be able to suffer performance problems. Still not fully baked are benchmarking standards that are expected out later this year from several industry organizations that will eventually compel manufacturers to list actual performance with regard to sequential and random reads and writes as well as the drive's expected lifespan under typical conditions."

cancel ×

150 comments

Sorry! There are no comments related to the filter you selected.

All? (1, Funny)

Anonymous Coward | more than 5 years ago | (#27882677)

How can that be? They tested every drive in existence?

Re:All? (2, Funny)

gbarules2999 (1440265) | more than 5 years ago | (#27882697)

Looks like it. they're all borked. Every single one of them. I said so in the title, and I only bother reading the title in Slashdot stories these days.

Re:All? (3, Insightful)

gbarules2999 (1440265) | more than 5 years ago | (#27882711)

Not, "I said," "it said." Damn my incompetence!

Re:All? (2, Informative)

Anonymous Coward | more than 5 years ago | (#27882875)

Can a fail be insightful?

Re:All? (0)

Anonymous Coward | more than 5 years ago | (#27882985)

Can a fail be insightful?

When the mods are smoking crack cocaine, yes. Yes it can. Well, it can't be insightful. It can be "insightful". In their minds only. Stupid mods.

Re:All? (5, Funny)

neovoxx (818095) | more than 5 years ago | (#27883185)

Insightfail?

Re:All? (1)

Velox_SwiftFox (57902) | more than 5 years ago | (#27883743)

It can be a revelation.

It was when one happened to me, on one of the two "3 million hour MTBF" SSD drives I purchased approximately a month before.

Re:All? (1)

EveLibertine (847955) | more than 5 years ago | (#27884277)

I wouldn't think so, but perhaps the mods are recognizing the necessity of insightful introspection in order to recognize one's own incompetence.

Re:All? (5, Funny)

johny42 (1087173) | more than 5 years ago | (#27883203)

This must be the first time a comment correcting a previous comment got modded higher than the original comment. Let's see how this comment, which comments on the fact that a comment correcting a previous comment got modded higher than the original comment, fares.

Re:All? (1)

icannotthinkofaname (1480543) | more than 5 years ago | (#27884371)

This...this is commenting on a comment....

Is that a meta-comment?

Re:All? (1, Funny)

Anonymous Coward | more than 5 years ago | (#27883063)

Bork? Bork? Bork?

Not *ALL* (2, Informative)

Plekto (1018050) | more than 5 years ago | (#27883841)

Looks like it. they're all borked. Every single one of them. I said so in the title, and I only bother reading the title in Slashdot stories these days.

http://4onlineshop.stores.yahoo.net/an5insax1ram.html [yahoo.net]
The ANS9010 and 9010B suffer no such issues since they are ram-based. They also have a CF backup slot in addition to a backup battery. Very slick and a better solution for a boot drive than a typical SSD if you absolutely must have maximum speed. Pricing with RAM is comparable to an enterprise-level SSD, just roughly 1/2 to 1/4 the capacity is all.

To test (5, Interesting)

Fri13 (963421) | more than 5 years ago | (#27882681)

Just place SSD drives to usenet or torrent servers and use them as /var/log mountpoints... you soon see real tests how well those work when comparing to old fashion harddrives!

Re:To test (1, Informative)

Anonymous Coward | more than 5 years ago | (#27883837)

Uh, not really. You need to test real usage conditions. The most common hard-drive (ab)using applications are going to be databases, development (edit, save, compile, rebuild; uses lots of disk access), and work-horse applications like VMware, Photoshop, Video editing software, 3D rendering, etc.

Especially things like SQLite which really tends to hammer the drives and is embedded in lots of applications.

I have some experience with SSD's on development machines and database servers. I speak from experience when I say they are much less reliable than the old spinning hard-drives when used in those environments. In fact, I have never seen a single one last more than a year.

Re:To test (1, Interesting)

AHuxley (892839) | more than 5 years ago | (#27884019)

I would pack a drive to about 8% of 'full'
Fill it with applications, OS (Mac, Win, Linux over 3 drives) , mps3, lots of jpegs, text files and short and long movie files (2~50~650 mb)
Get the RAM down to 1-2 gb and let the OS's thrash as they page in/out and watch the 3 computers over a few weeks.
Automate some HD intensive tasks on the small amount of space left, let then run 24/7.
Hope that Mac or Linux will keep files in different ways and use the little space in strange ways too. We can hope OS X and the lack of large contiguous chunks of free space will stress the OS and SSD in fun ways.
Windows will do what is expected.
Then run the HD 'tests' again.
Something should show up on a graph via the 3 different OS.

Just a small dip in performance (5, Informative)

Bellegante (1519683) | more than 5 years ago | (#27882685)

Even the article itself says that it isn't much of a big deal, once you get past the headline, of course.

And this seems like the sort of issue that will be resolved in the next generation, anyway.

Re:Just a small dip in performance (0)

Geoffrey.landis (926948) | more than 5 years ago | (#27882925)

At least like you should be able to reverse the problem by wiping the SSD and starting over. (essentially, de-fragmenting it by a wipe and reload)

Re:Just a small dip in performance (3, Funny)

postbigbang (761081) | more than 5 years ago | (#27882953)

Yeah, that's a great solution. Wipe a nice fat drive array, then start over. Right. Wipe it. Got it.

Re:Just a small dip in performance (1, Redundant)

davester666 (731373) | more than 5 years ago | (#27883035)

Hey, it's in a RAID array, you can just do one at a time by removing it, wiping it, then reattach it and rebuild the disk. Then do the next one.

If it's RAID 5, you can even keep using the array!

Re:Just a small dip in performance (1)

billcopc (196330) | more than 5 years ago | (#27883621)

Hold out your hands, you just won a dozen internets!

Re:Just a small dip in performance (0)

tzot (834456) | more than 5 years ago | (#27883685)

The parent post is not funny. Hear me, mods?

Re:Just a small dip in performance (0)

TheRaven64 (641858) | more than 5 years ago | (#27883719)

Yes it is. RAID sits below the filesystem, and so removing one drive, blanking it, and reinserting it will still give you a fragmented drive. If you are using ZFS/RAID-Z, or some other filesystem-layer replication then this approach will work, but with RAID it's a joke.

Re:Just a small dip in performance (4, Informative)

LordKronos (470910) | more than 5 years ago | (#27883959)

Yeah, but the SSD wear leveling sits at a level below RAID. When you write to a specific area of the SSD, the wear leveling can remap that to whereever it needs.

Re:Just a small dip in performance (-1, Offtopic)

Shikaku (1129753) | more than 5 years ago | (#27883053)

Or don't use NTFS or any kind of FAT volume.

Most Linux filesystems do not have a serious fragmentation problem, but NTFS and FAT[x] do.

citation: http://en.wikipedia.org/wiki/Ext3#Defragmentation [wikipedia.org]

That being said, as the Linux System Administrator Guide states, "Modern Linux filesystem(s) keep fragmentation at a minimum by keeping all blocks in a file close together, even if they can't be stored in consecutive sectors. Some filesystems, like ext3, effectively allocate the free block that is nearest to other blocks in a file. Therefore it is not necessary to worry about fragmentation in a Linux system."

Re:Just a small dip in performance (4, Informative)

hardburn (141468) | more than 5 years ago | (#27883171)

Totally different issue. The problem here is inherent in all flash drives, but can be mitigated by clever controller design. AnandTech made an extensive report on this issue [anandtech.com] .

Re:Just a small dip in performance (5, Informative)

AllynM (600515) | more than 5 years ago | (#27883769)

All flash drives *do not* have the issue. What really happens is your small write IOPS will be on the low side and your sequential writes will always be full speed *unless* you implement some form of write combining. The write combining cheats a bit by taking small random writes and writing them in a more sequential fashion to the flash itself.

The catch is that when you come past that now fragmented area, the controller has to play musical chairs with the data while trying to service the write originally requested by the OS. End result - slower write speed.

Some well behaved controllers (Intel, Samsung) will take a little extra time to defragment the block while it's servicing the sequential write. Optimized controllers (Intel M series) will now rarely fall below their advertised write speed of 80 MB/sec.

Other more immature controllers leave the data fragmented and simply move the whole block elsewhere. This results in a compounded fragmentation, which can eventually drop write speed to 1/3 to 1/5 of it's write speed when new.

I authored the original articles on the matter:
http://www.pcper.com/article.php?aid=669 [pcper.com]
http://www.pcper.com/article.php?aid=691 [pcper.com]

Allyn Malventano
Storage Editor, PC Perspective

Re:Just a small dip in performance (1)

atamido (1020905) | more than 5 years ago | (#27886565)

I've been curious if this is an issue when using a RAW flash device and a modern file system designed for flash. Would you get any better performance and simplicity by moving the wear leveling and write combining up to the OS level?

Re:Just a small dip in performance (2, Funny)

myxiplx (906307) | more than 5 years ago | (#27886577)

Authoritative comments, on Slashdot? Are you sure you're on the right site?

Re:Just a small dip in performance (1)

electrostatic (1185487) | more than 5 years ago | (#27885597)

Thank you for this pointer to a superb analysis. My interest comes from having ordered a Lenovo W500 with an 128BG SSD a few days ago. This 31 page review is smart, extensive, pertinent and tells a compelling story of SSD controller design issues. The amount of testing that went into it is more than impressive.

SSD random read/write performance issues requires an altogether different way of thinking about writes. Whereas, say, a rewrite of a 4K document can be done back into the same location of a hard drive, it cannot with an SSD. The write must be to an unused area (that has previously been erased). This is complicated by the fact that writes are done in units of 4K pages, while erases are done in units of 512K blocks (128 pages). After a while, and even if the drive is only partially full, every block has accumulated many "deleted" pages that cannot be written to until an erase operation. An erase requires that the 512K block be copied to a cache, the block erased (all bits reset), and the cache copied back into the block. If the controller fails to manage this well then random R/W operation can produce "stutters:" 500-1000ms delays where the system freezes.

The notion of defragmenting a drive does not apply to an SSD. First there is no mechanical delay in SSD, so read performance cannot be improved by making files continuous. Further, the OS has no knowledge as to the actual page location where a piece of data has been written. Only the controller has that information.

But there is the possibility of an OS "Trim" operation where it can instruct the controller to perform the multi-step reset operation outlined above. This could be done when the OS or user decides the SSD needs it and is not busy. The effect is to make deleted blocks available for writes before they're needed. IOW, instead of having to force numerous refreshes of 512K blocks in order to obtain space for a series of 4K blocks, do it soon after the delete --- when there's slack time -- rather than before the write when there's not. But the OS has to be involved. He says Windows 7 promises to support Trim in conjunction with a to-be-established controller standard.

Re:Just a small dip in performance (2, Insightful)

Anonymous Coward | more than 5 years ago | (#27883497)

Some filesystems, like ext3, effectively allocate the free block that is nearest to other blocks in a file. Therefore it is not necessary to worry about fragmentation in a Linux system."

Right, the answer to every Linux problem. Redefine the unavoidable to "not a problem" while the other guy "has it" and "it is bad".

Re:Just a small dip in performance (4, Informative)

Anpheus (908711) | more than 5 years ago | (#27883779)

To elaborate on the issue, think about how regular disks have sectors that tend to be around 512 bytes. This expectation is "baked" into a lot of filesystems, because of how ubiquitous it is.

This has to do with fragmentation of device sectors when those sectors don't conform to filesystem expectations. That is, the filesystem writes out a 512 byte sector, but the flash drive can only commit 128kb slices at a time. Each of those slices contains 256 sectors. That's not a good situation, because if the filesystem or the controller attempting to correct for the filesystem's writes handles the situation poorly, then that 128kb slice soon becomes fragmented. The fragmentation within that block causes your problems. The problem is when contiguous 512-byte sectors can no longer be allocated contiguously in the 128kb slices. Say you have a few sectors there, a few there, a larger chunk there, maybe even a whole 128kb slice that all corresponds to a single linear mapping of filesystem sectors.

All filesystems that write out blocks smaller than 128kb have this problem. Or whatever the size is the flash drive uses. The problem is twofold: filesystems were written with hard disk drive specifications expected, and those specifications were allowed to become so ubiquitous and the momentum behind them so great that writing for a different set of hardware becomes more difficult. And the second problem is that because of the inertia in expecting every SATA device to be a hard disk, that both filesystem driver and hardware manufacturers have come to expect, there is no "alternative" addressing or better or dynamic method of accessing a disk.

Everything, to the filesystem, is a spinning disk. If you made a disk that actually had 128kb sectors, you would probably encounter the same problem these flash drives have. The stupid realization now, a decade or more on from when many of these standards were drafted, is that these standards permitted very little, if any, deviation. All SATA disk devices are written with the expectation that they are spinning media. All SATA disk devices and the filesystem and the OS have expected this, and certain particular numerical definitions for things like sectors for so long, that no one ever thought to write a standard that would allow filesystem writers to create a filesystem that reasonably deals with new devices.

And because the SATA layer is so simplified and dumbed down for spinning media, there's no way in the SATA communication channel to manually defragment a sector. Apparently SATA/SAS are so set in stone, so stubborn that Intel and every other SSD manufacturers has to emulate a spinning media device, and there's no other good way to do it.

Literally, the filesystem cannot fix this problem, the OS cannot fix this problem. Because at that level of operation, the disk is seen as another dumb spinning disk with 512 byte sectors. You can't actually "see" where those sectors are located or attempt to defragment them from that level. The only way to do it is to issue a SATA command that wipes the entire drive, which allows the controller to flush its internal sector mapping.

Re:Just a small dip in performance (3, Interesting)

dgatwood (11270) | more than 5 years ago | (#27884491)

Come again? I'm not aware of SSDs doing any mapping at that level of granularity; to do so would mean that a 256 GB hard drive would require something like 2 GB of storage (assuming an even 32-bit LBA) just to hold the sector mapping table, and that would have to be NOR flash or single-level NAND flash, making it really freakishly expensive.

All SSDs that I'm aware of work like this: you have a logical block address (sector number). These are grouped (contiguously) into pages (those 128KB "slices" you're referred to). If you have a 128 MB page size, then sectors 0-255 would be logical page 0, sectors 1-511 are logical page 1, and so on.

These logical pages are then arbitrarily mapped to physical pages. This results in a mapping table that is a much more plausible 8 megabytes in size for a 256 GB flash drive.

Thus, any fragmentation within a flash page is caused entirely by the filesystem being fragmented, not by anything happening in the flash controller. The performance degradation from full flash has nothing to do with fragmentation. It is caused by the flash controller having to erase an already-used page before it writes to it. The only way to avoid that is to erase unmapped spare pages ahead of time.

Re:Just a small dip in performance (4, Insightful)

AllynM (600515) | more than 5 years ago | (#27884283)

Grandparent, and the whole chain, are *way* off base here. SSD LBA remap table fragmentation has absolutely nothing to do with file system fragmentation. ext3 will cause just as much of a slowdown as NTFS would. I share the same appreciation for Linux as everyone else around here, but in this case it is in no way the magic bullet we might like it to be.

Allyn Malventano
Storage Editor, PC Perspective

Re:Just a small dip in performance (4, Funny)

NotBorg (829820) | more than 5 years ago | (#27883477)

At least like you should be able to reverse the problem by wiping the SSD and starting over.

So this is a non issue for Windows users?

First generation SSD immaturity... (1, Interesting)

blahplusplus (757119) | more than 5 years ago | (#27882745)

... these things aren't going to be a big deal in the long run, I mean who wasn't expecting some amount of technological immaturity? We shouldn't forget though that even with it's immaturity it's still much faster then hard disk drives but the SATA interface controller was not designed to handle such high speeds, not to mention much software is not geared, nor optimized for SSD usage.

Still price has come down considerably on many SSD's over the last 6 months, I was thinking about picking up an X-25 M for a mere $350 bucks, would be worth it (to me) just to reduce load times in games like Empire total war IMHO.

Re:First generation SSD immaturity... (1)

644bd346996 (1012333) | more than 5 years ago | (#27883001)

This has nothing to do with technological immaturity or firmware bugs. It's simply a matter of SSDs using an optimization that hard drives can't due to their non-trivial seek times, and people are starting to realize that that optimization doesn't always work.

Re:First generation SSD immaturity... (1)

blahplusplus (757119) | more than 5 years ago | (#27883081)

"This has nothing to do with technological immaturity or firmware bugs. It's simply a matter of SSDs using an optimization that hard drives can't due to their non-trivial seek times, and people are starting to realize that that optimization doesn't always work."

Actually it does, you should check out ANAND's article here:

http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 [anandtech.com]

There definitely IS some immaturity (broadly speaking) if you go through the entire article about how other SSD's were designed and their particular problems.

Not a bug. (1, Informative)

ddrueding80 (1091191) | more than 5 years ago | (#27882757)

This isn't a bug, it is a property of flash memory. That is like calling a car that eventually runs out of gas poorly designed. The only way around it would be a new type of "defrag" where unused blocks were cleared in advance and partially used blocks consolidated.

Re:Not a bug. (0)

stonecypher (118140) | more than 5 years ago | (#27883279)

The clearing blocks in advance is called TRIM, and your computer already supports it, as does Windows 7. As far as defrag, that's completely unnecessary; the article and poster are incorrect, as fragmentation has nothing to do with the problem. Flash drives have zero seek and no performance penalty for random access.

Re:Not a bug. (1)

tzot (834456) | more than 5 years ago | (#27883717)

You keep using that word: "fragmentation". I don't think you know what it means in the SSD context.

Re:Not a bug. (1, Informative)

LordKronos (470910) | more than 5 years ago | (#27883967)

Actually, SSDs don't currently support TRIM. The last I read, the manufacturers can't agree on a common way to do it (there are 2 competing ideas about how to implement it). They are actually trying to do the right thing by working out their differences and implementing it all the same, rather than both doing their own thing. Until they come to an agreement, they can't release any firmware supporting TRIM. For the same reason, Windows 7 doesn't support TRIM either, and it is supposed to be shipping without TRIM support. That support is supposed to come shortly after Win7 is released.

Re:Not a bug. (4, Informative)

Mr.Intel (165870) | more than 5 years ago | (#27884991)

Actually, my SSD [newegg.com] (firmware 1.10 [ocztechnologyforum.com] ) supports TRIM [ocztechnologyforum.com] and I've used it with good results. OCZ is one of the two companies mentioned that is working on a TRIM solution, but you should also know, that Windows 7 definitely [msdn.com] supports TRIM. Google is your friend.

Re:Not a bug. (0, Redundant)

Rockoon (1252108) | more than 5 years ago | (#27885111)

Actualy to be quite specific.. there is a simple solution and that is to decrease the size of flash blocks to something more sane so that a flash block size is also a reasonable logical sector size like something in the 512 to 4096 byte range

No, this solution isnt "feasable" yet, due to cost.. but eventualy either another solution will be developed, or this one will be implemented.

HMMMMMMM (1)

captnbmoore (911895) | more than 5 years ago | (#27882777)

Think I'll stick with the tried and true IDE/SATA tech.

Re:HMMMMMMM (4, Informative)

Mad Merlin (837387) | more than 5 years ago | (#27882819)

Think I'll stick with the tried and true IDE/SATA tech.

Psst: SSD drives connect via SATA.

Re:HMMMMMMM (2, Insightful)

TooMuchToDo (882796) | more than 5 years ago | (#27882945)

They actually have PCI-E versions as well, to bypass the SATA bottleneck.

Re:HMMMMMMM (0)

Endo13 (1000782) | more than 5 years ago | (#27882915)

Think I'll stick with the tried and true magnetized platter tech.

FTFY.

Re:HMMMMMMM (1)

rob1980 (941751) | more than 5 years ago | (#27886241)

A good SSD will whoop many high-end platter drives even after the one-time speed decrease. Anandtech went over this a few months back. The reasons you should stick with platters is because they're cheaper per gigabyte, not because they're "tried and true". (I don't even really know about the "true" part, after all hard drives are the first thing that'll take a shit on most computers anyway.)

"Drastically affected its performance" (5, Informative)

Cowclops (630818) | more than 5 years ago | (#27882783)

"Drastically effected its performance"

This is patently false. Whats really happening is that SUSTAINED WRITE PERFORMANCE decreases by about 20% on a full drive as compared to a fresh drive. You might say 20% is too much, and I'd probably agree with you, except that ONLY sustained write performance is being affected.

Your read speed will not decrease. Your read latency will not increase. Unless you're using your SSDs as the temp drive for a high definition video operation (And why the hell would you for that? Platter drives are far better suited to that task between sequential write speed and total storage space) then you have nothing to worry about.

This happens on all drives, as the article title correctly states. The solution is a new write command that pre-erases blocks as you use them, so the odds that you have to erase-then-write as you go along are decreased. Win7 knows how to do this.

Nonetheless, it is totally overblown and your SSD will perform better than any platter based drive even when totally full.

Re:"Drastically affected its performance" (1)

Kjella (173770) | more than 5 years ago | (#27883333)

Unless you're using your SSDs as the temp drive for a high definition video operation (And why the hell would you for that? Platter drives are far better suited to that task between sequential write speed and total storage space)

Not if you use torrents, they're very much non-sequential as it's downloading tons of pieces all over the file. When I had a regular HDD as OS disk it was big so I'd download torrents to it - always slowed the machine down, was better to use a different disk but leaving hundreds of GBs unused didn't seem to make sense either. With an SSD you hardly notice the torrents running, I usually download to SSD, watch it then move it to file server. Everyone should get an SSD really, it's the greatest revolution since dualcore. Perhaps even bigger, everything's so smooth.

Re:"Drastically affected its performance" (5, Informative)

AllynM (600515) | more than 5 years ago | (#27883799)

20% is too little. I've seen drives, even SLC drives, drop by more than 50%. Only some drives bounce back properly. Others rely on TRIM to clean up their fragmentation mess.

A more important note is that some initial TRIM implementations have been poorly implemented, resulting in severe data corruption and loss:
http://www.ocztechnologyforum.com/forum/showthread.php?t=54770 [ocztechnologyforum.com]

I posted elsewhere regarding the fragmentation issue here:
http://hardware.slashdot.org/comments.pl?sid=1227271&cid=27883769 [slashdot.org]

Allyn Malventano
Storage Editor, PC Perspective

good article on the reasons behind this (4, Informative)

LodCrappo (705968) | more than 5 years ago | (#27882795)

http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=4 [anandtech.com]

Anandtech has a very detailed article that explains all about this and some ways to recover the lost speed (sometimes).

Re:good article on the reasons behind this (-1, Redundant)

Leafheart (1120885) | more than 5 years ago | (#27882855)

And it already hit slashdot. I was about to post this link.

Wait just a minute... (4, Funny)

rascher (1069376) | more than 5 years ago | (#27882817)

...you mean to tell me that fragmentation *reduces* the performance of storage???

Re:Wait just a minute... (4, Informative)

Tx (96709) | more than 5 years ago | (#27882997)

...you mean to tell me that fragmentation *reduces* the performance of storage???

Fragmentation on hard disks reduces performance because of the time it takes to physically move the disk heads around. There are no physical heads to be moved around in SSDs, therefore it's perfectly reasonable to assume that that mechanism of performance hit will not occur on SSDs, and therefore it's not an issue. I did a small test [googlepages.com] years ago on the effects of flash memory fragmentation in a PDA, and I, and most people I discussed the matter with seemed to be quite surprised with the results at the time. I never got a good technical explanation of why the performance hit was so large. Doubt that's the same mechanism at work as with modern SSDs, but sort of relevant anyway.

Re:Wait just a minute... (4, Informative)

beelsebob (529313) | more than 5 years ago | (#27883105)

The reason the performance hit is large is because writing to SSDs is done in blocks. Fragmentation causes part-blocks to be used. When this happens, the SSD must read the block, combine the already-present data with the data it's writing and write the block back, rather than just overwriting the block. That's slow.

Re:Wait just a minute... (0)

tzot (834456) | more than 5 years ago | (#27884005)

The reason the performance hit is large is because erasing SSDs is done in blocks.

There, fixed it for ya.

Re:Wait just a minute... (1)

Jane Q. Public (1010737) | more than 5 years ago | (#27884967)

Your explanation of the cause of the slowdown is correct, but it has very little if anything to do with fragmentation. They are two separate issues. If anything in the block needs to be re-written, regardless of whether it is contiguous or not, then the whole block will be re-written. There is no getting around it.

Since the memory controllers in SSDs deliberately distribute your data across the flash memory, "fragmentation" in its usual sense is pretty meaningless.

Re:Wait just a minute... (1)

AHuxley (892839) | more than 5 years ago | (#27885527)

Memory controllers cost real cash to write for Windows, Linux and Macs.
A real skill needing real support. The cheaper units are in a race to the bottom with what ever they can buy off the shelve.
Other firms try to spread high end from pro desktop users.
If you want a memory controller that works, you will pay.
No brand is ready to upset that mix at this time.
Old stock to sell before they can hire professionals at the low end.
At the top end, why end a good thing?

Re:Wait just a minute... (0)

Anonymous Coward | more than 5 years ago | (#27883003)

Read the bloody anandtech article posted above...

My X301 still runs fast (2, Interesting)

bzzfzz (1542813) | more than 5 years ago | (#27882897)

I purchased a Lenovo X301 with a 120 GB flash drive last September and have been nothing but pleased with the performance of the drive. I boot Vista and also run openSUSE in a vm. The drive speed is high and consistent. The drive in the X301 is supposed to have better controllers than some, and it certainly does better than a USB stick. Any theoretical problems with write speed don't appear to me to affect typical real world use.

My PATRIOT ssd still runs fast (1)

Anna Merikin (529843) | more than 5 years ago | (#27883839)

I've used it as a desktop drive for four months so far, and, using hdparm -T as a benchmark (I know, I know, but it's on a desktop!) it has the same throughput as it ever did. I download torrents to it.

It would copy completed torrents to a platter-drive at 60MB/sec when new and will still do 60MB/sec now.

I don't see a problem. Opera/Firefox open in less that one second (by wristwatch!) instead of ten on a platter-drive (Pentium-M, 1.6 GHz). The whole computer seems more responsive -- even modern in terms of speed.

Thumbs up on SSDs! My Patriot drive was on sale at Fry's for about $70 US (32GB). Best upgrade I ever made; I boot from it (less than 20 seconds on Ubuntu 9.04) but use a platter drive for /home and swap.

Re:My PATRIOT ssd still runs fast (0)

Anonymous Coward | more than 5 years ago | (#27886649)

I've used it as a desktop drive for four months so far, and, using hdparm -T as a benchmark (I know, I know, but it's on a desktop!) it has the same throughput as it ever did.

You are aware that hdparm -T is a read test, right? And the performance drop off being discussed is for writes?

Just use an intellgent defragger (5, Funny)

Anonymous Coward | more than 5 years ago | (#27882927)

One that can relocate MFTs, most used files and swap to the chips on the outer edge of the circuit board, where the throughput is faster.

Re:Just use an intellgent defragger (1)

radeon21 (1183313) | more than 5 years ago | (#27883041)

Faster throughput?

Re:Just use an intellgent defragger (2, Funny)

TheRaven64 (641858) | more than 5 years ago | (#27883739)

This technique requires you to spin your flash chips very fast, which is a feature only supported on enterprise-grade SSDs.

NAND is the culprit (5, Informative)

thewesterly (953211) | more than 5 years ago | (#27882941)

The fundamental problem with NAND-based solid-state drives is that they use NAND flash memory--the same stuff that you find in USB flash drives, media cards, etc.

The advantages of NAND is that NAND is both ubiquitous and cheap. There are scads of vendors who already make flash-memory products, and all they need to do to make SSDs are to slap together a PCB with some NAND chips, a SATA 3Gb/s interface, a controller (usually incorporating some sort of wear-leveling algorithm) and a bit of cache.

The disadvantages of NAND include limited read/write cycles (typically ~10K for multi-level cell drives) and the fact that writing new data to a block involves copying the whole block to cache, erasing it, modifying it in cache, and rewriting it.

This isn't a problem if you're writing to blank sectors. But if you're writing, say, 4KB of data to a 512KB block that previously contained part of a larger file, you have to copy the whole 512KB block to cache, edit it to include the 4KB of data, erase the block, and rewrite it from cache. Multiply this by a large sequence of random writes, and of course you'll see some slowdown.

SSDs will always have this problem to some degree as long as they use the same NAND flash architecture as any other flash media. For SSDs to really effectively compete with magnetic media they need to start from scratch.

Of course, then we wouldn't have the SSD explosion we see today, which is made possible by the low cost and high availability of NAND flash chips.

Don't try to hide flash technology (0)

Anonymous Coward | more than 5 years ago | (#27883169)

The real solution is to expose the flash block layout through the I/O bus and let the operating system and filesystem manage this itself. The flash-optimized filesystem would do more to aggregate writes into full erase-block size pieces and flush them to the flash device in one efficient pass.

Let the OS understand data block->erase block packing and just leave the device to manage wear-leveling of erase blocks by logically remapping them onto the real physical flash erase blocks.

Re:Don't try to hide flash technology (1)

Skapare (16644) | more than 5 years ago | (#27883347)

Both means should be provided. That way we can still have SSD devices emulating regular hard drives. But even if the direct layer access is not provided, a standard command code to identify block sizes, and a standard command code to erase a block (e.g. discard it from wear leveling translation for now) would be partly useful. One could erase all the blocks and thus reset the wear leveling over the whole device. Of course, you better have a few backup copies of the data.

Re:NAND is the culprit (1)

bbn (172659) | more than 5 years ago | (#27883181)

A smart device might do things a bit differently. It will not do your described cycle of read-block/change-data/erase/write-same-block. Instead it will buffer up enough changes until it has a full block and then write it to a _different_ block. One that is already preerased. There is no need to store sectors in the original order - just keep a table with sector locations.

A small capacitor makes it safe to delay writting by storing enough power to do emergency flush during powerloss.

I am sure makers of these device are putting much into making better algorithms to optimizing the write patterns and even online defragmentation of the device. Those algorithms is what sets the premium devices from Intel et al appart from the cheap crap.

I say it is not accurate that NAND needs to go away as you claim. We just need more mature strategies to handle these devices and Intel is doing pretty good already IMHO.

Re:NAND is the culprit (3, Informative)

eyepeepackets (33477) | more than 5 years ago | (#27883225)

Samsung has begun manufacture of their PRAM which promises to be a replacement for NAND:

http://www.engadget.com/2009/05/05/samsungs-pram-chips-go-into-mass-production-in-june/ [engadget.com]

Wikipedia writeup on PRAM:

http://en.wikipedia.org/wiki/Phase-change_memory [wikipedia.org]

This type of "flash" memory will make much better SSD drives in the near future.

Re:NAND is the culprit (3, Interesting)

KonoWatakushi (910213) | more than 5 years ago | (#27883703)

This is excellent news. As you allude, PRAM will finally make good on the promise of solid state storage. It will allow for both higher reliability and deterministic performance, without the ludicrous internal complexity of Flash based devices.

I can't help but cringe every time I hear the terms Flash and SSD used interchangeably. If anything, the limitations inherent to Flash devices described by the GP mean they have more in common with a hard disk, as they also have an inherent physical "geometry" which must be considered.

PRAM will basically look like a simple linear byte array, without all the nonsense associated with Flash. Even if Flash retains a (temporary) advantage in density, it will never compete with hard disks on value for bulk storage, nor will it ever compete with a proper SSD on a performance basis. It makes for a half-assed "SSD", and I can't wait for it to disappear.

Wear leveling and power management (1)

Skapare (16644) | more than 5 years ago | (#27883291)

Power management can turn off sections of the flash memory. This is good, of course, to reduce battery consumption in laptops and netbooks. But the process of turning a section's power off and then turning another section's power on can slow down the access. With very random access, expect that to simply happen a lot. So random hopping around the storage, while not as slow as a mechanical hard drive, will be slower than sequential.

Add wear leveling into the picture and you have a layer of memory translation. The purpose is to select different blocks out of a pool each time an erase needs to be done. So if you write over the same page of storage a million times, it is actually erasing a number of different blocks. In real world writing, which has its own random access, the end result over time is that this translation layer has the data scattered all over the available space.

Now even a sequential access to the data is really accessing the data in a random order based on what the wear leveling translation layer state is. This increases the number of times the access transitions from power controlled section to another. If the design is one where few or even one section can be powered on at the same time, this slows things down even for a sequential access. If the design allows many or even all sections to power on at the same time, then it shouldn't slow down (just for sequential reading), but would increase the power drawn and shorten battery charge/life if on battery power.

What would be useful ... if you don't mine occasionally losing all your data ... would be some kind of reset operation that can be done to the whole SSD device to discard and re-initialize the wear leveling translation (but not discard the bad blocks data). You could sequentially write over the whole device, which will help some, but won't be a complete re-initialization. The OS needs to be writing to the device in units of at least the erase block size in order to do this right. Multiple whole writes might do better than just one, but this is accumulating more wear on most (or if enough passes is done, perhaps just two ... all) blocks.

Re:NAND is the culprit (2, Informative)

BikeHelmet (1437881) | more than 5 years ago | (#27883389)

SSDs will always have this problem to some degree as long as they use the same NAND flash architecture as any other flash media. For SSDs to really effectively compete with magnetic media they need to start from scratch.

Of course, then we wouldn't have the SSD explosion we see today, which is made possible by the low cost and high availability of NAND flash chips.

Or...I dunno, maybe they could create a filesystem specifically for NAND flash [wikipedia.org] .

http://en.wikipedia.org/wiki/JFFS2 [wikipedia.org]

Therefore Headline is FALSE! (1)

StCredZero (169093) | more than 5 years ago | (#27883451)

So according to what you're saying, and what the Anandtech article said, the headline is just plain Wrong!

        http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=1 [anandtech.com]

The slowdown is only particular to NAND Flash. Dynamic RAM based solid state drives don't suffer from this phenomenon. (Gigabyte i-Ram and ACARD ANS-9010) However, they are definitely also Solid State Drives.

COW / LFS file systems (0)

Anonymous Coward | more than 5 years ago | (#27883787)

This isn't a problem if you're writing to blank sectors. But if you're writing, say, 4KB of data to a 512KB block that previously contained part of a larger file, you have to copy the whole 512KB block to cache, edit it to include the 4KB of data, erase the block, and rewrite it from cache. Multiply this by a large sequence of random writes, and of course you'll see some slowdown.

Unless you're using a COW / log-based file system, in which case you never write back to the same "LBA" of the device.

Once the SATA TRIM command is more widely supported, the OS will then tell the device to clear the no-longer-being-used LBA (assuming it doesn't need to be kept around for snapshots like in ZFS).

Re:NAND is the culprit (1)

MichaelSmith (789609) | more than 5 years ago | (#27884125)

How about using smaller blocks?

Re:NAND is the culprit (2, Interesting)

Lord Ender (156273) | more than 5 years ago | (#27884173)

Is there a fundamental reason why they can't just shrink the block size?

Ohhhh, I'm scared!!! (0)

Anonymous Coward | more than 5 years ago | (#27883019)

Yeah, the latency on high-end sequential writes will go from 0.08 ms to 0.10 ms.

Ummm, that's still an order of magnitude faster than any physical disk.

Wanna bet SSDs still work wonders as purposed devices for file systems like GPFS, QFS, ZFS, and XFS (the real version, not the crippleware that SGI GPL'd...) even after they "slow down from use"?

At least as long as you stick to the proven drives like Intel and Samsung (and probably a few others by now) and don't buy one of the utter crap drives out there now.

Not News (2, Interesting)

sexconker (1179573) | more than 5 years ago | (#27883099)

This is old news, and both the Intel drives and the OCZ Vertex have updated firmwares/controllers that remedy (but do not completely solve) the issue.

When we get support for TRIM, it will be even less of an issue, even on cheapo drives with crappy controllers/firmware.

The issue won't be completely solved ever, because of how SSD arranges flash memory and how flash memory can't really be overwritten in a single pass.

See anandtech's write up if you want details.
http://www.anandtech.com/printarticle.aspx?i=3531 [anandtech.com]

Re:Not News (1)

owlstead (636356) | more than 5 years ago | (#27883373)

Meh, if you see the random write data rate of the OZC drive (which uses a controller chip from a 3rd party company) the SSD drives totally obliterate the other drives in write speed, safe the expensive Intel ones.

We'll just wait a bit and buy either OCZ or another party that uses the controller with a stable firmware. Currently you will have to be on the lookout for bad/old firmware from OZC, or buy a drive that messes up write performance, or one darn expensive one from Intel.

Of course, if you mostly startup applications from the drive, you're already set.

Re:Not News (1)

sexconker (1179573) | more than 5 years ago | (#27883669)

OCZ Vertex drives have new controllers with good frimware.
Get your facts right.

Re:Not News (4, Informative)

AllynM (600515) | more than 5 years ago | (#27883835)

Intel has solved theirs about 95%, but they are helped by their write speeds being limited to 80 MB/sec. With the new firmware, it is *very* hard to get an X25-E to drop below its rated write speed.

http://www.pcper.com/article.php?aid=691&type=expert&pid=5 [pcper.com]

OCZ has not yet solved it. They currently rely on TRIM, and in my testing that alone is not sufficient to correct the fragmentation buildup. IOPS falls off in this condition as well.

Allyn Malventano
Storage Editor, PC Perspective

Re:Not News (2, Informative)

AllynM (600515) | more than 5 years ago | (#27885345)

Correction to my last. I was speaking of X25-M, not E.

Partly True (1)

Jane Q. Public (1010737) | more than 5 years ago | (#27884999)

I agree that it is not news (the topic, including performance reviews, was thoroughly covered by Tom's Hardware about 2 months ago), but the OCZ Vertex did not in fact "update" the controller. The new top-of-the-line Intel SSD does indeed have a new controller, that helps to minimize (but not eliminate) the issue. OCZ, on the other hand, just threw in another of the old controllers, and divided the memory between them to increase average throughput. The problem is still there, but it is somewhat less noticeable because the throughput is better on average.

But this is filesystem dependent (0, Offtopic)

Sleepy (4551) | more than 5 years ago | (#27883545)

This is going to be a much bigger problem on FAT32 and NTFS, than modern Linux filesystems because FAT32 and NTFS fragment after very little use.

If you're worried, increase your block size. That shouldn't be a problem if you're writing media to the disk (as opposed to a billion tiny files, in which case large blocks would waste extra disk... but still be able to withstand fragmentation...)

Re:But this is filesystem dependent (0, Offtopic)

RiotingPacifist (1228016) | more than 5 years ago | (#27883823)

So we should all go back to reiser3 the fragmentation-less filesystem? :P

Re:But this is filesystem dependent (0)

Anonymous Coward | more than 5 years ago | (#27884561)

OP is right. This is what I was thinking when I read the summary. Fragmentation is a filesystem issue. If your filesystem has an online defragmenter, what is the fscking problem?

I believe POSIX mandates storage to be handled in blocks and the blocks referenced by inodes. SSDs are just begging for this kind of filesystems!

POSIX does not mandate online defragmenters, afaik, but if your filesystem has that, you're gold. So I'll question this again, what is the fscking problem?

Re:But this is filesystem dependent (0, Redundant)

NSIM (953498) | more than 5 years ago | (#27884645)

This is going to be a much bigger problem on FAT32 and NTFS, than modern Linux filesystems because FAT32 and NTFS fragment after very little use.

If you're worried, increase your block size. That shouldn't be a problem if you're writing media to the disk (as opposed to a billion tiny files, in which case large blocks would waste extra disk... but still be able to withstand fragmentation...)

The fragmentation we are talking about here is not related to file system fragmentation. All the testing that has created this affect has been done with IO test programs like IOmeter that can create I/O patterns that are specifically designed to demonstrate the problem. So it will affect EXT3 or whatever LINUX file system you prefer just as much (or as little depending on your point of view) as NTFS or DOS

Re:But this is filesystem dependent (0, Redundant)

Jane Q. Public (1010737) | more than 5 years ago | (#27885031)

The problem has nothing to do with fragmentation in the usual sense! SSD memory controllers do not even write your data sequentially, so "fragmentation", as applies to magnetic media, is pretty much meaningless here.

The problem is between writes and re-writes. On a fresh block, data can be written at full speed. But whenever anything inside that block needs to be re-written, contiguous or not, the whole block must be read from memory, altered, then re-written. It could all be contiguous data, and that would still be necessary. The difference is simply between the time it takes to write a fresh block, and the time it takes to re-write it, because re-writing simply takes longer. Period.

Not ALL (0)

Anonymous Coward | more than 5 years ago | (#27883749)

If you read the article, Intel is reported to have fixed the problem with their X25-M SSD with a firmware update, and no data are provided to indicate that the problem remains. If Lucas123 is going to claim all drives suffer from the problem, then s/he needs to provide data to support it. Otherwise, it's just unscientific conjecture. Not that I don't believe it's still an issue, but no data are actually provided in this article!

So f*cking what? SATA is the bottleneck nowadays. (0, Troll)

Qbertino (265505) | more than 5 years ago | (#27884345)

What's the big fat hairy deal? Correct me if I'm wrong, but with SSDs access times out of the ms and in the ns range SATA is the bottleneck for those aswell. As it has been with throughput ever since we've had upwards of 5K RPM disks and upwards of 8MB cache on the controllers. Which was around 2002 IIRC.

In fact, it's actually the strangest thing to connect a SSD via SATA in the first place. A waste of power, space, time and complexity. Throughput wise anyway. An entirely different diskbus is long overdue. USB 3 could maybe be a candidate, no? One piece of outdated legacy less - allways a good thing imho. I personally thought of skipping SATA entirely and using internal USB 2 instead, back in the day when SATA was the hottest new thing.

Re:So f*cking what? SATA is the bottleneck nowaday (1)

Glendale2x (210533) | more than 5 years ago | (#27884553)

Firewire.

Re:So f*cking what? SATA is the bottleneck nowaday (1)

NSIM (953498) | more than 5 years ago | (#27884661)

I'm running an Intel x25m as my boot drive, I've used the system with and without the SSD, you'll pry the SSD from my cold dead hands. The responsiveness when using the SSD is astonishing, apps just spring open as fast as you can release the mouse button.

Tom's Hardware (3, Insightful)

Jane Q. Public (1010737) | more than 5 years ago | (#27884899)

wrote a thorough review of SSDs, including the X25, complete with a full technical explanation of exactly what causes the performance degradation.

About 2 months ago.

Of course they're seeing a lot of fragmentation (-1, Offtopic)

jimfrost (58153) | more than 5 years ago | (#27885309)

They're using Windows. (Half joke.)

It still astounds me that twenty-plus years after BSD FFS we have NTFS doing absolutely nothing whatsoever to avoid initial fragmentation. You want to talk about a lazy monopoly, there's proof right there; nobody else still has this problem.

Back on the subject at hand, SSDs were always likely to have teething pains, that's one of the reasons I've avoided them. We saw the same kind of thing with compact flash, if you remember. Give 'em a couple more years to work through it and get the prices down and capacities up and laptops won't have spindles anymore.

Oh yea, and try hard not to use SSDs for swap. The very thought of a Windows paging storm to an SSD makes me think of a burning wallet.

This is definitely a limitation of the technology (1)

AbRASiON (589899) | more than 5 years ago | (#27886617)

However...

As long as they can get the read, write, random read, random write performance to be substantially better than a hard disk - across the board I don't care too much.
Example: many many years ago, on my 286, I extracted a floppy disk with 1,800 .ico files on it (754 bytes?) in a zip file.
That took about an hour to do.
I then learned about 'smartdrv.sys' (or was it EXE?)
The time to do it went from an hour to about 30 to 60 seconds.

The way the FAT16 worked on my machine with a 20mb drive and a 286 CPU it was writing back and forth constantly for that many files, it was very in-efficient, each subsequent .ico file being extracted from the zip made it slower.

Now if we have some kind of alternative which alleviates this problem in Windows (and can still keep write corruption down, in the event of a power failure) I'd be curious to see it implimented.
Sooner or later SSD's will be better than magnetic hard disks, across the board (possibly inclduing space) right now there's some issues but I'm thinking, after Anands huge article a month or so ago, the manufacturers know that the consumers are switched on to this.

You'll see an OCZ Vertex 2.0 drive sooner or later, across the board faster than the 1.0, possibly cheaper and possibly bigger.
I would guess, within 18 months 'regular' non geeked out enthusiasts will be snapping up SSD's and within 48 months from now, you'll see SSD's shipped commonly in laptops and desktops purchased from IBM, Dell, HP at regular prices for regular office worker workstations (600$ US jobbies)

I for one, can't wait.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>