Hybrid drives do not use their meager flash to cache writes. The flash would wear out in an instant if they did that. It's strictly useful only for boot data and that is pretty much it, if a few seconds matters to you and you don't want to buy a separate SSD. For any real workload, the hybrid drive is a joke.

-Matt

Never buy hybrid drives, period. You are just multplying the complexity of the firmware (resulting in more bugs, as Seagate's earlier attempts at Hybrid drives revealed), and decreasing the determinism of the failure cases. And there's no point. A hybrid drive has a *tiny* amount of flash on it. It's good for booting and perhaps holding a program or two, and that is pretty much it. For someone who does so little on their computer that it would actually fit on the flash portion of a hybrid, a hard drive will be almost as fast. For someone who uses the computer more significantly, the hybrid flash is too small to matter.

My recommendation is to use only a SSD for workstations and desktops as long as you don't need terrabytes of storage. For your server, if you can't afford a large enough SSD, then a SSD+HDD combination (or SSD + HDD/RAID) works very well. In this situation you put the boot and swap space and the SSD, plus you cache HDD data on your SSD.

This is pretty much what we do on our systems now. The workstations and desktops are SSD-only, the servers are SSD + HDD(s).

The nice thing about this is that with, say, a 256G SSD on the server caching roughly ~200GB worth of HDD data, the HDD's do not require a lot of performance. We can just use 2.5" 2TB green drives. Plus we can use large swap-backed ram disks and so on and so forth. Makes the servers scream.

-Matt

Are you stupid?

-Matt

A serious photographer is sitting on $20K+ worth of equipment and a potentially ruined contract if any data is lost. Spending $1000 on a highly reliable high-capacity SSD to backup camera cards on a field trip is worth more than god.

-Matt

A 7200 rpm HDD can do 200-400 IOPS or so, semi-random accesses (normal database access patterns). A 15K HDD can do ~400-600 or so. Short-stroking a normal drive also gains you at least 100 IOPS (so, say 300-500 IOPS on a short-stroked 7200 rpm HDD). That's off the top of my head.

A SATA SSD, of course, can do 60000-100000 IOPS or so and a PCI-e SSD can do even more.

-Matt

Depends on the application. For a workstation or build box, we configure swap on the SSD.

The point is not that the build box needs to swap, not with 32G or more ram, but that having swap in the mix allows you to make full use of your cpu resources because you can scale the build up to the point where the 'peaks' of the build tend to eat just a tad more ram resources than you have ram for (and thus page), which is fine because the rest of the build winds up being able to better-utilize the ram and cpu that is there. So putting swap on a SSD actually works out quite nicely on a build box.

Similarly, for a workstation, the machine simply does not page enough that one has to worry about paging wearing out the SSD. You put swap on your SSD for another reason entirely... to allow the machine to hold onto huge amounts of data in virtual memory from open applications, and to allow the machine to get rid of idle memory (page it out) to make more memory available for active operations, without you as the user of the workstation noticing when it actually pages something in or out.

A good example of this is when doing mass photo-editing on hundreds of gigabytes of data. If the bulk storage is not a SSD, or perhaps if it is accessed over a network that can cause problems. But if the program caches pictures ahead and behind and 'sees' a large amount of memory is available, having swap on the SSD can improve performance and latency massively.

And, of course, being able to cache HDD or networked data on your SSD is just as important, so it depends how the cache mechanism works in the OS.

So generally speaking, there are actually not very many situations where you WOULDN'T want to put your swap on the SSD. On machines with large ram configurations, the name of the game is to make the most of the resources you have and not so much to overload the machine to the point where it is paging heavily 24x7. On machines with less ram, the name of the game is to reduce latency for the workload, which means allowing the OS to page so available ram can self-tune to the workload.

-Matt

Happening a little sooner than I thought, but the trend has clearly been going in this direction for a long time now. Just one year ago I stopped buying 3.5" HDDs a year ago in favor of a combination of (short stroked) 2.5" drives and SSDs. I already use only SSDs in all the workstations and laptops, the HDDs are only used by the servers now.

Now it is looking like I will probably not buy any more HDDs at all, ever again, even for the servers. That is going to do wonders for hardware life and maintenance costs.

It's a bit strange having a pile of brand-new perfectly working 1TB and 2TB 3.5" HDDs still in their static bags, unopened, in my spare drawer that I will likely never use again.

I wonder how long it will take case makers to start giving us 2.5"-only hot swap options without all the 3.5" crap taking up room. Of course, there are some already... I mean for it to become the predominant case style.

-Matt

Part of the problem is that it is very difficult to tell a player using hacks from a player who is simply good at playing the game. I remember, a long time ago (10+ years) my brother was a counter-strike player who specialized in head shots. He was very good at it, but standing behind him while he played there were numerous occasions where he got kicked off a server due to players thinking he was cheating. He wasn't. I was standing right there behind him.

I think the only real solution is to video yourself playing the game so other players can see (after the match) that you were not using any cheats or hacks. Either that or play at an official location with monitors and public hardware.

-Matt

Motorola did produce a HCMOS version of the 68000 and related cpus. e.g. the 68hc000 and friends, which I used extensively. HCMOS was billed as a 'fast' version of CMOS, trading off some current draw for speed. As people might remember, HCMOS pulls and pushes about the same (though the ground paths are rated higher). About 50 ohms to either rail, more capacitive than resistive so current draw ran more inline with the frequency and you could use 1M pull-down resistors on the tri-state busses and the logic was pretty bullet proof in terms of noise and reflections.

I really loved HCMOS, and hated TTL, but eventually advanced ttl beat it out (at least for the pin interface logic).

-Matt

Interrupts worked fine. It was bus errors (i.e. for off-chip memory protection and/or mapping units) that were a problem. The 68010 fixed that particular issue if I recall. I'm guessing later 68008's also did but I dunno. Doesn't matter since he isn't running with any memory protection.

You could in fact run a real multi-tasking OS on the 68000. I was running one of my own design for my telemetry projects. It didn't have memory mapping but it did have memory protection via an external static ram, 8:1 selector, and some logic. It managed around 20-30 processes.

And, strangely enough, you could also run a RTOS because the 68000 had wonderful prioritized interrupts. Back then, of course, real time response was required for handling serial ports and things like that.

-Matt

Er, I meant 8:1 selector (the R/~W bit was fed into one of the select inputs). The function code logic was used to selectively enable/disable the memory protection unit, so supervisor accesses bypassed it while user accesses did not. Which is good because it wouldn't have been able to boot otherwise.

Another use for the FC logic is to speed up the auto-vector code. The 68K had wonderful asynchronous interrupt logic. You basically had 8 priority levels and you could feed your I/O chips into a simple 8:3 priority selector and feed the result into the interrupt priority level pins on the cpu. The 68K would then do an interrupt vector acquisition bus cycle to get the vector (or you could tell it to generate an internal vector). Every once in a while the async logic would screw up and we'd get an uninitialized interrupt vector but the code to deal with that was trivial, and since it was all level logic the hardware would sort it out soon enough and calculate the correct IPL to request from the bus.

The autovectors are slow, though... it was far better to generate vectors from a ram (if I remember right). The FC logic could be used to force the access to the ram or the eprom (since the address lines I think were all 1's except for three bits defining the priority level being fetched, or something like that).

In contrast, even to this day Intel STILL can't get their interrupt logic to work properly. Even the MSI-X logic is broken in a lot of chipsets. Yuch. So much ridiculous and unnecessary complexity with Intel interrupt handling with all the idiotic IOAPIC and LAPIC sub-processors with non-deterministic reaction times and serialization problems and other stupid stuff. The motorola interrupt logic was a dream in comparison.

-Matt

Congratulations, you are now in a rare group indeed. But I gotta say, you haven't lived until you've programmed a 6502 directly in machine code. No assembler :-)

One of my telemetry systems which I built and designed 25+ years ago used the 68000 running at around 10 MHz (with a jumper for 20 MHz, which it could actually do though I didn't deploy it at those speeds). The coolest thing about it was that I had built a rudimentary memory protection unit using a static ram and an 8:2 selector. Any user mode accesses pumped the high address bits into the ram with 2 address bits going to the selector along with the R/~W bit. The result was gated into the bus error logic. The top three bits of the static ram were directly controlled by the kernel which allowed the kernel to 'cache' up to 8 process's worth of protection data in the ram at any given moment, so context switches were still very fast.

Before the 68030 and 68040 came out, Sun (I think) was running two 68000's in lockstep, one one cycle behind the other, in order to implement their own MMU. When a fault would occur, they bus-errored the lead chip and paused the second 'behind' chip so they could take the bus fault, resolve the mapping issue, and then resume the behind chip. Then the 68010 came along and fixed the bus error interrupt stacking bugs in the 68000, and the 68020 came along after that.

The 68030 could hold short loops in its chip logic with some tricks, despite not really having a cache. Unfortunately, the 68040's on-chip cache implementation was horrible and created all sorts of problems for implementers, and by then Intel chips were running much much faster.

When Motorola retired the 68K series some of their larger embedded users asked motorola to re-test the 68000 chip specs at a higher clock, since by then the HCMOS process could obviously run the chip much faster than the ~10-12 MHz that was speced. Motorola tested the HCMOS version of the chip to around 50-70 MHz or so. Such a nice 32-bit chip, I was really sorry to see Moto lose to Intel (mostly because Moto gave up).

-Matt

but... operation is not even remotely smooth enough to compete with apps running with native graphics libraries. On Apple or Android. Still too sludgy, the browser implementation still does not implement sufficient concurrency to make it work well.

-Matt

You obviously have not had to deal with customer/user complaints about filesystem corruption. Because if you had, you'd rapidly come to the conclusion that the manpower required to service all of those complaints, let alone track down the cause (which is virtually impossible if TRIM is enabled), not to mention the bad rep that you get whether it is your fault or not, is simply not worth it.

-Matt

Complete nonsense. You seem to think that TRIM is some sort of magical command that makes SSDs work better. Spend a little more time on understanding the reality and your opinion will change.

Overprovisioning works extremely well. So well that there is really no reason to use TRIM, and plenty of reasons to avoid using it due to the many reasons stated by myself and a few others here.

Overprovisioning and TRIM do not have linear relationships. You don't get double the value by using both, or even double the value by, say, doubling the amount you overprovsion, or doubling the amount of free space the SSD thinks it has due to using TRIM. Beyond a certain point, overprovisioning and TRIMmed space will have only a minimal effect on actual wear because, as I've said already, a good SSD will do both static AND dynamic wear leveling. Dynamic wear leveling alone using TRIMmed or overprovisioned space, no matter how much space is available, only delays the inevitable need to relocate static blocks.

You can reduce the copying the SSD has to do, but beyond a certain point the amount of copying that remains will be so far under the radar compared to nominal filesystem operation (normal writes to files, etc), that it just won't have any more of an impact.

The non-deterministic nature of TRIM (depending heavily on how full your filesystem is and how fragmented it is), not to mention firmware bugs, filesystem bugs, the impossibility of diagnosing and tracking down corruption when it occurs, problems with feeding TRIMs through block managers which use large-block CRCs, and many other issues wind up creating huge complexities that increases your chance of hitting a bug somewhere that blows you up... it's just not a good trade-off. I will take the *highly* deterministic and generally bullet-proof overprovisioning method over TRIM any day of the week.

The only time I advocate using TRIM is when someone wants to wipe and repartition a SSD from scratch. That's it. I don't even advocate it for cleaning up the swap partition on reboot because then you can't recover crash dumps (and you might already be paging after that point so...). Though I suppose one could add some logic to TRIM the swap partition if no crash dump is present. That's about as far as I would go, though.

-Matt