Impact of solid-state drives
in [Unix Programming]
|
Prev: gethostbyname doesn't accept IPv6 addresses
Next: 7 x = ."It's" IF ." " ELSE ."not " THEN ."equal"
From: Francois Tigeot on 5 Mar 2010 02:54 Carlie Coats wrote: > Noob wrote: >> [ NB: X-posted tocomp.arch andcomp.unix.programmer ] >> >> Within 1-2 years, "mainstream" desktop PCs will probably come >> equipped with a "small" (32-128 GB) solid-state drive (SSD) for >> the operating system and applications, and (possibly) an additional, >> larger (500+ GB) hard-disk drive (HDD) for a user's media (mostly >> compressed audio and video). > [snip...] >> Given the typical Unix directory structure: >> http://en.wikipedia.org/wiki/Unix_directory_structure >> which directories should go the SSD and which to the HDD? >> >> bin and sbin => SSD >> usr => SSD probably >> home => HDD >> etc ?? => not modified often ?? SSD perhaps >> var ?? > > SSD's excel (relative to HDDs) at random I/O -- especially > small random reads -- but current models still beat out HDDs > for random writes, as well. It's worth noting that Linus > Torvalds has remarked that the SSD on his new machine gives > him a larger performance boost than the Nehalem processor > does -- software builds involve _lots_ of random scratch I/O. A new swapcache(8) mechanism has just been integrated in the development version of DragonFly BSD. The idea is to configure a fast SSD as swap, which then caches regular disk data. You can choose which directory hierarchies are selected for data caching with special file flags. Some links: http://www.shiningsilence.com/dbsdlog/2010/02/21/5489.html http://www.shiningsilence.com/dbsdlog/2010/02/23/5503.html http://leaf.dragonflybsd.org/cgi/web-man/?command=swapcache§ion=ANY -- Francois Tigeot
From: James Harris on 5 Mar 2010 03:54 On 4 Mar, 23:43, sc...(a)slp53.sl.home (Scott Lurndal) wrote: > Morten Reistad <fi...(a)last.name> writes: > >In article <hmoo7o$46...(a)speranza.aioe.org>, Noob <r...(a)127.0.0.1> wrote: > >>In short, will widely-available SSDs require OS designers to make > >>large changes, or is the current infrastructure generic enough? > > >This is old news. I have been deploying such systems for 7 years now. > > SSD's have been available for over 25 years in the mainframe world, some > using battery backed DRAM, some using much more expensive SRAM. Are you sure that's the distinction you intended? SRAM (static RAM) would need battery backing - and a significant amount of it. DRAM would need battery backing and refresh logic. James
From: Noob on 5 Mar 2010 05:12 Scott Lurndal wrote: > Noob wrote: > >> [ NB: X-posted to comp.arch and comp.unix.programmer ] >> >> Within 1-2 years, "mainstream" desktop PCs will probably come >> equipped with a "small" (32-128 GB) solid-state drive (SSD) for >> the operating system and applications, and (possibly) an additional, >> larger (500+ GB) hard-disk drive (HDD) for a user's media (mostly >> compressed audio and video). >> >> In the SSD+HDD scenario, I was wondering whether it would be >> "better" (for some metric) to have the OS swap to the SSD or >> to the HDD? > > It's "Better" (for all metrics) to not swap. What happens when there's "just not enough RAM"(TM)(R)? Do you over-commit? > No. It never makes sense to page executable code. I think you mean "it never makes sense to page unmodified pages". (since they can be reloaded from the original media, right?) What if the original media is a DVD? What if the code has modified itself? or it's JIT compiled? > My current test system has 112 processors, 1TB memory and 64 Intel > SSD drives (attached to 16 LSI hardware raid controllers). It never > swaps :-). OK, so you're saying next year's typical mainstream desktop personal computer will come with 112 cores and 1 TB RAM. Where do I sign up? I have my 500 USD right here. Regards.
From: Noob on 5 Mar 2010 08:59 Carlie Coats wrote: > Noob wrote: > >> [ NB: X-posted to comp.arch and comp.unix.programmer ] >> >> Within 1-2 years, "mainstream" desktop PCs will probably come >> equipped with a "small" (32-128 GB) solid-state drive (SSD) for >> the operating system and applications, and (possibly) an additional, >> larger (500+ GB) hard-disk drive (HDD) for a user's media (mostly >> compressed audio and video). >> [...] >> Given the typical Unix directory structure: >> http://en.wikipedia.org/wiki/Unix_directory_structure >> which directories should go the SSD and which to the HDD? >> >> bin and sbin => SSD >> usr => SSD probably >> home => HDD >> etc ?? => not modified often ?? SSD perhaps >> var ?? > > I vote for "small" 100-250 GB SSD In my neck of the woods, MLC solid-state drives currently cost 2-4 EUR per GB. Assuming prices are cut in half in the next 12 months (optimistic IMO), we're still talking 250-500 EUR for a 250GB SSD. IMHO, that's too steep for mainstream desktop PCs. > directly on the motherboard Do you mean soldered to the motherboard? If so, what for? > (or, worst-case PCI bus) Are you considering a SSD on a PCI expansion card, instead of one with a SATA interface? Ccommon PCI buses (32-bit @ 33 MHz) are limited to 133 MB/s. Regards.
From: Chris Friesen on 5 Mar 2010 09:23
On 03/04/2010 12:35 PM, Scott Lurndal wrote: > It's "Better" (for all metrics) to not swap. > It never makes sense to page executable code. Of course it's better not to swap. However, given a specific machine and a specific workload, there may be no possible way to fit both the code and the data set into RAM at the same time. If swapping out a page of code that gets executed extremely rarely allows the data set to fit in RAM and the app runs 10x faster, I'm all for paging executable code. Chris |