Slashdot Mirror


Solid State Drives Tested With TRIM Support

Vigile writes "Despite the rising excitement over SSDs, some of it has been tempered by performance degradation issues. The promised land is supposed to be the mighty TRIM command — a way for the OS to indicate to the SSD a range of blocks that are no longer needed because of deleted files. Apparently Windows 7 will implement TRIM of some kind but for now you can use a proprietary TRIM tool on a few select SSDs using Indilinx controllers. A new article at PC Perspective evaluates performance on a pair of Indilinx drives as well as the TRIM utility and its efficacy."

196 comments

  1. But its the future by telchine · · Score: 5, Interesting

    I finally got the opportunity to test out SSDs this year. There may be the odd teething problem to get over, but in my mind there is no market in the future for mechanical drives except maybe as cheap low-speed devices for storing non-critical information... in much the same way as tape drives were used a few years ago.

    1. Re:But its the future by Rockoon · · Score: 1

      The mechanicals may be able to stay ahead in capacity for a long long time, even though they obviously have no hope of competitng in the performance arena ever again.

      --
      "His name was James Damore."
    2. Re:But its the future by Anonymous Coward · · Score: 3, Insightful

      I finally got the opportunity to test out SSDs this year. There may be the odd teething problem to get over, but in my mind there is no market in the future for mechanical drives except maybe as cheap low-speed devices for storing non-critical information... in much the same way as tape drives were used a few years ago.

      Well damn, I'll just have to tell our customer that has something like a 30 petabyte TAPE archive that's growing by about a terabyte or more each and every day that they're spending money on something you say is, umm, outdated and these newfangled devices that the next power surge will totally fry are the wave of the future.

      Guess what? There's a whole lot more money spent on proven rock-solid technology by large organizations then you apparently know.

      Tape and hard drives are going NOWHERE. For a long, long time to come.

    3. Re:But its the future by Anonymous Coward · · Score: 1, Interesting

      The mechanicals may be able to stay ahead in capacity for a long long time, even though they obviously have no hope of competitng in the performance arena ever again.

      I disagree with this. With mechanicals, we're adding 250-500GB with each iteration. With SSD, they're doubling with each iteration. Considering they're basically at 1/8 the capacity of mechanical drives, it'll only be another couple of years before they surpass mechanical drives.

    4. Re:But its the future by rm999 · · Score: 4, Informative

      Actually, magnetic disks have exponentially increased in capacity since the 50s. In fact, the rate of increase has been higher than the growth of transistor count.

      See: http://www.scientificamerican.com/article.cfm?id=kryders-law

    5. Re:But its the future by MeatBag+PussRocket · · Score: 4, Interesting

      if by "proven rock-solid" you mean horrid fidelity and media degradation rates, i'd say you are correct about tapes. if you're client has a 30 petabyte tape archive there is probably some horrible inefficiency goin on. (i'm sure you probably have little control ofer the situation, i have similar clients) but if they have 30Pb of data on tape that they access regularly, they're wasting a LOT of time just retrieving data. you should really consider a SAN NAS or similar. HDD storage is very cheap these days and LTO4 tapes are pretty pricey. we all know they have shoddy storage quality to boot. if they dont access it regulary then its probably a real waste of money to own, record and store 30Pb of data. either way, just the physical storage of that many tapes is probably about equivelant to the sq. footage needed for a rack or 2 (or 3) of blade servers with the same storage capacity.

      --
      i wage a holy war against the apostrophe.
    6. Re:But its the future by timmarhy · · Score: 1

      nope. tape is STILL the only way to backup your data if your serious. i've been hearing about the death of the spinning platters for a decade now and it's still just around the corner, much like fusion and peak oil.

      --
      If you mod me down, I will become more powerful than you can imagine....
    7. Re:But its the future by hedwards · · Score: 1

      What are you talking about? We've already seen peak oil, that came about a few years back.

    8. Re:But its the future by noidentity · · Score: 1

      As long as magnetic drives give lower effective price per bit, they will be used.

    9. Re:But its the future by timmarhy · · Score: 1, Troll

      you don't have a fucking clue, because not every country declares it's reserves. at some point oil WILL run out, but anyone claiming to know when is a damned liar and not to be trusted.

      --
      If you mod me down, I will become more powerful than you can imagine....
    10. Re:But its the future by Anonymous Coward · · Score: 0

      What do you mean "a few years ago" .... my company still uses tape drives >.

    11. Re:But its the future by dgatwood · · Score: 2, Interesting

      Things have changed a lot in four years. Since 2005, hard drives have only increased from 500 GB to 2 TB---a factor of 4. In that same time, Compact Flash cards increased from 8GB to 128 GB---a factor of 16. Flash density increases are severely outpacing hard drive density increases, and unlike hard drives, flash storage isn't rapidly becoming less reliable as the density increases....

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    12. Re:But its the future by morgan_greywolf · · Score: 1

      Mod parent up. SSDs are a very immature technology and are not, yet, ready for the enterprise data center. Wait a few years until the technology matures. Magnetic hard drives have been around for what? 30-40 years? They're stable and proven. How many multi-petabyte enterprise data centers have you seen running SSDs as their primary storage? None. Yeah, that's what I thought.

      They also have a long way to go before they compete with mangetic hard drives in terms of cost.

    13. Re:But its the future by Phishcast · · Score: 2, Insightful
      How many multi-petabyte enterprise data centers have you seen running SSDs as their primary storage? None. Yeah, that's what I thought.

      Agreed that SSDs have a long way to go on price to compete, but it's simply not true that they're not yet ready for the enterprise datacenter. All the larger enterprise storage array vendors (EMC, HDS, IBM, NetApp) say they're ready, and most are shipping them with decent sales. Despite their price and the "fact" you've so eloquently stated, you'll find them in many Fortune 500 datacenters simply because they outperform spinning disks by such a factor that they're cheaper per IO. I believe today the vast majority of vendors providing enterprise-class SSD drives are sourcing them from STEC. They play some tricks to work around write limits, but they've got ~5 year MTBF ratings.

    14. Re:But its the future by Anonymous Coward · · Score: 0

      The thing, you see, is that hard drives have a much better linear write speed than SSDs.

      The problem (for HDs) is that the IDE protocol (regardless of whether it's over IDE or SATA), and likewise the SCSI protocol (over... whatever) try to expose a high level interface: linearly addressed blocks. And you don't know (at the OS level) where they are, how long it's going to take to get there and write to them and so on. On top of that, the OS exposes a higher again level interface: files.

      The result is an interface that's much slower than could be.

      To take a simple example, let's say you're running a database. A transaction commits (or prepares). The DB doesn't care *where* the prepare or commit is written, and it would be quite happy to reserve 4 blocks per cylinder (latency .5 ms on a 15k rpm disk) or 16 (.13 ms) to write it down ASAP, instead of the current 5-10 ms. But it can't. It'd need know where the heads are and then say "on that same cylinder (or one next to it), platter m, sector n1, or n2, or n3, write *this* *next time you're on it*, then tell me (I'll clean up later). Not possible.

      The OS gets in the way. Theoretically it could expose a different FS access layer that would allow it, but the HD interfaces we have just can't support it.

      And that's the issue. And it's the same issue with SSD. OSes are perfectly capable of handling 64k write blocks, avoid rewriting too many times, packing writes, and so on, but we're stuck with this "nice" "addressable" "block" crap and drives trying to do too many things that the OS could do much better.

      It's a really f*cked up situation.

    15. Re:But its the future by billcopc · · Score: 2, Interesting

      All the larger enterprise storage vendors are full of shit. They say the SSD is "ready" because it's the hottest buzzword in the industry, which always commands huge profit margins.

      On one hand, I can use cheap fast 2.0TB SATA drives for 11 cents a gig, or I can go the SSD route with 256gb drives at $4.00 a gig. That's OEM cost, which means EMC and friends will triple that number, to convince your boss these drives are "special".

      Yeahhh... give me the one that costs 36 times more, takes up 4 times more space, requires 8 times more controllers and is guaranteed to wear out in a few years. If your I/O patterns are so messed up that today's horrendous SSDs actually lower your cost per I/O, you need to rethink your information architecture.

      --
      -Billco, Fnarg.com
    16. Re:But its the future by uncqual · · Score: 1

      You kids today... I've been hearing about the death of spinning platters for two decades.

      Eventually they will virtually disappear as paper tape, cards and, more recently, floppies have -- but it will take a lot longer than most expect.

      Now get off my lawn.

      --
      Why is there an "insightful" mod and why isn't it "-1"? If I wanted insight, I wouldn't be reading /.
    17. Re:But its the future by j-turkey · · Score: 2, Insightful

      ...and unlike hard drives, flash storage isn't rapidly becoming less reliable as the density increases....

      I can see the logic behind the argument that hard drives should become more failure prone as the platter density increases, but I've yet to see any data substantiating this point. Your claim that hard drives are rapidly becoming more unreliable makes your statement come off as even more dubious to me.

      I don't mean to attack you or come off as a complete dickhole, but do you know of any data to back this up? I'm legitimately curious, as in my (completely anecdotal) experience, magnetic hard drives seem to be getting more and more reliable.

      (Mind you, I'm seriously knocking on wood...I know that I'm going eat my words when I wake up to multiple simultaneous drive failures just for opening my big fat mouth about my good fortune with magnetic data.)

      --

      -Turkey

    18. Re:But its the future by rcw-home · · Score: 1, Insightful

      Yeahhh... give me the one that costs 36 times more, takes up 4 times more space, requires 8 times more controllers and is guaranteed to wear out in a few years. If your I/O patterns are so messed up that today's horrendous SSDs actually lower your cost per I/O, you need to rethink your information architecture.

      There are two schools of thought regarding SSDs:

      1. Those who talk shit about them
      2. Those who have used them
    19. Re:But its the future by Phishcast · · Score: 1
      How many of these 2.0TB SATA drives are you going to purchase to do the same number of random cache miss IOPS that a single SSD can do? The math does not lie, applications are out there that can gain massive performance improvements and save money at the same time using SSDs. It's so easy to say hey, re-architect your application. Guess what? Mission critical apps grow organically and are not always optimized. How heavily used will your application get before even your optimized IO creeps into the realm of "I/O patterns so messed up that today's horrendous SSDs actually lower your cost per I/O"? How much money do you think the bank/nation-wide retailer/wall street firm would need to spend to "rethink their information architecture"? Not to mention power and cooling of a room full of short-stroked 2TB SATA disks vs one cabinet of SSDs.

      SSD is not gaining traction simply because it's a buzzword and commands huge profit margins (both are true). It works. It solves real problems. In the right cases it saves money. If you spent some time in a larger organization I suspect you'd change your tune. You're comparing 2TB SATA apples to 256GB SSD oranges. Both may be fruit, but they're not interchangeable.

    20. Re:But its the future by complete+loony · · Score: 1

      Unfortunately the speed of the interface to read and write to magnetic disks hasn't been increasing at the same rate as the volume of the disk.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    21. Re:But its the future by Courageous · · Score: 3, Informative

      Flash drives have longer MTBF than spinning media... so they last longer. However, a less well known fact is that flash drives have a URE rate 10-100X worse than spinning media does typically today. It's getting fixed, but the fellow you're replying to is basically wrong.

      C//

    22. Re:But its the future by Courageous · · Score: 1

      It will be more than 6 years before SSD's surpass the commodity SATA segment in $/GB, and $/GB is definitively what drives Tier 2 storage. So while the enterprise 10K/15K's years are numbered (I expect days of total destruction NLT 2011), SATA will be around for a while.

      C//

    23. Re:But its the future by rtfa-troll · · Score: 1

      Hint: peak oil doesn't mean "oil has run out". It could just mean that the price of oil has had a long term decline and people are no longer trying as hard to get oil out and never will. You need to show a bit more evidence than "you don't have a fucking clue" before we can believe you are right. To be honest, his statement is probably more a hopeful prediction about the level of usage of wind power and other renewable energy sources than about oil reserves.

      --
      =~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
    24. Re:But its the future by LordLimecat · · Score: 1

      That appears to be an 80GB drive for $314. For that price I purchase at least 5 80GB magnetic disks. I think his point was valid, and Im not sure how you thought you were refuting it.

    25. Re:But its the future by beelsebob · · Score: 1

      Not true I don't think. SSDs already beat HDDs in terms of data density, as can be observed by the fact that you can buy 512GB 2.5" SSDs (for silly money), but only 500GiB HDDs. The only factor that HDDs win on now is price, and I don't expect it to take long before that changes.

    26. Re:But its the future by Trahloc · · Score: 1

      Actually I think you missed the point of 'peak oil' as well. Peak oil is the point where you can't pull anymore out of the ground and the *supply* is starting to dwindle, not the demand. The reason the grandparent is reacting the way they are is because 'peak oil' has been declared multiple times only to be pushed back by a technological innovation or the discovery of a new oil reserve that once again increases potential oil production beyond demand.

      Artificial restrictions by OPEC that dwindle supply below demand do not a 'peak oil' make.

      --
      The Goal: A long simple life filled with many complex toys.
    27. Re:But its the future by morgan_greywolf · · Score: 2, Insightful

      I think he was pointing to the "reviews". Here's the thing: none of those reviews were from enterprise-class users.

      Once you start getting into 10 drive RAID arrays (and up), speed of each drive is no longer your limiting factor, provided you're using some kind of striping. That's the reason SATA RAID arrays have started to become popular in the enterprise for less critical systems -- there's almost no performance difference at all. You need to go fibre channel before you see any marked difference in performance.

    28. Re:But its the future by danieltdp · · Score: 1

      Your alegation is true *IF* both continue to grow at the same rate. There is no basis to believe that this is a fact.

      In my opinion, nothing can be said about the future.

      --
      -- dnl
    29. Re:But its the future by fimbulvetr · · Score: 1

      I can see how you would draw that conclusion alone on just the numbers, but I think you failed to take into account that hard drives are selling at much faster rates than they did during the times of HDDs, and those rates are accelerating. Since volume is ramping up considerably, manf have insane incentives to increase there economies of scales at commenserate rates, thus lowering the costs.

      If you don't believe it, use your same reasoning for SIMMs vs. DIMMs. Then try it against DIMMs vs. DDR1, then DDR2. I picked up two 2GB SODIMM DDR2 modules yesterday for $20/piece.

    30. Re:But its the future by rcw-home · · Score: 1

      That appears to be an 80GB drive for $314. For that price I purchase at least 5 80GB magnetic disks. I think his point was valid, and Im not sure how you thought you were refuting it.

      Pick any set of magnetic disks + controller hardware that you can get for $314. Now make it do 23MB/sec in random writes. Or anything close to that.

    31. Re:But its the future by afidel · · Score: 1

      Uh, think again. If you need lots of IOPS and not tons of storage SSD's are great. The Intel x-25e and FusionI/O drives are enterprise class. I can get nearly the same IOPS out of a $800 x-25e as I can out of a quarter million dollars worth of disks and controllers. If you have certain classes of problems (hot log volumes, data cache where latency matters, etc) then SSD's are great today and the technology is getting better by the quarter.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    32. Re:But its the future by Eivind · · Score: 1

      True a price-differential of ~35 is huge, and enough to make it cost-prohibitive for many applications. However that differential is shrinking, aand at the same time the storage/dollar ratio is rising quicker than peoples production of data grows.

      If these two trends continue, more and more people will switch to SSD.

      First, because a 5:1 premium is more acceptable than a 50:1 one. And second because a 5:1 premium, in a world where the storage you need costs $200 with the cheap option would mean paying $1000, which few people would do. Whereas in a world where a $100 disk has 3 times the capacity you need, payinng $150 instead for a solution that is large enough, and significantly faste, can make sense.

      Witness how people buy laptops, despite higher performance for the same price in a desktop.

      It's just that the performance of a modern laptop is good *enough* and it's cheap *enough*, so people -do- buy $700 laptops that have less capacity than a $500 desktop would. For the same reason, they may buy a $150 SSD-disk with less storage-capacity than a $100 HDD.

    33. Re:But its the future by Courageous · · Score: 1

      I'm not sure what you are trying to say. Did you mean to say, you think we'll be getting SSD's in the SATA segment sooner? This could be. But project for me what you think is the correct %decrease in price for both SATA drives and SSD's. Put them in a spreadsheet. Tell me when $/GB is less for SSD's. Do keep in mind that there is nothing to say that areal density in spinning media is finished...

      I think the 15K segment is finished, partly because the SDD's are increasing far more quickly in performance than spinning media. The 15K segment is performance-driven.

      The 15K segment will hold on a little while longer yet, though. The uncertainty associated with performance-degradation after use, along with the less well publicized URE problems, will hold enterprises back for a bit.

      C//

    34. Re:But its the future by dgatwood · · Score: 1

      My number of hard drive failures was averaging about one every 3-4 years for most of my life. My failure rate last year was three in a week, four in a year, spread across two brands and four drive models. That's purely anecdotal, of course, but jaw dropping, nonetheless, as IIRC it represented 100% of the in-warranty drives I had spinning at the time..

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    35. Re:But its the future by j-turkey · · Score: 1

      Wow - impressive (if not scary). I think that I'm going to spend some time today counting my lucky stars while I back up my data. :)

      --

      -Turkey

  2. What I really want to know by earthforce_1 · · Score: 2, Insightful

    Which Linux filesystem works best with SSDs? I don't intend to touch Win7.

    --
    My rights don't need management.
    1. Re:What I really want to know by loufoque · · Score: 1

      NILFS2 I suppose.
      Supposedly beats the crap out of LogFS, YAFFS and JFFS2 when using SSDs.

    2. Re:What I really want to know by AigariusDebian · · Score: 3, Informative
    3. Re:What I really want to know by vadim_t · · Score: 2, Informative

      That's because JFFS and such are intended to be used on top of a raw flash device.

      SSDs do wear levelling internally already, so a filesystem that tries to do it as well is redundant.

    4. Re:What I really want to know by SanityInAnarchy · · Score: 3, Insightful

      That's my biggest complaint about them, actually -- these "teething problems" people mention are pretty much directly a result of OSes treating SSDs as though they were spinning magnetic disks.

      No, the OS should be able to do its own wear leveling. If you need to pretend it's a hard drive, do it in the BIOS and/or the drivers, not in the silicon -- at least that way, you can upgrade it later when things like this come out.

      --
      Don't thank God, thank a doctor!
    5. Re:What I really want to know by blitzkrieg3 · · Score: 4, Informative

      You beat me to it, but in the spirit of adding value, there's a good article here. Another benefit of nilfs2 is that you can easily snapshot and undelete files, giving it a sort of built in "time machine" technology (to use apple's terminology).

      I'm just surprised that none of the linux distros are talking about it yet. You would think with the apple and ibm laptops using SSD today that there would be some option somewhere. I think everyone is distracted by btrfs.

    6. Re:What I really want to know by MeatBag+PussRocket · · Score: 1

      i would think EXT4 would be the FS of choice for a SSD, if i'm wrong, i wouldnt be surprised but why those over EXT4?

      --
      i wage a holy war against the apostrophe.
    7. Re:What I really want to know by Anonymous Coward · · Score: 0

      Normal file systems are designed for hard drives. That means a file's blocks are contiguous, if possible, and if you need to update a block, you overwrite it in place. With SSDs, there's no rotational delay, seek delay, etc, so there's no advantage to having a file's blocks being near each other. However, there is a big disadvantage in updating a block in place. Log file systems don't update blocks in place, they leave the old block as is and write data to an unused block. That means you get free snapshot capabilities, but it also means it works well with SSD's limited write cycles.

    8. Re:What I really want to know by onefriedrice · · Score: 1

      I've got ext4 on my SSD. It performs very well, but nilfs is a better fit for an SSD. I'll reformat to nilfs sometime within the next few kernel release cycles. Nevertheless, ext4 is just fine--I even have journaling and all the other bells and whistles. I'm not afraid of the additional wear as I suspect the drive will fail by some other technical malfunction long before the flash cells wear out.

      By the way, it's true what they say: An SSD is the one component that will provide you with the most noticeable performance boost your computer has ever had, and it's one of the cheapest, too. I just got a 30G for ~$120 and my root filesystem fits comfortably on it (obviously my data is on a spinning disk). Now I boot in seconds and applications (yes, even Firefox) load instantly--makes "bloat" virtually irrelevant. Seriously, I still like platter drives for their capacity, but you don't need a lot of space to store your root filesystem and you can't beat the performance improvement for just over a hundred bucks spent.

      In my opinion, an SSD need no longer be considered a toy for early adopters. I certainly don't consider myself an early adopter. It just makes sense. Obviously SSD drives aren't as "mature" as our beloved platter drives, but they're not exactly brand new technology either.

      --
      This author takes full ownership and responsibility for the unpopular opinions outlined above.
    9. Re:What I really want to know by Anonymous Coward · · Score: 0

      Problem with that - Windows.

      Treating the SDD as an SDD, and letting the OS do it's own wear levelling, would require operating system support. It would likely also require a different filesystem. Microsoft would have to support this in a future version of Windows. Hardware manufacturers are not going to wait for Microsoft to catch up, and their hardware has to work with OSes available right now. So they have no choice in the matter.

    10. Re:What I really want to know by MichaelSmith · · Score: 1

      The SSD on my eeepc has similar read speeds to a laptop hard disk but read times are more consistent because there is no waiting for head and platter seek. This makes it seem faster to me.

    11. Re:What I really want to know by Anonymous Coward · · Score: 0

      Fuck that. You can "upgrade it later when things like this come out" through firmware updates. Thats kindof the whole point of the article (the performance changes from adding TRIM support through a firmware update and a utility since the OS doesn't support it yet). God forbid we RTFA though.

      If OS support vs Silicon support would result in problems similar to USB vs Firewire (in addition to using system resources that dont need to be used) it's not worth the potential portability or updateability.

    12. Re:What I really want to know by gad_zuki! · · Score: 3, Insightful

      No way, lets have the firmware do this. The problem with your approach is that the OS wont understand the drive as well as the manufacturer does, so it will always be a sub-optimal solution. Dont tie the hands of the manufacturer to put intelligence in his drives. For instance, the best way to wipe a disk is via an ATA command, and not through multi-passes of wipes. The manufacturer knows where the heads are and how the drive writes. The SSD situation is somewhat similar.

    13. Re:What I really want to know by RiotingPacifist · · Score: 1

      since when has ext been the best choice for anything, ext has always been about balance i doubt its the best choice for SSD, Id put my money on a log filesystem, e.g you couldn't be more wrong and GP is correct because NILFS2 will write to used blocks much less often than conventional systems. OFC ext will be better than FAT because file-allocation table block is going to be a problem and it turns out ext4 with COW will also be good (but not as good as a log system and the journal itself will be a problem)

      --
      IranAir Flight 655 never forget!
    14. Re:What I really want to know by complete+loony · · Score: 1

      Yes and No.

      The linux kernel's recent UBIFS flash support is I believe separated into 2 distinct layers. There's a layer for logical to physical address translations with wear-leveling and free space tracking (UBI). And a separate layer for organising the storage of the filesystem within those used blocks while keeping stored data in block sizes that match the underlying physical media and re-writing the whole block at once.

      I think that kind of abstraction is useful enough for the OS, potentially with the UBI layer provided by a hardware device.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    15. Re:What I really want to know by Ilgaz · · Score: 1

      It is all NTFS'es fault. Impossible to turn off journaling, OS doesn't move journal etc.

      On HFS+ , journal is also an ordinary file and backwards compatible. In fact theoretically, OS X can even journal FAT if it wanted to.

      So, if you turn off journaling, half (or more) of the potential problem is gone. First, there won't be a journal in some area being written over and over. Second, OS X won't enable "hot band" function which puts the most accessed files (hot files) to beginning of disk, a specific area in many strict and fail safe conditions. It won't dare to move files on the fly if journaling is not enabled and hot band makes no sense on SSD anyway. It even erases hotfiles.btree (the database) right when journaling is disabled.

      I have a feeling that the issue is mostly a Windows issue, because of the filesystem. How come we never hear horror stories from "Macbook Air" owners who preferred SSD? Could we be arguing something which ActiveWin etc. guys argue about?

    16. Re:What I really want to know by benow · · Score: 1
      Yes, the speedup is dramatic. The random access and multi-threaded speedup play a large role, and are left out of many comparisons. MLC and a good interface make a difference, certainly, but the major speedup is from random access.

      Lots of RAM and an SSD will make a box fly.

    17. Re:What I really want to know by code4fun · · Score: 1

      I thought wear leveling was already being done by the SSD hardware? It is for Compact Flash. There is a little controller inside the CF that manages the NAND flash chip(s) and handles the wear leveling transparently. SSDs will put all those disk repair software out of business. ;-)

    18. Re:What I really want to know by SanityInAnarchy · · Score: 1

      The problem with your approach is that the OS wont understand the drive as well as the manufacturer does, so it will always be a sub-optimal solution.

      The problem is, we currently have a sub-optimal solution, for just that reason -- the manufacturers make assumptions, even regarding things like FAT size and location, when tuning the performance of these drives.

      We're adding hack upon hack upon hack -- the OS will have some sort of defragmenter, and will attempt to avoid fragmentation, just as the device is deliberately scattering writes throughout the disk.

      If we want to let the drive provide some sort of BIOS-like scheme -- wherein some code (appropriately sandboxed) is included in the drive, and executed by the CPU -- I'm all for that. But let's design it with an eye towards what this device actually needs to do, rather than making it pretend to be a hard drive.

      --
      Don't thank God, thank a doctor!
    19. Re:What I really want to know by SanityInAnarchy · · Score: 2, Informative

      Not true at all -- that's why I mentioned a BIOS.

      I'm pretty sure even Windows is smart enough to just use the BIOS-provided access, if it doesn't have a driver. If it does, provide it in a driver.

      It would likely also require a different filesystem.

      Nope. You can do exactly the same pretend-it's-a-hard-drive approach, until additional filesystems are developed. And there's nothing preventing a third party from developing a filesystem for Windows.

      Again, see the BIOS approach. In fact, look at nVidia's fakeraid -- software RAID done with BIOS support and a Windows driver. This is neither a particularly new idea, nor a particularly difficult one, especially if you're preinstalling.

      Hardware manufacturers are not going to wait for Microsoft to catch up

      Indeed. But I don't want to wait for both Microsoft and the hardware manufacturers to catch up.

      --
      Don't thank God, thank a doctor!
    20. Re:What I really want to know by SanityInAnarchy · · Score: 1

      I would say, disabling journaling is a bad idea. You want a wandering log, or just a log-based filesystem, or soft updates.

      You don't want to go back to the days of having to fsck after crashes.

      --
      Don't thank God, thank a doctor!
    21. Re:What I really want to know by SanityInAnarchy · · Score: 1

      Way to completely miss the point.

      Yes, wear leveling is done by the SSD itself, which is a total waste. The OS already has to do allocation; there's no reason a filesystem can't do wear leveling, too, and several Linux filesystems do.

      There's also the block size itself, and the fact that the OS is optimized to place things sequentially, which is completely pointless -- especially if it tries to defrag -- when the device is an SSD.

      And no, it won't put repair software out of business. If anything, it'll generate more business -- some SSDs go into read-only mode when they can't write, but some just stop working altogether, meaning if you want your data back, you now have to pay someone to take apart the drive and recover it for you.

      That, and with people disabling journals to get more performance and a longer lifetime, we're back to the old problem of OS crash or power pulled could mean a corrupt filesystem.

      --
      Don't thank God, thank a doctor!
    22. Re:What I really want to know by Ilgaz · · Score: 1

      Well, I am assuming these things hates data written over and over to same spot. It is obvious that journal moves from time to time but I don't think it is enough, I don't know the exact reason of "journal pointers have been reset!" message either.

      Trust me, for a consumer laptop which is good enough to consider SSD, fsck_hfs doesn't take that long. Of course, with journaling it would be a lot better but they are adopting early, not my fault :) In fact, an updated OS X without root level running hacks or outdated drivers rarely crashes to a point to require disk checking.

      Another thing is, based on my experience, the real time taking process of fsck_hfs happens because of mechanical movements, if you have access to OS X machine or can read man pages from web, check the "cache" setting (exclusive to fsck_hfs) which Apple defaults to almost funny low level. If you raise it to 512MB or even 1Gigabyte, almost no head movement occurs and it becomes even faster than commercial tools. SSD obviously has no head to move so the results can be surprising.

    23. Re:What I really want to know by Ilgaz · · Score: 1

      I tested Windows 7 RC on a Mac Mini just 2 days ago, for 24 hours.

      Microsoft is really, really interesting company. While entire industry talks about SSD and even Disk Defragmenter producing (and ethical) companies tell their customers "Do not defragment SSD drives", Windows 7 defaults to weekly defrag, without even asking to user.

      It is a release candidate, coded and packaged in 2009. It is not "windows 2000" or something. Their users already live problems because of NTFS and they decide to weekly defrag, on behalf of user and they even promote defrag in various places inside UI.

        I always said "defragmenting can do good in certain conditions" (and get flamed) but I have never imagined of a OS vendor suggesting all users to take risky step of defragmenting. Forget everything, it puts huge load to the drive mechanics and they don't even watch smart temperature. Laptop drives are already running hot and loaded.

    24. Re:What I really want to know by zdzichu · · Score: 1

      In Linux TRIM commands are issued by ext4 and btrfs. Btrfs also have two SSD modes for allocator, but is not meant for production now. There are probably other linux filesystem issuing TRIM, as it's implemented few kernel releases ago.

      --
      :wq
    25. Re:What I really want to know by Hal_Porter · · Score: 1

      I do like they way you stir -1 flamebait into +1 technically vaguely plausible to confuse the moderators.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    26. Re:What I really want to know by Hal_Porter · · Score: 1

      MILFs has a issue for long term use though. When you first use it is very trim and has little overhead and is highly responsive. Later on it gradually bloats to the point it is unusable and/or spends its time servicing requests from other systems and ignoring you. Then you pretty much have to waste it and replace it with Reiser.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    27. Re:What I really want to know by CyberDragon777 · · Score: 2, Informative

      FYI Windows 7 disables defragmenting on SSD drives.

      The automatic scheduling of defragmentation will exclude partitions on devices that declare themselves as SSDs. Additionally, if the system disk has random read performance characteristics above the threshold of 8 MB/sec, then it too will be excluded. The threshold was determined by internal analysis.

      Support and Q&A for Solid-State Drives

      --
      We both said a lot of things that you are going to regret.
    28. Re:What I really want to know by Muad'Dave · · Score: 1

      IIRC, Linux does not use the BIOS at all once booted - that's what it's doing poking around on all those buses discovering hardware during startup.

      --
      Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
    29. Re:What I really want to know by Anonymous Coward · · Score: 0

      NILFS

      .. STD? MILFS? Too many acronyms, it's all so confusing.

    30. Re:What I really want to know by sjames · · Score: 1

      Again, see the BIOS approach. In fact, look at nVidia's fakeraid -- software RAID done with BIOS support and a Windows driver. This is neither a particularly new idea, nor a particularly difficult one, especially if you're preinstalling.

      No OS has actually used the BIOS for I/O for a very longgggggg time. It's just too slow and too crappy to contemplate.

      The BIOS part of the fakeraid goes away once the OS loads. The driver does all the work. In Linux, because it already has a well tested RAID driver, the objective with fakeraids is to make it look like a JBOD.

      That's why it's being done in the drive firmware. It's the drive's job to make itself look like a contiguous array of blocks identified by a single index value. The TRIM command is an advisory message that the OS is no longer interested in the contents of a particular block. Spinning meda won't care since overwriting data takes no longer than writing over an empty block (since TRIM is advisory, the drive isn't obligated to do anything in response to it). SSDs will be greatly interested so they can potentially pre-erase flash sectors so that the next write will be faster.

      It would be possible to support letting the OS do it's own management by defining a mode switching command. It will also be necessary to define commands for the OS to find out the layout of erase sectors on the flash. The question is WHY. It's not likely to buy you anything that the TRIM command plus firmware on the drive doesn't already do.

    31. Re:What I really want to know by atamido · · Score: 1

      The problem with your approach is that the OS wont understand the drive as well as the manufacturer does, so it will always be a sub-optimal solution.

      Do you have numbers to back this up with? I'd like to see a comparison of speed from common flash file systems and an SSD running EXT4. It can't be that hard to compare the two. It should be significantly cheaper to develop a controller to present RAW flash instead of the virtualized interface currently used.

    32. Re:What I really want to know by atamido · · Score: 1

      Where would you buy a RAW flash SATA drive to use a file system designed for flash?

    33. Re:What I really want to know by atamido · · Score: 1

      the OS should be able to do its own wear leveling.

      I agree, but where does one get a RAW flash device with a SATA interface? You would think they would be cheaper as no fancy controller needs to be developed, but I can't find one anywhere.

    34. Re:What I really want to know by Wesley+Felter · · Score: 1

      There aren't any and won't be any because the Linux market is too small.

    35. Re:What I really want to know by SanityInAnarchy · · Score: 1

      Well, I am assuming these things hates data written over and over to same spot.

      Somewhat, but it can wear-level that anyway. What I would assume it hates is tiny amounts written over and over, rather than larger chunks.

      Trust me, for a consumer laptop which is good enough to consider SSD, fsck_hfs doesn't take that long.

      It's not just about the length of time, it's about the possibility of corruption. FSCK is basically trying to recover after corruption has occurred. Journals prevent corruption from occurring in the first place.

      --
      Don't thank God, thank a doctor!
    36. Re:What I really want to know by SanityInAnarchy · · Score: 1

      No OS has actually used the BIOS for I/O for a very longgggggg time. It's just too slow and too crappy to contemplate.

      I'm curious why, but ok.

      The BIOS part of the fakeraid goes away once the OS loads. The driver does all the work.

      What I'm curious about is why it couldn't use the BIOS if no driver was provided. And if a driver is provided, hey, problem solved.

      That's why it's being done in the drive firmware.

      So... It's really easier to develop firmware, and a bunch of extra controller logic, than a cross-platform driver? Really?

      The question is WHY. It's not likely to buy you anything that the TRIM command plus firmware on the drive doesn't already do.

      The answer is, because the OS can already do these things, and it removes a whole layer of complexity -- not to mention wholly unnecessary hardware.

      It's like hardware RAID. Faster, for now, and more compatible, maybe. Also way less flexible, more moving parts to fail, and things you actually can't do with it.

      As an example: If the OS is doing wear-leveling, a new write to a given chunk of a file is going to go to a new location on disk. The filesystem could potentially remember the old location, and not pre-erase it, but actually be able to rewind to that point, if needed, until something else overwrites it.

      Yes, you can do a log-based FS on top of the firmware, but now you're basically implementing the same logic on top of that -- write everything to the end of the disk, ultimately recover unused spaces near the beginning -- as I understand it, this is ideal behavior for wear-leveling. Why implement it twice?

      I suppose it frustrates me for the same reason virtualization frustrates me. It has the same feel as creating a file, then pretending that's a block device, so that the virtual machine can run its own filesystem on top of it -- and for what? Mostly, so you can give people "root" access, while restricting them to a sandbox. Tools like chroot -- and, ultimately, BSD Jails -- should be able to do this job -- there's no reason you shouldn't be using some directory on the host filesystem.

      Yet we add this extra layer of wasteful cruft, to avoid having to do some hard engineering.

      --
      Don't thank God, thank a doctor!
    37. Re:What I really want to know by code4fun · · Score: 1

      Well, everyone is entitled to their own opinion. I, for one, prefer it to be a hardware function. That could be from previous bad experience with software based wear leveling back in the old days.

      The other issue I have with software doing wear leveling is the added processor overhead incurred. This may not matter for modern day desktop systems, but it still a burden for embedded devices.

    38. Re:What I really want to know by SanityInAnarchy · · Score: 1

      I, for one, prefer it to be a hardware function. That could be from previous bad experience with software based wear leveling back in the old days.

      And others have had bad experiences with hardware based wear leveling.

      The difference is, put it in the OS, and it can actually be patched. Put it in the firmware, and it can theoretically be patched, but probably only by the manufacturer.

      The other issue I have with software doing wear leveling is the added processor overhead incurred. This may not matter for modern day desktop systems, but it still a burden for embedded devices.

      For an embedded device, I can understand throwing another processor on there to do this -- because that's basically what you're advocating. But I'm still skeptical -- is the power draw from all that extra circuitry inside the SSD, worth the power savings by using just a little bit less CPU?

      --
      Don't thank God, thank a doctor!
    39. Re:What I really want to know by sjames · · Score: 1

      No OS has actually used the BIOS for I/O for a very longgggggg time. It's just too slow and too crappy to contemplate.

      I'm curious why, but ok.

      Because BIOS routines are still written for real mode. At the very least, making a call to a BIOS I/O routine would require reloading the segment registers, make the call, then load them again. In the process, you'll end up flushing the cache. It's a huge performance killer.

      Beyond that, all modern commercial BIOS are a dreadful mess filled with binary patches and cruft. Rumor has it (and I believe it based on disassembly) that some parts are considered untouchable because the last person who understood it has died and any changes seem to screw up everything.

      In any event, the goal of the BIOS routines is to be very generic and work most of the time. Speed isn't even a consideration since it's only used long enough to load the bootloader.

      You do NOT want to rely on the BIOS for any more than you absolutely have to!

      So... It's really easier to develop firmware, and a bunch of extra controller logic, than a cross-platform driver? Really?

      Ever looked at the code for a "cross platform" driver? Usually it's a disaster even if it only has to support a single architecture. I'd hate to see one meant to run on any OS and any CPU. The drive controller, etc are a decentish place to hide their valuable IPee and maintain a well defined and well understood interface that's already supported everywhere. You can get an IDE controller for practically any platform. I don't think you can even buy a mainboard that doesn't have one.

      Compared to the effort required to get a new hardware spec everywhere, adding a simple advisory command to ATA is simplicity itself.

      Meanwhile, it's not like you could get rid of glue logic anyway. Flash memory doesn't run at FSB speeds. The flash itself already has a built in state machine anyway. Speaking of which, you don't want the CPU twiddling it's thumbs waiting for that state machine to complete an erase operation (very slow). Issuing a TRIM command is fire and forget.

      Mostly, so you can give people "root" access, while restricting them to a sandbox. Tools like chroot -- and, ultimately, BSD Jails -- should be able to do this job -- there's no reason you shouldn't be using some directory on the host filesystem.

      I should point out that chroot can be trivially broken out of. Jail is tougher, but it's easy to accidentally leave a back door.

    40. Re:What I really want to know by SanityInAnarchy · · Score: 1

      Because BIOS routines are still written for real mode.

      Ew. That seems like something that should be fixed.

      Beyond that, all modern commercial BIOS are a dreadful mess filled with binary patches and cruft.

      That's really not a good reason, considering there is a modern, open source BIOS -- Coreboot, formerly LinuxBIOS. I see no reason vendors couldn't adopt that, and start extending it.

      Usually it's a disaster even if it only has to support a single architecture. I'd hate to see one meant to run on any OS and any CPU.

      nVidia claims something like 90-95% of the code in their video drivers is shared between all platforms.

      The drive controller, etc are a decentish place to hide their valuable IPee

      Bullshit. People have been "hiding" that IP in software, too. If there's a reason for people to reverse-engineer it, they will, anyway.

      and maintain a well defined and well understood interface that's already supported everywhere.

      Well, mostly everywhere. But I can see the appeal, there. It is, however, an interface with some shortcomings...

      On the other hand, that implies the kernel interfaces should be similarly well defined and well understood. How difficult is it to present a Volume under Windows, or a block device under Linux? Consider that FUSE interfaces already exist for Linux and OS X -- surely a POSIX filesystem API is more difficult than a block API?

      I'd have somewhat less trouble with this idea if it was possible to bypass that abstraction layer and use the raw device, for filesystems and OSes that can take full advantage of it. But it's presented as this SATA black box, to which we're slowly starting to add features that were there already on more primitive devices.

      You can get an IDE controller for practically any platform. I don't think you can even buy a mainboard that doesn't have one.

      I'm pretty sure mine doesn't. Most SSDs, including mine, are SATA.

      Meanwhile, it's not like you could get rid of glue logic anyway.

      Fair enough. However, I think this goes beyond the amount of glue logic we want.

      I may have made this analogy before, but it's a bit like hardware RAID. Some slight performance gain that just becomes irrelevant in a generation or two, and older/dumber OSes can pretend it's just a single hard drive. Downsides are, you're paying for extra, unnecessary hardware, the logic in the RAID controller is probably inferior, and the RAID layer really can't talk to the filesystem layer, preventing some of the cooler features of ZFS.

      Speaking of which, you don't want the CPU twiddling it's thumbs waiting for that state machine to complete an erase operation (very slow). Issuing a TRIM command is fire and forget.

      No, but is there a reason the CPU has to? I suppose that depends on the interface used...

      I should point out that chroot can be trivially broken out of.

      True, but that's largely because people never tried to make it into a jail, and instead focused on virtual machines.

      Of course, I'm guessing that you can only really break that jail as root, correct?

      Jail is tougher, but it's easy to accidentally leave a back door.

      The same could be said of any system, including virtualization.

      Really, I think virtualization is a similarly brutal hack, that may be justified by the amount of work it saves, but really, we should just do the work.

      Example: Virtual machines can be migrated from one physical machine to another, without anything inside the VM even noticing. However, LinuxPMI already does this to some extent with individual processes. It's a hard problem, but not impossible.

      And an obvious

      --
      Don't thank God, thank a doctor!
    41. Re:What I really want to know by sjames · · Score: 1

      That's really not a good reason, considering there is a modern, open source BIOS -- Coreboot, formerly LinuxBIOS. I see no reason vendors couldn't adopt that, and start extending it.

      I certainly agree that Coreboot is better, and would be even better still if not for hardware vendors that keep their datasheets and BIOS writer's guides locked up like state secrets.

      That and mainboard vendors silently making undocumented changes to their boards without even a revision number bump are the only reasons I don't sell general purpose systems with Coreboot pre-installed.

      Well, those plus boards with soldered on flash and broken recovery mechanisms like failing to connect the top block swap line etc. Oh how I wish x86 CPUs and mainboards had a nice JTAG debugging/recovery mechanism!

      However, the people designing SSDs have no ability to force that change. They have to play the hand they're dealt, and that includes crufty old BIOS that nobody in their right mind would trust any further than they absolutely have to.

      nVidia claims something like 90-95% of the code in their video drivers is shared between all platforms.

      I don't deny that it can be done, and I certainly haven't seen the source, but it is very probably a real mess to maintain. Certainly the binary blob nVidia driver has a history of creating stability problems in Linux (IIRC, it was a big reason that kernel tainting was introduced, so LKML would have a clear indication that there was no point trying to debug due to the nVidia module being involved).

      Bullshit. People have been "hiding" that IP in software, too. If there's a reason for people to reverse-engineer it, they will, anyway.

      I personally agree with you. And I'll raise you that most of that IP is not actually as amazing as they think it is. But if they're going to insist on hiding it I'd rather they do so behind a very well defined API and protocol fully isolated from my kernel except at that well defined interface. Preferably an interface with a comprehensive pass/fail compliance test.

      The alternative is a binary blob that taints my kernel and potentially scribbles all over RAM.

      Of course, I'm guessing that you can only really break that jail as root, correct?

      Ideally, that's true. However, if two unprivileged users in different chroot jails have any of the namespace in common, they can boost each other out of jail by passing an open directory fd over a unix socket.

      I agree that lighter weight solutions have the potential to be vastly superior to VMs for most applications.

      I even patched a 2.6.18 kernel to make chroot more like jail. That combined with capabilities can even produce a compartment that safely supports a root like account that is useful for many common situations where a VM is often used. There were still some unanswered questions about networking that I need to work out if I ever get the time. The big shortcoming was that there was nothing to keep a compartment from hogging all of the RAM and CPU. I need to revisit that soon, there's been a lot of work on containers in the Linux kernel for the last several versions, so perhaps there's enough there to complete the system now.

      Something Plan 9 like has even more potential in that area.

      It does seem likely that at some point hotplug RAM will be re-invented, even if only in virtual form. Mainframes have been able to deal with that for years now. Some of the MCE work in the kernel is pointing in that direction sort of. Invalidating RAM in the system due to excessive ECC errors means the kernel understands that RAM is not a fixed constant.

    42. Re:What I really want to know by SanityInAnarchy · · Score: 1

      However, the people designing SSDs have no ability to force that change. They have to play the hand they're dealt, and that includes crufty old BIOS that nobody in their right mind would trust any further than they absolutely have to.

      I'm not suggesting that they should replace the BIOS on the mainboard, except perhaps for laptops. But what about things like PXE? Other hardware, including controllers, have been built with a way to at least boot off of them...

      But, I'm probably out of my depth here.

      But if they're going to insist on hiding it I'd rather they do so behind a very well defined API and protocol fully isolated from my kernel except at that well defined interface. Preferably an interface with a comprehensive pass/fail compliance test.

      I would agree with that, but I would still prefer it be done in software.

      The alternative is a binary blob that taints my kernel and potentially scribbles all over RAM.

      It could potentially be just as isolated. That would take some work, though.

      The big shortcoming was that there was nothing to keep a compartment from hogging all of the RAM and CPU.

      I thought there were already mechanisms to provide per-user limits to those?

      --
      Don't thank God, thank a doctor!
  3. fragmentation? by convolvatron · · Score: 1

    can someone explain why fragmentation in the mapping between logical blocks and
    physical addresses causes performance degradation?

    is it an issue with logically sequential reads being spread across multiple pages?

    a multi-level lookup to perform the mapping?

    ?

    1. Re:fragmentation? by Vigile · · Score: 4, Informative

      This older Slashdot post linked in the story links to a story that covers that topic very well: http://www.pcper.com/article.php?aid=669

    2. Re:fragmentation? by sexconker · · Score: 3, Interesting

      Because, basically, flash drives are laid in levels.

      When you delete, you simply map logical space as free.

      If you go to use that free space later, you find that area, and drop shit into it. It's I dunno, a 32 KB block of memory called a page. If the page is full (to the point where you can't fit your new shit) of "deleted" files, you first need to write over those deleted files, then write your actual data.

      If the logical space is full with good, fragmented (with deleted files interspersed) files, you need to read out to memory, reorder the living data and remove the deleted data, add in the full page back.

      Think of it as having a notebook.
      You can write to 1 page at a time, only.

      Page 1 write

      Page 2 write

      Page 3 write

      Page 2 delete

      Page 2 write (still space)

      Page 2 write (not enough space, write to page 4 instead)

      Page 2 delete

      Page 2 write (not enough space, no more blank pages, read page 2 and copy non-deleted shit to scratch paper, add new shit to scratch paper, cover page 2 in white out, copy scratch paper to whited-out page 2)

    3. Re:fragmentation? by cbhacking · · Score: 5, Informative

      Disclaimer: I am not a SSD firmware author, although I've spoken to a few.*

      As best I can understand it, the problem is that writes are scattered across the physical media by wear-leveling firmware on the disk. In order to do this, the firmware must have a "free list" of sorts that allows it to find an un-worn area for the next write. Of course, this unworn area also needs to not currently be storing any relevant data.

      Now, consider a SSD in use. Initially, the whole disk is free, and writes can go anywhere at all. They do, too - you end up with meaningful (at some point) data covering the entirety of the physical memory cells pretty quickly (consider things like logfiles, pagefiles, hibernation data, temporary data, and so forth). Obviously, most of that data doesn't mean anything anymore - to the filesystem, only perhaps 20% of the SSD is actually used, after 6 months. However, the SSD's firmware things that every single part has now been used.

      Obviously, the firmware needs to be able to detect when data on disk gets obsoleted, and can safely be deleted. The problems with this are that this leads to *very* complicated translation tables - logical disk blocks end up having no relation at all to physical ones, and the SSD needs to track those mappings. The other problem is that these tables get *huge* - a typical home system might have between 100K and 1M files on it after a few months of usage, but probably generates and deletes many thousands per day (consider web site cookies, for example - each time they get updated, the wear leveling will write that data to a new portion of the physical storage).

      Maintaining the tables themselves is possible, and when a logical block gets overwritten to a new physical location, the old location can be freed. The problem is that this freeing comes at the same time that the SSD needs to find a new location to write to, and the only knowledge it has about physical blocks which can safely be overwritten is ones where the logical block has been overwritten already (to a different physical location). Obviously, the lookup into the table of active blocks has to be indexed by logical block, which may make it difficult to locate the oldest "free" physical blocks. This could lead to searches that, even with near-instant IO, result in noticeable slowdowns.

      Enter the TRIM command, whereby an OS can tell the SSD that a given range of logical blocks (which haven't been overwritten yet) are now able to be recycled. This command allows the SSD to identify physical blocks which can safely be overwritten, and place them in its physical write queue, before the next write command comes down from the disk controller. It's unlikely to be a magic bullet, but should improve things substantially.

      * As stated above, I don't personally write this stuff, so I may be mis-remembering or mis-interpreting. If anybody can explain it better, please do.

      --
      There's no place I could be, since I've found Serenity...
    4. Re:fragmentation? by Bigjeff5 · · Score: 2, Insightful

      In very simple terms (because I'm no expert), it's because of the way SSDs deal with wear leveling and the fact that a single write is non-sequential. When it writes data, it is writing to multiple segments across multiple chips. It is very fast to do it this way, in fact the linear alternative creates heavy wear and is significantly slower (think single chip usb flash drives) than even spinning disk tech, and so this non-sequential write is essential.

      Now, to achieve this, each chip is broken down into segments, and those segments are broken down into smaller segments, which are broken down into bytes, which are then broken down bits. When the SSD writes, it writes to the next available bit in the next available segment on each of the chips in the drive. Because it keeps track of exactly where it left off, this process is extremely fast, as all new data goes to the next place in line.

      The problem comes when you fill up the hard drive and then delete data. When you delete data, you are deleting little bits spread all over the physical drive. Unless it is a tiny file, every chip will have a little bit of the file. What's worse, unless it was a massive file, you probably wont be clearing whole sequential segments on the drive. To add to that even further, the OS doesn't actually delete anything, it just flags it! So what this means is after you cleared a bunch of room on your hard drive, when writing new data your SSD is still massively fragmented, and to write new data the drive has to find free bits and clear them first. Think worst case scenario for spinning disk fragmentation and that's what you have - and you will get it every single time you fill up an SSD. You can actually re-format the drive and it won't necessarily fix the fragmentation problem, because formating won't reset the segments on the chip to factory state and update the internal drive index in such a way that it maximizes speed again.

      Now, because the SSD is sort of like a very large RAID array with very tiny disks, even in this state is still faster than a conventional spinning-disk hard drive. But it is nowhere near as fast it was when it was clean and new.

      Thus, the TRIM functions that have been mentioned. Basically these go through and do a de-frag of the data, which requires maximising the space at the "back" of each chip, then re-setting those free segments to the factory state. Depending on how much needs to be moved, this can have wear concerns, so you don't really want to do this all the time. The idea with SSDs is to fill them all the way up, then clear out as much room as you possibly can before trimming the drive. Once trimmed the drive should be back to pre-fragmentation speeds, but you have also just written many more times to some bits on the drive than others, which raises wear concers if the process has to be repeated too many times.

      --
      Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
    5. Re:fragmentation? by complete+loony · · Score: 1

      When you delete data, you are deleting little bits spread all over the physical drive.

      The biggest problem is that a delete in most filesystems simply marks the space in the index on the device as free. However most filesystems leave the deleted data in place without writing anything over the top until that space is re-allocated. Hard disks don't typically need to know which sectors of the physical storage are actually in use. If you tell an SSD that this block is no longer required it can start erasing the physical chips and add them to the internal free list ready for the next data to be written.

      Ideally filesystems will need to be modified so they are aware of the different characteristics of SSD's.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    6. Re:fragmentation? by iluvcapra · · Score: 5, Funny

      If you go to use that free space later, you find that area, and drop shit into it.

      Knock it off with all the fancy jargon!

      --
      Don't blame me, I voted for Baltar.
    7. Re:fragmentation? by aztektum · · Score: 5, Informative

      For a thorough (RE: long) primer on SSDs and long term performance woes, Anand's overview is a must read.

      --
      :: aztek ::
      No sig for you!!
    8. Re:fragmentation? by ls671 · · Score: 3, Interesting

      Very interesting, I assumed the problem was similar to fragmentation and wondered why nobody compared it as such.

      Now, your explanation makes things much more clearer, the global problem is amplified by the additional problem you described.

      Now would implementing the logic to control the SSD entirely at the OS/FS level be much slower than implementing it in silicon in the SSD itself ?

      As you said, I now understand that the OS/FS would now have to be aware of the underlying media ;-)

      --
      Everything I write is lies, read between the lines.
    9. Re:fragmentation? by Anonymous Coward · · Score: 0

      The problem is not the indexing, or the tables keeping track of where everything is, no matter how massive they may become. It's that simply deleting data in FLASH memory does not make that area available immediately.

      SSD's use FLASH memory. "Empty" FLASH memory contains all 1's. When you write data to "empty" FLASH memory, you write 0's where they are needed, and leave the 1's alone.

      As somebody else mentioned, when the system needs to modify data, it simply marks the old data as deleted and writes the new data to a fresh location. Very fast.

      The problems start when you are out of fresh locations. You cannot write 1's to FLASH memory, you can only write 0's. So if you want to reuse a deleted location, you must first "erase" it and set it back to all 1's, so you can then write 0's where they need to be.

      But FLASH memory cannot be erased one byte at a time, or even a few bytes at a time. When you erase FLASH memory, you must erase a minimum of an entire page. Pages are typically some multiple of 256 bytes.

      After you have used your FLASH memory for a while, there will be no pages that are completely unused. So if you want to re-use some deleted bytes in a page, you need to read the page into RAM, erase the page, incorporate the new data into the RAM copy, then write the page back out to FLASH.

      Biggest problem of all: Erasing FLASH is S-L-O-W. Doing these read-erase-write gymnastics in an on-demand fashion is horribly inefficient.

      New algorithms, either in the FLASH firmware, or in the OS file system, can continuously scan the pages in a FLASH memory and systematically defrag the system, putting the live data together into common pages, leaving other pages completely deleted. This is a bit of a performance hit if you happen to need live data at the moment it is being moved (but the hit is orders of magnitude better than defragging a rotating media, which by definition means that at any given time the R/W head is anywhere but where you need it to be).

      The pages that are entirely deleted can be erased in the background with zero performance impact. And ideally there are then always free pages available and nobody has to wait for something to open up.

    10. Re:fragmentation? by sootman · · Score: 2, Interesting

      Obviously, the firmware needs to be able to detect when data on disk gets obsoleted, and can safely be deleted. The problems with this are that this leads to *very* complicated translation tables - logical disk blocks end up having no relation at all to physical ones, and the SSD needs to track those mappings.

      Would it solve the problem (or, I guess I should say, remove the symptoms... for a while, at least) to do a full backup, format the SSD, and restore? I know it's not an ideal solution but rsync or Time Machine would make it pretty painless.

      Also, if I had an SSD and was browsing a lot I could see making a ramdisk for things like browser cache files. Too bad Safari and Firefox don't seem to let you specify where you want your cache to be anymore, like old browsers used to. I guess you could make a symlink or something but then you'd HAVE to have that drive mounted.

      --
      Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
    11. Re:fragmentation? by Bigjeff5 · · Score: 1

      It might ease the problem, but it wouldn't solve it. The controller on the drive needs to clear the pages and re-set everything back to zero, it doesn't do that with just a format as far as I am aware. You'd need a format -and- a trim to get it back to like-new speeds.

      I like your idea for ramdisks and cache though.

      --
      Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
    12. Re:fragmentation? by 42forty-two42 · · Score: 2, Informative

      The problem isn't scanning metadata - the problem is relocating data prior to an erase. Flash memory is built into erase blocks that are quite large - 64k to 128k is typical. You can write to smaller regions, but to reset them for another write you have to pave over the neighborhood. However the OS is sending writes at the 512-byte sector granularity. So the drive has to essentially mark the old location for the data as obsolete, and place it somewhere else.

      When the drive has been used enough, however, it may have trouble finding an empty, erased sector to write to. So it has to erase some erase block. But if all erase blocks still have good data (eg, each has half used, important data and half obsolete, overwritten data), you need to relocate some of that data elsewhere.

      What the trim command does is tell the drive that it need not preserve the data of a given sector - otherwise, if you were to delete a file, the drive would still have to preserve its data each time one of these relocation operations occur, since it doesn't know anything about the filesystem's allocation maps. By using TRIM, the drive is aware of what data is deleted, and can thus be discarded when it's time to erase blocks. It also increases the percentage of truly unused flash sectors, increasing the probability that a write can go through without having to wait for a relocation.

      Note that this is completely independent from filesystem fragmentation - indeed, a defrag can even make things worse, by making the flash drive think both old and new locations for some data need preserving.

    13. Re:fragmentation? by 7+digits · · Score: 5, Informative

      Once upon a time, a technical subject on /. gave insightful and informative responses that were modded up. Time changes, I guess.

      The "fragmentation" that SSD drive have don't really come from wear leveling, or from having to find some place to write things, but from the following properties:

      * Filesystems read and write 4KiB pages.
      * SSD can read many time 4KiB pages FAST, can write ONCE 4KiB pages FAST, but can only erase a whole 512KiB blocks SLOWLY.

      When the drive is mostly empty, the SSD have no trouble finding blanks area to store the 4KiB write from the OS (he can even cheat with wear leveling to re-locate 4K pages to blank spaces when the OS re-write the same block). After some usage, ALL THE DRIVE HAVE BEEN WRITTEN TO ONCE. From the point of view of the SSD all the disk is full. From the point of view of the filesystem, there is unallocated space (for instance, space occupied for files that have been deleted).

      At this point, when the OS send a write command to a specific page, the SSD is forced to to the following:

      * read the 512KiB block that contain the page
      * erase the block (SLOW)
      * modify the page
      * write back the 512KiB block

      Of course, various kludges/caches are used to limit the issue, but the end result is here: writes are getting slow, and small writes are getting very slow.

      The TRIM command is a command that tell the SSD drive that some 4KiB page can be safely erased (because it contains data from a delete file, for instance), and the SSD stores a map of the TRIM status of each page.

      Then the SSD can do one of the following two things:

      * If all the pages of a block are TRIMed, it can asynchronously erase the block. So, the next 4KiB write can be relocated to that block with free space, and also the 127 next 4KiB writes.
      * If a write request come and there is no space to write data to, the drive can READ/ERASE/MODIFY/WRITE the block with most TRIMed space, which will speed up the next few writes.
      (of course, you can have more complex algorithms to pre-erase at the cost of additional wear)

    14. Re:fragmentation? by Anonymous Coward · · Score: 2, Informative

      browser.cache.disk.parent_directory

    15. Re:fragmentation? by rdebath · · Score: 1

      Yes this would work very well.

      BUT. you MUST tell the drive you've done this, with the previous drives the only way is to use the drive's secure erase command to wipe the drive.

      With these new drives you could just TRIM all the free space occasionally.

    16. Re:fragmentation? by lagfest · · Score: 1

      probably not. but neither OS vendors nor SSD manufacturers would want that.

      There's no backwards compatibility, SSD vendors have to write drivers for every OS, and so on.

    17. Re:fragmentation? by ls671 · · Score: 1

      Well, my understanding is too fresh to judge the case but based on experience; standard interfaces usually emerge after a period of, say, 10 to 20 years after the raw technology with proprietary drivers emerges.

      Please correct me if I am wrong but wasn't this the case for hard drives ?

      Of course, the technology has to last that long for standards to emerge. ;-))

      --
      Everything I write is lies, read between the lines.
    18. Re:fragmentation? by metacell · · Score: 1

      Would it solve the problem (or, I guess I should say, remove the symptoms... for a while, at least) to do a full backup, format the SSD, and restore?

      I think it would alleviate the problems for a while, provided you do a low-level reformat on the SSD. The unused blocks would be marked as unused by the SSD until each of them had been overwritten once. (Which unfortunately happens pretty quickly, because of the wear level balancing.)

    19. Re:fragmentation? by sjames · · Score: 1

      In a nutshell, the page size of the flash is larger than the logical sector size, but flash can only erase whole pages at a time (and erase isn't a fast operation). So when blocks get re-written, the old content doesn't go away by default. Instead, the logical to physical mapping is changed to point to an already blank area and the old content is marked for reclaimation.

      When the last logical block in a page is invalidated, then the page can be scheduled to be erased and returned to the available list.

      The catch in all of this is that the accounting information is ALSO stored in flash. That would be a complete showstopper except that with flash, a bit can always be written from a 1 to a zero (it's the 0->1 transition that requires an erase). Updating the accounting information doesn't require an erase then write sequence, you just leave a pointer as all ones to signify that this is the current data. To update, choose another page, write the data there and then write it';s address into the pointer. The catch is that now in order to locate the current status, you read the head of the chain and follow the pointer. Repeat until the pointer is all ones. All of that indirection takes time.

    20. Re:fragmentation? by fimbulvetr · · Score: 2, Insightful

      It's extremely unfair to link to the print version of that article. Anand put an immense amount of time into that (and everything before it!) and scarred quite a few bridges to bring it to light for his readers - there are very, very few reviewers out there that would do that for their readerbase. The least you could do is offer him and his site _some_ respect.

    21. Re:fragmentation? by fimbulvetr · · Score: 1

      Whoops! Sorry, wrong post!

    22. Re:fragmentation? by fimbulvetr · · Score: 1

      (Originally replied to wrong poster, now modified to prevent "This exact comment has already been posted. Try to be more original... ")
      It's extremely unfair to link to the print version of that article. Anand put an immense amount of time into that (and everything before it!) and scarred quite a few bridges to bring it to light for his readers - there are very, very few reviewers out there that would do that for their readerbase. The least you could do is offer him and his site _some_ respect.

    23. Re:fragmentation? by sexconker · · Score: 1

      A more serious and in depth description of it.

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

    24. Re:fragmentation? by afidel · · Score: 1

      If a write request come and there is no space to write data to, the drive can READ/ERASE/MODIFY/WRITE the block with most TRIMed space, which will speed up the next few writes.

      I believe that is exactly the wrong strategy, if 15/16 4KB 'sectors' in a 256KB block are TRIMMED you would NOT want to use that block as the one to overwrite because it will soon be freed and can be background erased.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    25. Re:fragmentation? by 7+digits · · Score: 1

      > I believe that is exactly the wrong strategy, if 15/16 4KB 'sectors' in a 256KB block are TRIMMED you would NOT want to use that block as the one to overwrite because it will soon be freed and can be background erased.

      (Note: there is not 16 4KiB pages in 256K, but 64)

      Depends on what the metric for success is, in particular how do you weight in the cost of wear versus the write performance.

      The downsides of your strategy are as follow:

      * You will wear the disk a bit faster (you are going to ERASE blocks a bit more often, as the block you are erasing will contain less free pages)
      * You will get a worse throughput if you write a big file, because you are going to ERASE more blocks, with no TRIM intervening.

      On the upside, you maybe get a better throughput if there are a lot of simultaneous write/delete on a disk with mostly free space.

      As I said in my original post, you can have a lot of different algorithms. For instance, you can also relocate a page that is the only one in its block into a free page, to be able to asynchronously ERASE the block. You'll add a little wear, but will always have blocks available... You could use a dynamic watermark under which you relocate content and ERASE the block. Everything is possible, with very different performance metrics on different benchmarks.

    26. Re:fragmentation? by snadrus · · Score: 0

      I understand it more like Virtual Machine's "Dynamically allocated hard drive" problem.

      There, you can create many files, then delete them, but the virtual machine just knows where you've written and must keep that allocated.

      Some have improved by looking in to that drive's format (NTFS only) and seeing what is no longer used, then cleaning it off the "real" drive. They call that "defrag" as well.

      On a side note, would this help VMs keep hard drive space down? If so, 100% drives for all of them. Set it & forget it.

      --
      Science & open-source build trust from peer review. Learn systems you can trust.
    27. Re:fragmentation? by sootman · · Score: 1

      I'm a couple point versions down, but I don't see that option in FF 3 on OS X or Windows.

      --
      Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
    28. Re:fragmentation? by badkarmadayaccount · · Score: 1

      Reminds me of defragmentation techniques for NT 4. Backup to tape, restore. ROFLMAO

      --
      I know tobacco is bad for you, so I smoke weed with crack.
  4. High failure rate by JO_DIE_THE_STAR_F*** · · Score: 0, Troll
    I've heard that the failure rate on SSD's can be as high as 20%. As I am to lazy to google this or even RTFA I am wondering if this is true. If it is true then adoption rates are going to be very low and this technology may never takeoff before something new and better comes around. Of course even if it isn't true than there is still the perception by a lot of (Ignorant) people (like me) that there is a high failure rate so adoption will still be very slow

    [perceived] Bottom line SSDs don't work well so, let's just wait until something better comes along.

    Also doesn't one of the hardware manufactures (Samsung I think) have a patent on SSD so no one else can make the drives any way. Proprietary == Dead

    1. Re:High failure rate by Darkness404 · · Score: 3, Informative

      What in the world are you talking about? The nice things about SSDs is that yes, they do fail, but they fail (or are supposed to) in a predictable, non-catastrophic way that leaves the data readable just not writable. I have had two SSDs and haven't had either fail despite heavy usage, and I don't think you could patent SSDs because the technology is everywhere because it is flash memory and even if it is patented more companies make them than just one.

      --
      Taxation is legalized theft, no more, no less.
    2. Re:High failure rate by Anonymous Coward · · Score: 0

      Proprietary == Dead

      Yes, because NOBODY is going to buy a hard drive that runs at a speed equivalent to 35,000 RPM just because its proprietary.

    3. Re:High failure rate by vadim_t · · Score: 4, Insightful

      That's a statistic that doesn't make any sense.

      20% under what conditions, and in what timeframe? Over a long enough time period everything has a 100% failure rate.

      Normal hard disks also will eventually fail, due to physical wear.

      Also if it lasts long enough, at some point, reliability will stop being important. Even if it still works, very few people will want to use a 100MB hard disk from 15 years ago.

    4. Re:High failure rate by Bigjeff5 · · Score: 2, Insightful

      I've never heard of a 20% fail rate for SSDs. I've heard of wear concerns, as each little bit on the drive can only be written a set number of times (it's at 10,000 or so, if I remember correctly). However, thanks to the majic of wear leveling and the large amount of separate chips in an SSD drive, you can fill up your drive completely and you will have only written to each bit exactly once. That means you could theoretically fill your SSD up 10,000 times before you would expect failure. Reality is a bit lower than that, maybe 3,000-5,000 times due to having to TRIM to re-arrange the bits, but it's still significant.

      Of course, even with the performance hit TFA talks about after filling your SSD (which is fixed with the TRIM function TFA also talks about) the fastest spinning disks are still much much slower than all but the very worst SSDs out there.

      Anyway, the 20% fail rate may have been a specific manufacturer of SSDs, there are already some really shitty ones out there.

      Lastly,

      Also doesn't one of the hardware manufactures (Samsung I think) have a patent on SSD so no one else can make the drives any way. Proprietary == Dead

      You may need to get some more education about how patents work, because if that were true IBM would not have the fastest SSD on the markent. See, they do this thing called licensing, which basically means company Y purchases an agreement from company X to use their technology to manufacture a product. It creates an incentive for company X to allow other manufacturers to use their technology, flooding with the market with both quality and crap, but ultimately lowering the price and speeding innovation regardless of the high quality stuff (and improving the quality of the cheap stuff, it works both ways usually).

      It's actually the reason patents exist. We only get in a fuss when people patent stuff that either a.) should never need a patent (which means the patentor can sue for damages for infringement) or b.) some company goes around buying patents from legitimate inventors for the sole purpose of hoping said patents become infringed upon by an unwitting third party. The former is a failure in the patent system, and the latter is patent trolling, which is an unethical and disgusting abuse of the process.

      --
      Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
    5. Re:High failure rate by macraig · · Score: 4, Insightful

      Just a small tangential nitpick: we were already more than a factor of ten past that HDD capacity fifteen years ago. The 1GB barrier was broken very early in the Nineties. I still have an HP 1GB SCSI drive from about '91 or '92, IIRC.

      As far as failure rates go, I still have ALL of my disk drives (one or two outright failed) from the 15-20 years, and every single one of them still functions at least nominally. I'm still more trusting of magnetic media than I am either rewritable optical or Flash-based media.

    6. Re:High failure rate by fractoid · · Score: 1

      I've heard that the failure rate on SSD's can be as high as 20%.

      As Heinlein put it wonderfully in 'Tunnel in the Sky':

      The death rate is the same for us as for anybody ... one person, one death, sooner or later. - Cpt. Helen Walker

      --
      Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
    7. Re:High failure rate by MichaelSmith · · Score: 1

      I've heard that the failure rate on SSD's can be as high as 20%.

      As Heinlein put it wonderfully in 'Tunnel in the Sky':

      The death rate is the same for us as for anybody ... one person, one death, sooner or later. - Cpt. Helen Walker

      Except Lazarus Long of course.

    8. Re:High failure rate by Anonymous Coward · · Score: 0

      Let me see if I can parse this:
      "I still have ALL of my disk drives (one or two outright failed) from the 15-20 years,..."

      Ok, I will interpret this "ALL" as including the "(one or two outright failed)" units. I think most people reading this will make the same interpretation.

      "...and every single one of them still functions at least nominally"

      So, "every single one of them" refers to the disk drives in the first part of the sentence, which includes the "(one or two outright failed)" units. So, you are claiming that units that have "outright failed" still function "at least nominally."

      I knew drive manufacturers like to stretch terms and definitions to trump up reliability, but this is a bit ridiculous. If you can really make statements like the above with a straight face, you should get a job with one of the HDD manufacturers, if you have not already.

      Even if your sentence is interpreted slightly differently, the second part refers to the drives that have not failed and you are making the awesome claim that 100% of the drives that have not failed are still functional. Wow! That's amazing because I have the exact same results.

    9. Re:High failure rate by macraig · · Score: 1

      You missed the point, which was that the MEDIA ITSELF in those drives has not degraded significantly over all that time. That is not the case with either Flash RAM nor optical media, for both of which it's the MEDIA ITSELF that is the point of failure.

    10. Re:High failure rate by Anonymous Coward · · Score: 0

      The nice things about SSDs is that yes, they do fail, but they fail (or are supposed to) in a predictable, non-catastrophic way that leaves the data readable just not writable.

      If you're talking about flash cell failure modes, you're correct. Flash cells wear out at semi-predictable rates, and most drives contain a "spare" area where failed writes can be re-located to, thus preventing data loss.

      What's not taken into account is a gross failure of the drive's electronics. Such a failure would render the entire drive catastrophically failed with no warning and practically no recovery capability. Plain old mechanical drives can have the same failure modes, and I've lost more than a few of them in this fashion. In the latter case, the platter and heads are fine, but the onboard controller is dead. Sometimes you can replace the logic board and recover some of the data, but it's anything but assured.

      Anyway, the point is that SSD's, while immune to the mechanical issues that plague rotating magnetic media, are still just as vulnerable to logic board failures. As such, if you have valuable data you need to put on an SSD, you need to RAID it just like you did with prior drive technologies.

  5. Why Windows 7 in the summary? by loufoque · · Score: 0

    Why is Windows 7 even in the summary?
    People who buy high-end disk drives and care about Windows must be quite a minority. The point of hard disk drives with fast writing performance is for servers.

    1. Re:Why Windows 7 in the summary? by Darkness404 · · Score: 2, Insightful

      Gamers, gamers, gamers and gamers. Seriously, the early adopters of any technology that is supposed to be faster on the consumer level will be gamers. Considering that most games are Windows-only it makes sense.

      --
      Taxation is legalized theft, no more, no less.
    2. Re:Why Windows 7 in the summary? by mrmeval · · Score: 2, Insightful

      Because someone got paid to do it. You don't think /. editors work for free do you?

      --
      I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
    3. Re:Why Windows 7 in the summary? by Anonymous Coward · · Score: 0

      *Must* be? You selfish, self-serving jerk. Start paying attention to things outside the idealistic server room setting. There are a lot of home users that want that speed for their own reasons.

    4. Re:Why Windows 7 in the summary? by Robotbeat · · Score: 3, Interesting

      Even the best consumer-level SSDs like the Intel x-25m/e use a volatile RAM cache to speed up the writes. In fact, with the cache disabled, random write IOPS drops to about 1200, which is only about three or four times as good as a 15k 2.5" drive. The more expensive truly-enterprise SSD drives which don't need a volatile write cache cost at LEAST $20/GB, so the $/(safe random write iop) ratio is actually still pretty close, and cheap SATA drives may actually be even on that metric as the fast enterprise SSDs. Granted, this shouldn't be the case in a year, but that's where it is right now. (Also, the performance-per-slot is a lot higher for SSDs, which can translate into different $ and power and space savings.)

    5. Re:Why Windows 7 in the summary? by zippthorne · · Score: 1

      Meh. Just stick in 50GB worth of RAM in there. No one's filling a Blu-Ray disk with 3d environment data yet, are they?

      Why should a game even hit the disk except when saving, these days?

      --
      Can you be Even More Awesome?!
    6. Re:Why Windows 7 in the summary? by Darkness404 · · Score: 1

      ...Because either the game has to do a lot of initial loading or use the disk. Even copying from the HD to RAM takes time, sure, today you can pre-load a bunch of stuff, but things still need to be written and read from the disk every now and then.

      --
      Taxation is legalized theft, no more, no less.
    7. Re:Why Windows 7 in the summary? by ls671 · · Score: 1

      > Gamers, gamers, gamers and gamers.

      Steve, is that you ?

      --
      Everything I write is lies, read between the lines.
    8. Re:Why Windows 7 in the summary? by hairyfeet · · Score: 1

      Which is why i don't get why the game designers aren't preloading like hell. even the cheapo cards are starting at 512Mb-1Gb, and many machines are 4Gb+. Hell the box i am typing this on i built for $500 with 1Gb on the GPU and 4Gb on the CPU, yet games insist on constantly loading from disc while a good chunk of the memory just sits there doing nothing. Surely they can scan the machine on first install and if GPU RAM equals X and system RAM equals y then prefetch like crazy. Or am I missing something?

      But the other poster is right, the hardcore gamers will snatch these up first. I have dealt with customers who think nothing of shelling out $1000 just on the GPUs, and several time that on the CPU+RAM. The hardcore gamers are always the early adopters for anything that will give them a couple more FPS to brag about.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    9. Re:Why Windows 7 in the summary? by Mitchell314 · · Score: 1

      Doesn't RAM data become undatified when you turn the machine off?

      --
      I read TFA and all I got was this lousy cookie
    10. Re:Why Windows 7 in the summary? by 42forty-two42 · · Score: 1

      And what's the problem with that? Any server worth its salt will have a small battery backup for its drive array to keep it running until array/disk write caches can be flushed anyway.

    11. Re:Why Windows 7 in the summary? by walshy007 · · Score: 1

      most ram does yes, but there are always exceptions to the rule.

    12. Re:Why Windows 7 in the summary? by eyepeepackets · · Score: 1

      Compress the data into a tarball (or .zip file, whatever) and write it to the hard drive when you are finished working/playing, reverse the process when setting up.

      Real speed junkies use RAMdisks!

      --
      Everything in the Universe sucks: It's the law!
    13. Re:Why Windows 7 in the summary? by Anonymous Coward · · Score: 0

      The Intel X25 has a tiny buffer in the controller chip like every other SSD out there. The buffer is needed for basic operation. The DRAM inside the X25 isn't used as a cache for user data. http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=10

    14. Re:Why Windows 7 in the summary? by atamido · · Score: 1

      Intel has specifically stated that the RAM cache on their drives is not used for writes. It is used while remapping sections of the drive, condensing sections, etc.

  6. trim by Anonymous Coward · · Score: 0

    Well, to be honest, what kind of nerd doesn't like a little trim?

    1. Re:trim by eyepeepackets · · Score: 1

      Yet another happy Microsoft customer vents his wrath on those wise enough to use something else.

      --
      Everything in the Universe sucks: It's the law!
    2. Re:trim by Anonymous Coward · · Score: 0

      I'm a faggot linux nerd, you insensitive clod!

  7. Potential data recovery problems by quazee · · Score: 2, Interesting

    Something as simple as deleting the wrong partition becomes an irreversible operation if you do it using a tool that supports TRIM on TRIM-enabled hardware.
    Even if you restore the partition table from a backup, you will likely suffer silent file system corruption, which may even not be apparent until it's too late.
    If TRIM support is actually implemented on the device, the device is free to 'lose' data on TRIMmed blocks until they are written at least once.

    --
    throw new SuccessException("Sig read successfully");
    1. Re:Potential data recovery problems by Anonymous Coward · · Score: 0

      Unless you mount the device as read only and copy to a different device, so the data doesn't have a chance to be overwritten.

    2. Re:Potential data recovery problems by quazee · · Score: 1

      This will only work if the drive doesn't do background 'scrubbing' to improve future write performance.
      Or, even if the drive didn't erase physical Flash cells yet, it could already mangle the mapping between the logical and physical blocks.
      In fact, I have a cheap CompactFlash card that does exactly that when you yank power from it while writing - the drive appears completely scrambled (with blocks reordered) when you restore power to it.

      --
      throw new SuccessException("Sig read successfully");
    3. Re:Potential data recovery problems by Spit · · Score: 1

      I would never, ever trust a filesystem after an event like this. Ever. Do your backups.

      --
      POKE 36879,8
    4. Re:Potential data recovery problems by steveha · · Score: 3, Insightful

      Something as simple as deleting the wrong partition becomes an irreversible operation if you do it using a tool that supports TRIM on TRIM-enabled hardware.

      This seems needlessly verbose. Let me shorten it for you:

      Deleting a partition should always be considered an irreversible operation.

      Hmmm, even shorter:

      Don't delete a partition unless you want it to go away forever.

      Even if you restore the partition table from a backup, you will likely suffer silent file system corruption, which may even not be apparent until it's too late.
      If TRIM support is actually implemented on the device, the device is free to 'lose' data on TRIMmed blocks until they are written at least once.

      If I understand you correctly, you are suggesting that a disk partitioning tool will use TRIM to not only wipe the partition table itself, but also nuke the partition data from orbit. And you the point out that it would not be adequate to rewrite just the sectors of the partition table.

      If so, then the answer is: you don't just restore the partition table, you restore the whole partition (including data) from backup.

      I for one consider much-faster write speeds to be a bigger advantage than possibly being able to reverse a partition deletion.

      steveha

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
    5. Re:Potential data recovery problems by rdebath · · Score: 1

      There will NOT be silent file corruption. If the OS TRIMs the entire partition it will appear to have been wiped by the drive. The physical blocks will be moved back onto the drive's free list the logical blocks will be mapped to the 'null block'.

      End result TRIM looks like a fast wipe and the data will be completely erased at the ATA level but the data won't be erased at the flash level until later.

    6. Re:Potential data recovery problems by ioliver · · Score: 1

      My understanding is that trim won't be done when partitioning but instead when a file system is created. So, fdisk won't have trim capability added, but mkfs will. So, creating a new filesystem over the top of valuable data will be a BAD THING but my view is that only one skilled in the art of marketing/political talking could ever have presented this as being a good thing.
      Ian

    7. Re:Potential data recovery problems by fimbulvetr · · Score: 1

      If you delete a partition or even a file, why the *hell* are you expecting it to be reversible? That's "delete" we're talking about here, not "hold my hand recycle bin". Delete. If you don't know in you're soul what you're doing, then why are you even in a partition editor?

  8. TRIM support by profaneone · · Score: 1

    So does this mean that the a girlfriend of a geek can save her files on it too??

    1. Re:TRIM support by Anonymous Coward · · Score: 0

      No, but maybe girlfriend b or girlfriend c could. Geek pimp ftw.

  9. SSDs?! by MMInterface · · Score: 1

    Despite the rising excitement over SSDs, some of it has been tempered by performance degradation issues.

    Who cares how they perform. All they have to do is sit there and scare away enemy fleets.

    1. Re:SSDs?! by Anonymous Coward · · Score: 0

      Despite the rising excitement over SSDs, some of it has been tempered by performance degradation issues.

      Who cares how they perform. All they have to do is sit there and scare away enemy fleets.

      Um...You're thinking of SSNs.

    2. Re:SSDs?! by Sabriel · · Score: 1

      Despite the rising excitement over SSDs, some of it has been tempered by performance degradation issues.

      Who cares how they perform. All they have to do is sit there and scare away enemy fleets.

      Um...You're thinking of SSNs.

      That sound you just heard was a Super Star Destroyer wooshing over your head...

  10. It is yesterdays future ... by Anonymous Coward · · Score: 0

    > Actually, magnetic disks have exponentially increased in capacity since the 50s.
    > In fact, the rate of increase has been higher than the growth of transistor count.

    No, it hasn't!

    According to the - slightly stale, from 2005 - article, magnetic storage density has increased by a factor of 50 million in 49 Years, from 2000bit/sq.in. in 1956 to 100Gbit/sq.in. in 2005.

    In the same time, transistor count has increased from 1 (single Transistor) in 1956 to a billion Transistors (Gbit Ram) in 2005.

    Even if you start in only 1970 with the 1Kbit Dram, you get a millionfold (2^20) increase in just 35 years, or a doubling every 1.75 years, while Disks increased by less than 2^26 in 49 years, doubling only every 1.9 years.

    And these days, Hard disks are as dead as a certain parrot!

    Unlike in 2005, none of the current must-have gadgets like Iphones, Navigation Systems or high-end Netbooks still sports one, they are increasingly relegated to a role in Grandma's cheap walmart computer holding 10 years worth of crappy photos and videos.

    1. Re:It is yesterdays future ... by geekboy642 · · Score: 4, Insightful

      I can buy a terabyte hard drive for around $100. For the same hundred dollars, the best SSD I can find is 32GB. On my computer, Steam's cache folder is bigger than 32GB. My music player has a 120GB drive, my DVR has a 350GB drive, and my backup server has a 1.5TB raid. Just because expensive mobile gadgets use expensive solid-state drives does not mean hard drives are dead, dying, or even decaying.

      --
      Just another "DOJ fascist authoritarian totalitarian bootlicker" -- Zeio
    2. Re:It is yesterdays future ... by j-turkey · · Score: 1

      I can buy a terabyte hard drive for around $100. For the same hundred dollars, the best SSD I can find is 32GB. On my computer, Steam's cache folder is bigger than 32GB. My music player has a 120GB drive, my DVR has a 350GB drive, and my backup server has a 1.5TB raid. Just because expensive mobile gadgets use expensive solid-state drives does not mean hard drives are dead, dying, or even decaying.

      I totally agree, the fat lady hasn't sang when it comes to magnetic hard drives. It does seem like SSD's will soon find their place in performance-oriented systems though. I'm looking forward to having them sorted out enough that my next desktop will have a SSD for an OS, swap, and perhaps applications (which all tend to be hindered by the slow random access of magnetic media) - and a big honkin' magnetic drive for storage.

      --

      -Turkey

    3. Re:It is yesterdays future ... by setagllib · · Score: 2, Informative

      If you can afford an SSD, why would you waste it on swap? Why not just buy more RAM? If you ever actually need swap, you are doing something wrong.

      --
      Sam ty sig.
    4. Re:It is yesterdays future ... by rtfa-troll · · Score: 2, Interesting

      How about hibernate to disk? If you have lots of good SSD that should be very fast shouldn't it?

      --
      =~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
    5. Re:It is yesterdays future ... by Maian · · Score: 1

      So you're willing to spend a hundred bucks or so to speed up hibernate time by a couple seconds? Do you hibernate 10 times a day or something?!

    6. Re:It is yesterdays future ... by Trahloc · · Score: 2, Funny

      Think of it as a luxury expense from the cash we save building our own systems.

      --
      The Goal: A long simple life filled with many complex toys.
    7. Re:It is yesterdays future ... by j-turkey · · Score: 1

      It makes less sense for non-windows OS'es. Windows always seems to make use of the pagefile, regardless of memory.

      --

      -Turkey

    8. Re:It is yesterdays future ... by Anonymous Coward · · Score: 0

      wrong. Sequential write is still faster on (10-15krpm, high density) spinning disks. And hibernate is the most extreme case of sequential write you get.
      As the price of the 15k disks is about the same as that of the SSDs, the only downside would be the exquisite noise....

    9. Re:It is yesterdays future ... by Anonymous Coward · · Score: 0

      If you can afford an SSD, why would you waste it on swap? Why not just buy more RAM? If you ever actually need swap, you are doing something wrong.

      Swap is useful if you've already maxxed out your RAM.

    10. Re:It is yesterdays future ... by danieltdp · · Score: 1

      He sould hibertate only once in a year. Oh, wait...

      --
      -- dnl
    11. Re:It is yesterdays future ... by vertinox · · Score: 1

      Just because expensive mobile gadgets use expensive solid-state drives does not mean hard drives are dead, dying, or even decayin

      True, but mechanical hard drives usually the bottle necks for many systems who need raw speed for power applications and games.

      Its not something as trivial as mobile gadgets, but many gamers have reported amazing results on their system using SSD. Soon most desktop publishing and video production houses will have SSD as their primary hard drive because they go the bick bucks to spend (no more waiting 12 hours for video to compress).

      I do believe mechanical hard drives will be used in tandem with SSD for a while because sometimes you just need archiving.

      Next year when I build a new gaming system I plan on using an SSD as my primary hard drive (hopefully prices will have gone done) and then an old HDD as archive purposes.

      If SSD ever gets cheap enough I'll just use that as my primary drive once it gets beyond 125 GB.

      (I only use a 100gb partition for my primary drive that I currently use for games because I tend to format it a lot)

      --
      "I am the king of the Romans, and am superior to rules of grammar!"
      -Sigismund, Holy Roman Emperor (1368-1437)
    12. Re:It is yesterdays future ... by vertinox · · Score: 1

      Just because expensive mobile gadgets use expensive solid-state drives does not mean hard drives are dead, dying, or even decaying.

      Oh and SSD vs HDD reminds me of CRT versus LCD about 5 years ago.

      Many people said LCDs screens were too expensive but...

      Do you see any CRTs for sale today?

      --
      "I am the king of the Romans, and am superior to rules of grammar!"
      -Sigismund, Holy Roman Emperor (1368-1437)
    13. Re:It is yesterdays future ... by jones_supa · · Score: 1

      I've been also thinking that using swap decreases the system reliability a bit. What if a swapped bit gets corrupted on disk and then later returned to memory? No matter what premium ECC memory you had on the system, you essentially have corrupted RAM now.

    14. Re:It is yesterdays future ... by Anonymous Coward · · Score: 0

      Page/Swap in both *NIX and Windows supports a backing store function. In multiprocessing systems, the OS wants to put a "copy" of the loaded modules into the virtual storage and then page it back in if it's needed. There are a lot of applications, particularly on windows, which remind me of the old Terminate & Stay Ready (TSR) software from DOS days. The main difference now is they interrupt driven from other events and not a keyboard-based n-finger salute. So page/swap is definitely still needed and most multiprocessing systems perform better with it, regardless of the memory configuration.

    15. Re:It is yesterdays future ... by Minimalist360 · · Score: 1

      Hard drives were once super expensive compared to floppies or tape. The benefit over floppy was massive storage. The benefit over tape was random access, but there was a huge difference in storage capacity favoring tape.

      Right now SSDs are super expensive compared to rotational hard drives. The benefits are NO seek time, superfast sustained reads and writes, and no mechanical failure when you throw them across the room. For the laptop formfactor, they have proved their worth.

      A year ago when purchasing a Dell XPSM1330 you could add a 64GB SSD as an upgrade from a 120GB SATA rotational drive for $800. I know because I bought one. I was very very happy with it except for the size. I carried around an external drive and it was irritating. Three months ago I bought the same computer, only this time I could upgrade from a 250GB SATA rotational drive to a 256GB SSD for $400, which I did. I gave the old laptop to my wife, and put a 32GB SD card in the front of it for MP3s. She's happy. I can keep my music library right on the main drive and still have 70GB free now. I'm happy. Really happy.

      Until you've experience the virtually complete lack of seek in real-world situations, for all data including non-cached data, it's hard to appreciate the impact it has on your day to day experiences. And this is just consumer-level, you should see some of the crazy SSD solutions for server environments.

      Give it another year and we'll see where we're at. I think there's a reason everyone making rotational media has been hedging by purchasing SSD technology. And Seagate suing everyone.

    16. Re:It is yesterdays future ... by Minimalist360 · · Score: 1

      False, false, and false.

    17. Re:It is yesterdays future ... by toddestan · · Score: 1

      Ram may be around $10/GB, but it is very difficult to build a computer with more than 8GB in it. Desktop boards typically only have 4 DIMMs slots in them, and if you want cheap memory you're looking at 2GB sticks. So the best you can easily do is 4x2GB for a total of 8GB. Some Core i7 boards have six slots, so you can get 12GB into them. Besides that, you're looking at either an expensive server board (and possibly an expensive server-class processor to match), and/or expensive high density memory sticks - if you can even find them.

    18. Re:It is yesterdays future ... by j-turkey · · Score: 1

      Howso? Even with tons of memory, Windows (or at least most apps) require a pagefile. Even when the OS doesn't actively page, it still writes to the commit change, which accesses the disk, slowing down app-loading or other disk access. I'm not very happy with the windows paging behavior. Care to show me where you think that I'm wrong, or just throw around "false, false, and false"?

      --

      -Turkey

    19. Re:It is yesterdays future ... by Anonymous Coward · · Score: 0

      If you need more memory, build a second machine - you're right up there in distributed processing territory anyway. SSD or not, your memory workload will become a disk workload if you use swap, so what is the point of having a single powerful computer when two weaker ones will outperform it?

  11. Ooh yeah! by sootman · · Score: 1

    I'd love to get me some trim!

    --
    Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
    1. Re:Ooh yeah! by Korbeau · · Score: 1

      But are you in a solid state?

  12. ReiserFS 3 by bobbuck · · Score: 1

    I bought a WinTec FileMate Ultra 24G from Tiger Direct that plugs into the ExpressCard Slot. I am now using that as the boot partition with reiserfs (v3), elevator=noop, and mounted noatime. This might not give the very best performance but it is much faster than the stock HD. OpenOffice loads in 2 seconds. I turned down the /sys/block/sdb/queue/read_ahead_kb but I'm not sure where it should be. I put my logs on tmpfs. Some people put the Firefox cache on tmpfs.

  13. TRIM needs a driver, a windows driver? by Ilgaz · · Score: 1

    The most important point of hard disks are being amazingly multi platform. I didn't like the sound of "Windows driver", "OS support" to perform nicely.

    SSD guys really better stick to the standards and never, ever do anything requiring a "driver" on host OS. For example, there are G4 Mac owners who happily upgrades their "old tech" magnetic drives to 500 GB or even 1TB. Who will write driver for them? Apple? SSD vendor? I don't think so.

    In fact, HD vendors really better stay away from writing anything except the "smart control" stuff... Or, they better donate to smartctl project and stay away from it too...

    1. Re:TRIM needs a driver, a windows driver? by CyberDragon777 · · Score: 1

      TRIM is just like any other ATA command, you don't need different drivers, only one driver that supports TRIM.

      --
      We both said a lot of things that you are going to regret.
  14. A tip for people reading "fragmentation by Ilgaz · · Score: 1

    Coriolis Systems (who produces iDefrag) jokingly referred to that issue on their blog.

    " Ironically even SSDs, where you would expect the uniform access time to render fragmentation a problem of the past, still have various problems caused by exactly the same issue(1)'

    of course, they add:

    1 For avoidance of doubt, we strongly recommend that you don't try to defragment your SSD-based volumes. The fragmentation issue on SSDs is internal to their implementation, and defragmenting the filesystem would only make matters worse.

    In case you spot a good friend who got suggested by Microsoft to defrag their drive (Win7 does it even without asking), you better tell it is not the "magnetic disk fragmentation" issue. It is really different and I heard some real bad stories from people who defragmented (!) their SSD drives.

  15. TRIM support by Dexter+Herbivore · · Score: 1

    Am I the only one that read the words "TRIM support" and immediately thought of tight fitting panties?

  16. Revision 1571? by Mr+Z · · Score: 1

    Will it work on my Commodore?

  17. Apparently Windows 7 will... by Anonymous Coward · · Score: 0

    Apparently Windows 7 will... enough of the promotion of Windows 7 already. I don't object to advertising but I really do hate it when someone tries to pretend that they just want to tell us about one thing, when the real purpose is to tell us about something else.

  18. What about hybrids? by Waccoon · · Score: 1

    Where are all the wonderful SSD/HD hybrid drives that were supposed to come out and prevent many of the problems SSDs have?

    My dad bought me an SSD for my birthday, and it was one of those models that has horrible studdering issues (which, from what I'm reading, covers most SSDs). That was a lot of money for a drive that let me install drivers about 20 times slower than a hard drive would, and caused my machine to freeze for 20-40 seconds at a time while just surfing the web. That was after disabling all the NTFS caching and optimization nonsense, too.

    I remember a long time ago talking to a guy about using a mix of fast and cheap memory in the same computer instead of a huge amount of memory running at one speed. Instead of talking about memory controller costs and OS design, he just told me, "There's no such thing as cheap memory". Well, I seem to see that SLC and MLC have a large difference in cost and performance. Is it at all practical to make a drive with a little SLC and a lot of MLC to aid in performance and wear-leveling issues? SSDs already utilize several megs of cache memory, so is it really that impractical to mix different flash technologies to solve the random-write problems?

    1. Re:What about hybrids? by Waccoon · · Score: 1

      Never mind about the mixing of flash types. I did my research.

      I still want to know where the hybrids are.

    2. Re:What about hybrids? by vertinox · · Score: 1

      I've heard some of the earlier SSD are crap because the controllers are crap.

      They say the new Intel ones have been getting rave reviews because it has a quality controller.

      Of course they are more expensive than everyone else's.

      Which brand did you father get you?

      --
      "I am the king of the Romans, and am superior to rules of grammar!"
      -Sigismund, Holy Roman Emperor (1368-1437)
    3. Re:What about hybrids? by Waccoon · · Score: 1

      OCZ Apex 60GB, the one with dual JMicron controllers. It also got rave reviews when it was released, but the real-world usability is rubbish.

      Even now, there are still too many SSDs based on the JMicron controller, and the newest drives based on this design have large caches and are better than the old ones, but they still have problems. My personal opinion is that the companies who made/are making these drives should have known better than to release the products at all, because the problems are so explicit. There's no way at all they could have unleashed these drives and thought they were appropriate for the market. Apparently, 150+MB read speed benchmarks work very well to sell poorly tested products. It didn't take much research for me to see that these drives were not acceptable.

      There's also so many drives using the JMicron, it's nearly impossible to find anything else unless you visit a review site that has dared to photograph the inside of the drive. Many manufacturers won't tell you what's inside.

      I'm considering a Samsung-based Corsair P128 as a replacement. Intel doesn't have anything between 80GB and 160GB, which is a shame.

  19. What am I missing here? by Anonymous Coward · · Score: 0

    I'm not sure I understand the problem. So the SSD thinks it's full but the OS has 'deleted' parts of it so it's really not full, but it hasn't bothered to inform the SSD of this fact, is that the general gist?

    OK, so SSD doesn't know that a file is gone and that memory space can be over written.. but then what happens when the OS says, oh, hey, save this new file here please?

    How does the SSD know at that point what part of itself it can write the new file to? I can come up with:

    1. The OS tells it. OK, so why can't the OS just tell it when it deletes the file and be done with it?

    2. It guesses.. somehow that doesn't seem likely?

    I have no idea why a TRIM command, which I picture as say, emptying your recycle bin, would necessitate having to move a whole bunch of data around freeing up larger blocks, which I picture as a defrag.

    The SSD knows where the files are, or it couldn't access them, it knows where the free space is, or it couldn't utilize it.. so how come it can't simply free up the space on a TRIM instead of moving stuff around?

    Is it because each memory space needs to be, hmm, load balanced in a way to avoid early failure? In that case, why not throw more than 1 algorithm at the writes initially, like go up, down, left right, circle, pyramid, etc. (I'm picturing the memory space as a massive field of squares).

  20. Shouldn't we have stupid disks? by mbarkhau · · Score: 1

    What I don't get, is that we have wear leveling in controlers and they also have to translate virtual blocks to physical blocks.

    We have file systems that are meant for hard disks, so why don't we have file systems for SSDs? You could just buy any old stupid SSD and get decent performance out of it.

    1. Re:Shouldn't we have stupid disks? by CyberDragon777 · · Score: 1

      File systems don't decide where to put the tracks on the magnetic platters, why should they decide where to write the data in a flash chip? Unless you want to move the "smartness" into the OS, that would mean SSD manufacturers couldn't use specific optimizations, or had to issue proprietary drivers.

      --
      We both said a lot of things that you are going to regret.
    2. Re:Shouldn't we have stupid disks? by badkarmadayaccount · · Score: 1

      What's the problem with SSD drives in EFI machines at least? EFI allows the driver to be contained in the device itself, making it available before the OS loads. It just has to support EFI. And you get the free extra that the drive could be easily using PCIe or HyperTransport. Heck, embed a SATA controller pseudodriver and a static x86 partial evaluating hypervisor to get around virtualized hardware overhead without touching the drivers.

      --
      I know tobacco is bad for you, so I smoke weed with crack.
  21. Re:I love trim by Anonymous Coward · · Score: 0

    +1 Camel Toe

  22. tape is very, very useful by Anonymous Coward · · Score: 1, Interesting

    if by "proven rock-solid" you mean horrid fidelity and media degradation rates, i'd say you are correct about tapes.

    [citation needed]

    Tapes probably have a better unrecoverable error rate that drives and don't have bits flip randomly while data is at rest like hard drives are found to do. See the talk entitled "No Terabyte Left Behind" given by Andrew Hume at LISA '07 (Wed. 4-6pm):

    http://www.usenix.org/events/lisa07/tech/

    hey're wasting a LOT of time just retrieving data.

    High speed drives can go from shelf to data in a maximum of 60 seconds.

    you should really consider a SAN NAS or similar.

    Tapes have the highest measure of density when it comes to TB/kW and TB/sq. of data centre floor space. LTO-4 is up to 800 GB native in a tiny little package that takes no power, and LTO-5 is currently in draft and will be 1.6 TB native (add compression for fun). With LTO-4 (and other tape standards as well) and above there's also a standardized way to encrypt the data (AES-256), so if it goes offsite you don't have to worry about data loss.

    Tape may not be for everyone, but there are certain things for which there is no replacement for. CERN is using tape to archive the 15 PB/year of data that's going to be generated by LHC: do you want to know how much power to would take to have 15 PB on SAN / NAS? Then take that power and multiply it by 2 or 3 to running the cooling.

  23. Don't count your chickens just yet by TravisO · · Score: 1

    It's still a bit early to say SSD has better longevity than a traditional HDD, in theory, yes I agree, SDD probably outlasts HDDs, and this will be even more true as they improve, but I'm not about to jump on the SDD boat 100% just yet.

    Better safe than sorry, we've had HDDs for decades and they're fairly acceptable albeit not perfect.

  24. I thought NILF stood for by TravisO · · Score: 1

    Nerds I'd Love to F#!K

  25. Usage statistics? by Chelloveck · · Score: 1

    Is there any way to get usage statistics out of the SSD itself? Specifically, I want to query the drive for the number of erase cycles each physical block of flash has been subjected to, verify failures, etc. This should be quite different from the logical block usage at the file-system level, so I don't expect standard HDD tools to give an accurate picture of the drive's health.

    --
    Chelloveck
    I give up on debugging. From now on, SIGSEGV is a feature.
  26. Mod parent up please by cbhacking · · Score: 1

    Thank you. That is a better explanation of the exact problem than I gave, as it explains better why it is so difficult / takes so much time to find a region suitable for erase/overwrite (and why TRIM helps the drive so much).

    --
    There's no place I could be, since I've found Serenity...