timwhit
0
Well, at least it sounds easy enough to fix. This will give me slightly longer to figure out how to buy this without angering my GF.
SSDs - State of the Product?
- Thread starter ddrueding
- Start date
Well, at least it sounds easy enough to fix. This will give me slightly longer to figure out how to buy this without angering my GF.
I don't understand why the X25-E is not being upgraded to the newer memory until 2010. Even if performance is the same, wouldn't production be less costly? How much effort does it take to update the associated components? Maybe they have a stockpile of unsold materials?
My guess would be either:
1) They don't have the production capacity to move everything to the new process
2) The X25-E is an "enterprise" part and needs more testing
I would lean towards #2, as it would make more sense to move their higher-margin parts to the new tech first and help justify the price.
1) They don't have the production capacity to move everything to the new process
2) The X25-E is an "enterprise" part and needs more testing
I would lean towards #2, as it would make more sense to move their higher-margin parts to the new tech first and help justify the price.
Stereodude
Not really a
Or, maybe there isn't SLC memory available on the 34nm process yet. :scratch:
Gilbo
0
Get the X25-M. There isn't a real-world, significant performance difference for any task I can think of.
In fact, for Photoshop, for example, 4 inexpensive traditional HDDs will offer superior performance as a scratchdisk.
The X25-E is only useful for very specific enterprise/server applications. Anything you can do on a single-user desktop will be served just as well or better by other, less expensive options.
In fact, for Photoshop, for example, 4 inexpensive traditional HDDs will offer superior performance as a scratchdisk.
The X25-E is only useful for very specific enterprise/server applications. Anything you can do on a single-user desktop will be served just as well or better by other, less expensive options.
mubs
0
You mean in Raid-0?
Pradeep
0
Interesting, but I don't know how relevant that is to my situation. Access times are definitely more important than STR sometimes. If I were to run a RAID 0 configuration, it would be with SSDs. There is no space internally for 3.5" hard drives nor do I have interest in more external arrays. Buying an SATA 3Gb/s RAID controller now would not be worthwhile given that faster SATA is coming soon, and a future SSDs will need it.
I'll be getting rid of my 2x 32GB X25-Es...let me know.
The Vertex in RAID-0 is just fine for my needs. I'll go to 4 120GB in RAID-0 and stop worrying about what drive data is on.
Presently I have 2x 120GB Vertex in RAID-0 and 2x 32GB X25-E in RAID-0. I'm just tired of shuffling stuff around.
Presently I have 2x 120GB Vertex in RAID-0 and 2x 32GB X25-E in RAID-0. I'm just tired of shuffling stuff around.
I suspect it will be the bees knees, dogs nuts or some such thing. If it really does what I think it's supposed to do (clear free space in idle time).
The article suggested there was a performance penalty for the TRIM command. Did I read it incorrectly? It only works when files are deleted and not overwritten. It was proposed as copying the block to cache (seems scary to me), wiping clean the LBA, and then writing back the adjusted blocks to clean up. I don't fully understand why this affects SSDs and not HDDs.
If you're using it as a scratch drive, they have a complete wipe program that makes it like-new.
Pradeep
0
SSDs require an erase step before a write. When a file is deleted the OS may just deallocate that space. So a block could be available, but not erased. HDDs don't have the erase step.
Fushigi
0
Would TRIM eliminate the ability to un-delete a file once the Recycle Bin has been emptied? Sounds like it. Not really a problem for me but I'm curious.
I don't get the erase step and how it's different from an HDD. Why don't HDDs need the erase step if the OS deallocates? Is it just allowed to overwrite without erasing? Is the difference with SSDs that they must erase or else it won't allow for that block to be used again because the OS will think it has data in it?
A good explanation of TRIM is here:
http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=10
The problem TRIM attempts to solve is that of the flash controller trying to find free blocks to write to. If they are actually free instead of having old data in them, they are found faster and the writes happen faster. Otherwise I think it has to erase and then write for some reason (can someone back this up with a link - I can't find the article I read it in now). It can't just write. So there is added time finding blocks to write and added time actually writing them. TRIM does remove data that is marked as deleted and will remove undelete functionality but not recycle bin functionality. Added to this I think is the fact that the block size is pretty big. I think it is like 4KB or something.
HDD don't perform the same free block finding functions. They don't have to worry about wear levelling. They just find the first available block and maybe optimize a bit for which it can write to faster.
http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=10
The problem TRIM attempts to solve is that of the flash controller trying to find free blocks to write to. If they are actually free instead of having old data in them, they are found faster and the writes happen faster. Otherwise I think it has to erase and then write for some reason (can someone back this up with a link - I can't find the article I read it in now). It can't just write. So there is added time finding blocks to write and added time actually writing them. TRIM does remove data that is marked as deleted and will remove undelete functionality but not recycle bin functionality. Added to this I think is the fact that the block size is pretty big. I think it is like 4KB or something.
HDD don't perform the same free block finding functions. They don't have to worry about wear levelling. They just find the first available block and maybe optimize a bit for which it can write to faster.
Just read that whole anandtech article.
They explain here
http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8
about the problem without the TRIM command.
They explain here
http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8
about the problem without the TRIM command.
You're spot on, Will. HDD can just overwrite a block of data that has been previously marked as empty. SSDs need to erase an entire block before any part of it can be written. The wear leveling part is pretty easy to understand; the first pass will use every block on the drive. From then on, even yif you erased everything, all blocks would require an erase before any write.
Even with TRIM, you will want to maintain a decent chunk of free space on the drive, or wear levelling will not be nearly as effective.
Even with TRIM, you will want to maintain a decent chunk of free space on the drive, or wear levelling will not be nearly as effective.
No, TRIM prevents the write penalty caused by all blocks already containing data by clearing blocks before they are needed. Without it, blocks are cleared after the write has been requested, incurring a performance penalty.
ok, so with an SSD that has TRIM with a supported OS, if I delete a file, TRIM runs at that time and clears the block? I don't understand why the SSD can't function like a HDD in this manner? I think you said it was because of the wear leveling functionality, correct? The idea being not to reuse the same block to avoid repetitious wear on the same block location? Because of this, the drive continues to fill up until near capacity spreading out repetitious load and then those blocks that were freed a while back won't get erased until the drive needs that space (assuming there is no TRIM involved)? It still seems like the wear leveling functionality (if I'm understanding it correctly) is causing the issue in which TRIM is supposed to work around?
Almost. A HDD can overwrite any chunk of data with new data at any time without penalty. SSDs must erase an entire block before making any change to it, overwrites aren't possible. This adds an additional time penalty to any write operation.
You can disregard the wear leveling bits for the discussion of TRIM, one does affect the other, but it isn't relevant to understanding TRIM.
You can disregard the wear leveling bits for the discussion of TRIM, one does affect the other, but it isn't relevant to understanding TRIM.
And the gem from the article was that while a page was 4KB, a block was typically 512KB, and the whole block needed to be erased and then rewritten.
Some restriction of NAND flash and the way it works. So even if it had to write a tiny 4KB page, it needed to write 512KB.
So your write speeds are like 128 times slower or something when there are no free pages/blocks. TRIM is attempting to erase blocks when you have time after the delete so they aren't erased when you are writing data. Anand was saying it doesn't help with rewriting files though. But that can't be correct. Why doesn't it just write the file to the free pages and mark the previous location to be freed. There may be firmware optimizations like that when TRIM is supported by the OS.
When you are writing data is when you would notice the slowdown. When you delete a file you don't care about it anymore. The process isn't blocking on the delete. A process will block on a write. The process may hide it from you like word's background saving. But something is waiting for that I/O to complete whether it be a program or the OS.
Some restriction of NAND flash and the way it works. So even if it had to write a tiny 4KB page, it needed to write 512KB.
So your write speeds are like 128 times slower or something when there are no free pages/blocks. TRIM is attempting to erase blocks when you have time after the delete so they aren't erased when you are writing data. Anand was saying it doesn't help with rewriting files though. But that can't be correct. Why doesn't it just write the file to the free pages and mark the previous location to be freed. There may be firmware optimizations like that when TRIM is supported by the OS.
When you are writing data is when you would notice the slowdown. When you delete a file you don't care about it anymore. The process isn't blocking on the delete. A process will block on a write. The process may hide it from you like word's background saving. But something is waiting for that I/O to complete whether it be a program or the OS.
Newegg says ETA 8/28/09. I'd like to buy one of these also.
Where does one find this app?
Possibly here, but I have not tested or verified legitimacy.
sechs
0
I think it's important to understand that not only must flash memory be erased before rewritten, but they have a minimum block of data that they must write. So, if you change part of a write block, the good data must be read, the entire block erased, and the data written, some of which was there before. That's not anything like how spinning magnetic disks work.
You can get around this read-erase-write problem by having empty blocks, and just doing read-write. But you burn through your empty blocks faster doing that; you're just putting off the issue. By erasing blocks that are marked by the file system as available, you can put it off furthur -- and, perhaps, indefinitely.
sechs
0
If you have an OCZ drive, they have utilities on their website.
And that gets back to my earlier question about TRIM wearing out an SSD faster. It seems like you can have performance or longevity.
And another thing struck me, SSD's would be poor as swap drives or scratch pads, or in any situation where frequent re-writes of the same data happens. Or am I off base?
And another thing struck me, SSD's would be poor as swap drives or scratch pads, or in any situation where frequent re-writes of the same data happens. Or am I off base?
Fushigi
0
They'd be poor for swap/scratch space from a longevity standpoint if the swap space used was a truly significant portion ofthe disk. But if it's just a few GB then I don't see it as much of an issue. The wear leveling helps in this regard.
Besides, aren't these drives rated for continuous (24x7) read/writing for 5+ years anyway? In 5 years we'll be ready to move on to something newer/better/faster/hopefully cheaper.
Question: Should an SSD be formatted with as close to a 512KB cluster as possible to reduce the read-wipe-write cycle when multiple files are involved?
Besides, aren't these drives rated for continuous (24x7) read/writing for 5+ years anyway? In 5 years we'll be ready to move on to something newer/better/faster/hopefully cheaper.
Question: Should an SSD be formatted with as close to a 512KB cluster as possible to reduce the read-wipe-write cycle when multiple files are involved?
IIRC, they are rated for 8x5 writing for 5+ years still way more than enough. With the tech moving as quickly as it is, none of these drives will be in use 5 years from now.
I vaguely recall something about a special formatting tool to align the logical clusters with the SSDs physical blocks. It was supposed to help, but I've never bothered with it as I am completely happy with the performance of my SSDs.