Slashdot Mirror
How To Use a Terabyte of RAM
Spuddly writes with links to Daniel Philips and his work on the Ramback patch, and an analysis of it by Jonathan Corbet up on LWN. The experimental new design for Linux's virtual memory system would turn a large amount of system RAM into a fast RAM disk with automatic sync to magnetic media. We haven't yet reached a point where systems, even high-end boxes, come with a terabyte of installed memory, but perhaps it's not too soon to start thinking about how to handle that much memory.
Finally, I'll have enough space to run Firefox, OpenOffice, and Eclipse *all at the same time*! As long as I don't leave Firefox running too long.
Klingon programs don't timeshare, they battle for supremacy.
Given that the core components of an OS are only a few GB, even 8GB systems might be able to do this, today.
GPL Deconstructed
With all that RAM, projects like Folding@home, SETI@home, and all these distributed computing projects could have endless RAM.
:)
We could cure diseases by doing research on those systems!
First post
For those of you who don't have Adblock: Printerfriendly Version
I would think that, since we aren't even close to having boxes with more memory than we actively use, and RAM isn't growing any faster than we are using it up, that using it as a "disk" is even further off than the article would seem to imply.
Whale
One Terabyte ought to be enough for anybody.
Well, if the OS doesn't have to be *nix, you could run Windows Vista on it. Maybe.
See also, Windows 7 minimum requirements.
Is it just me, or do you hate it when people say "Is it just me..."?
the people who spell it "terrabyte".
Is that the recommended or minimum requirement?
I have 8 GB of RAM and rarely use more than four of it unless I'm playing a 64-bit game which eats it up (Crysis). Yes, I am running both 64-bit Linux and Windows.
One time, I opened up more than a thousand tabs in Firefox just because I could.
Colin Dean Go a year without DRM
One important thing to consider, is that if using a ramdisk for important stuff, what happens when the power dies?
For example, will the stuff synced from magnetic media be stored elsewhere? If so, what happens to the speed?
-B
...I might be able to run Vista!!! (I wonder how many people have written this prior to me already?)
It's a lot of RAM and at today's computational speeds, it's not likely that it could be used for anything beyond a RAM drive.
Is it too soon to think about how to use that much RAM? NO! It's the lack for forward thinking that caused a lot of artificial limitations that have been worked around in the past. We're still dealing with limitations on file systems and the like. I've got an old Macintosh that can't access more than 128GB or something like that because its BIOS can't handle it... I had to get another PCI controller installed to handle larger drives.
What it is time to think about is now to code without such limitations built-in. This would better enable things to grow more easily and naturally.
Our use of RAM as users expands about as fast as our ability to add sticks of RAM to the box. If the latter happened at 1000 times the rate of the former, then in 15 years let's talk about the luxury of wasting RAM as a disk mirror.
The System Tray would end up filling most of my dual monitors with all the crap Microsoft will inevitably find "necessary" to run the OS, leaving me with a small, 640x480 patch and approximately 640k for applications.
You wrote: "We haven't yet reached a point where systems, even high-end boxes, come with a terabyte of installed memory" - this is not true. Sun's E25k can go over 1TB of memory.....
char *ptr=malloc(1099511627776);
memset(ptr,1,1099511627776);
Linux gobbles free RAM to add to the buffer cache. This is already a large RAM disk with automatic sync. In embedded systems, you can even decouple the buffer cache from any physical media and just live in a variable size RAM disk, which means that Linux finally catching up to AmigaDOS.
I believe Sun has a server that can do 1TB of memory.
so now we can run solaris
that 640GB should be enough?
(Yes, I know he denies actually saying it, but we all know it's true anyway.)
That is all.
I'm using regular ramdisks initalized with data on bootup, composited with temporary, empty disk partitions using unionfs and synchronized back to their real partitions on powerdown, so that I have an extremely fast read time for most things contained on such a disk and conventional write-reread times. However, the problem is that for the upper layers of the kernel, those ramdisks are not RAM at all, just some other block device around - and when it comes to loading executables and libraries, they are copied, well, from memory to memory. What's missing is some way to tell the damn thing to use the data pages that already are there and issue a copy-on-write only when required. If this mechanism can do that - well, I'll be in as soon as they make it a little bit more fault-tolerant.
This is Slashdot. Common sense is futile. You will be modded down.
How is this different from the already existing kernel VFS buffer store, other than for the repopulation at startup?
Could you not accomplish this much more simply by having a process read all the blocks in a given block device at startup, thus faulting everything into the kernel buffer cache?
www.eFax.com are spammers
Just get rid of the external hard disk as a storage mechanism all together. Use the RAM as the 'hard disk', create a large L3 cache on the CPU that directly caches the RAM, and the L1 and L2 cache can cache the L3 cache. No problem.
The analysis thankfully makes a comparison to the IO caching that happens nominally. The distinction seems to be that this 'innovation' makes calling 'sync' a lie. That just doesn't seem like a good thing. It seems a roundabout way to make sync a lie as well.
I put in 16 GB of ram in a system, and operations are quite snappy, the disk cache happily filling and draining, and it feels more or less like a ramdisk system, once the data has been read into memory the first time on read operations. Sure, sync takes an ungodly amount of time, but that only happens when something wants to make damn sure the system is ready to tolerate an unfortunate event after something important happens.
XML is like violence. If it doesn't solve the problem, use more.
"You just need to believe in your battery, Linux and the hardware it runs on. Which of these do you mistrust?"
We have desktop systems now that can go up to 32GB RAM, so 1TB isn't that far off.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Current high-end server boards support up to 64GB of RAM (16 slots, 4GB DIMMs).
By Moore's Law, we should hit 1TB in a high-end server 6 years, high-end desktops (assume 8GB of RAM, currently selling for $180 CAD) in 10.5 years, and the average midrange desktop (assume 2GB of RAM, currently selling for $45 CAD) in 13.5 years.
We might be a while off in consumer applications, but for high-end servers, 6 years doesn't seem very far away.
Well I can do cock push-ups.
Anyone remember RAM disks from the DOS days? This was the same thing, when we had excess RAM, we would load files into memory. Next, I bet someone is going to tell me that thick-client is more efficient than thin-client...
Check out the specs on the Motorola (formerly BroadBus) B-1 Video Server:
http://www.motorola.com/content.jsp?globalObjectId=7727-10991-10997
Sounds like a good use for a terabyte of RAM to me.
Disclosure: I currently work for Motorola, but I don't speak for them, and don't have any involvement with this product beyond salivating over it when it was announced that we were buying BroadBus.
Ten years ago, my PC had 8 megs of system RAM. My laptop now has four gigs of RAM. In ten more years, I am sure we'll have a terabyte of RAM.
A NYC lawyer blogs. http://www.chuangblog.com/
If you are planning on having a few minutes' worth of UPS backup then why would you need to write to the hard drive continuously? Keep the hard drive spun down (saving power). If the system is being shut down, or AC power fails, then spin up the drive and make a backup of your ramdisk, thus being ready to restore when the power comes back up.
Next step beyond that: stop using a filesystem at runtime. Just assume your data can all fit in memory (why not, if you have a terabyte of it?) This simplifies the code and prevents a lot of duplication (why copy from RAM to RAM, just to make the distinction that one part of RAM is a filesystem and another part is the working copy?) But you will need a simple way to serialize the data to disk in case of power-down, and a simple way to restore it. This does not need to be a multi-threaded, online operation: when the system is going down you can cease all operations and just concentrate on doing the archival.
This assumption changes software design pretty fundamentally. Relational databases for example have historically been all about leaving the data on the disk and yet still fetching query results efficiently, with as little RAM as necessary.
Next step beyond that: system RAM will become non-volatile, and the disk can go away. The serialization code is now used only for making backups across the network.
Now think about how that could obsolete the old Unix paradigm that everything is a file.
Anyway this sync is great,
It's so delicious and moist...
"Given that the core components of an OS are only a few GB, even 8GB systems might be able to do this, today." - by 2nd Post! (213333) on Thursday March 20, @03:38PM (#22810564) Homepage They can, on Windows NT-based systems, since NT 3.51 iirc, in fact... done via SuperDisk &/or SuperVolume, by SuperSpeed.com (formerly EEC Systems):
http://www.superspeed.com/servers/supervolume.php
I wrote up an article for that companies' website whose ideas took them to a finalist position @ Microsoft Tech-Ed 2000-2002 iirc, in one of the harder (if NOT the hardest to win) ones to be in, SQLServer Performance Enhancement.
APK
P.S.=> That was while I was being paid to create their SuperCache/SuperCache II tuner code, which started out as a free addon to it, & then I sold they the code which made it up to 40% more efficient (because it reminded me of tuning DOS' SmartDrive, lol, & had parameterization possiblities for the driver init. stage)...
Anyhow, the article I wrote (for they, AND later, CENATEK, about their RocketDrive SSD) was a good side thing to "turn them on to" (back in 1996 in Windows NT-Pro Magazine no less to a GREAT review by Mr. John Enck, technical editor then & now (since they are Windows.NET magazine OR WindowsIT Pro mag now, not sure anymore)...
& it worked - for DATABASING people, & other things galore (serving up websites, etc. & just general HUGE reductions in latency, in almost anything you can imagine to apply them to, really)... apk
Don't worry about your 1TB RAM... Microsoft would have the right tools to overflow it by that time!
mmmmm.....
Geez. Why would I ever need it!?!
If you ever want a fast OS, run Windows 3.1 on a 300 MHz P2 with 64 Mb of RAM. Blazing fast.
Let's get to 128 Gb of RAM before we start pimping 1 Tb.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
The first thing I thought of was pr0n. Is that so wrong?
Well, there's spam egg sausage and spam, that's not got much spam in it.
The IBM System p model 595 can hold 2 TB of RAM with 64 processors. I just got done installing on 7 of these boxes which had 1 TB in each. These servers can run AIX or Linux, but you gotta use AIX if you need lots of memory in a partition. FYI !
- The Mad Duke
-The Mad Duke
Want to use a TB of RAM? It's simple - just install Vista and that terabyte'll be used up before you can say "640K ought to be enough for anybody" :)
Geez, I wrote a floppy disk cache driver as a programming homework exercise in the 1980s. Talk of re-inventing the wheel...
Excuse me, but please get off my Pennisetum Clandestinum, eh!
When I started my programming career (1997), my employer had 3-4 servers, the newest of which had a RAID array of Micropolis drives totaling a staggering 18GB for the volume. The older servers had 6GB and 9GB volumes. While we did have to take a bit more care then than now to conserve space, that was enough for an awful lot of tasks.
If I'm reading the specs right, you can now get parts for a PC with 12GB of RAM (mixing DDR2 and DDR3) from NewEgg for something on the order of $1000. While I wouldn't suggest making a file server that just works in RAM (what if you lose power?), what about databases? Modern database servers write to the transaction log (on disk) before they do anything else so that their caching logic can write the changes themselves to disk whenever it's convenient. Why not try a database where the tables themselves aren't on disk at all? Put BLOB fields into actual files, and keep the transaction log on disk (RAID 1), but otherwise the database only exists in RAM. If you need to restart, you just process all the transactions that happened since the last complete backup.
Now, this wouldn't be big enough for everything, but it would be big enough for an awful lot of jobs (stop and think for a minute about just how much information 12GB really is), and it would allow quite good performance on some pretty cheap hardware. And who knows? When you start wanting to support more than will fit in RAM, maybe virtual memory will turn out to be a better model than disk caching.
http://www.sun.com/servers/highend/m9000/
I can bucket sort over 1099511600000 integers in it's worst case run.
BSD is for people who love Unix, Linux is for people who hate Microsoft.
During games or analysis I could store the entire 3-6men endgame table bases in memory and get rid of the bottleneck that a HD is when doing a lot of searching in a 1.5 TB dataset. So yes, it could be useful to some people. Perhaps not mom and pop who check email, but researchers who crunch large datasets.
Perhaps its time to not make a hard distinction in software between RAM and disk. I know that RAM caching sort of does this, but software still assumes a difference between the two. It may be time to come up with a "generic storage model" of some sort that does not assume RAM or disk. This way when one or the other changes, or an intermediate option (flash RAM?) comes along, the software will be ready. Of course, there may be some overhead in putting an abstraction layer between storage calls, but as time goes on, we usually march up the abstraction ladder anyhow.
The closest thing I worked with to this was Clipper. It would automatically cache data tables in RAM if they fit, otherwise use regular disk-based indexing/searching (most RDBMS do this now, but it is hard "see" it happening because they're on a busy server in a different room). I just "talked" to the tables and didn't worry about whether they were using RAM or disk or a combo because the internals managed that. And they were pretty fast too if lots of a table could be cached.
Table-ized A.I.
Does this require multiple processes to run? From what I understand, current Linux kernels have a ~2GB process size limit.
Yes we have. You can buy a system with 8 terabytes of RAM
here
Although it is common to speak of "GNU Emacs", it has been revealed that it was intended to be "GNU/Emacs"; no, not in the same sense of GNU/Linux, but rather to speak of them being one and the same. All it is missing now is a kernel, but I'm sure something will show up to allow GNU/Emacs be a standalone operating system.
A fully caching file system that could be layered on top of your network or disk file system. Sun did this for dataless workstations and it worked pretty well.
Another historically interesting ram file system was the Amiga Recoverable RAM Disk. You coudl even boot off it.
Still think the floating point voxel octree version of Google Earth will use that memory before any ramdisk gets it.
Here are the details:
http://www.hp.com/products1/servers/scalableservers/superdome/specifications.html With up to 128 CPUs, 2 TB of memory, 16 hard partitions and 32 GB/s of I/O bandwidth... I did an evaluation recently with the sx2000 chipset, very cool stuff - but in my opinion Linux isn't quite there yet.
With the ability to take that 2TB of RAM, all hot-swappable, and run it in mirror-redundancy (1TB usable), you would have a very reliable and fast system.
Wouldn't this work with less RAM say 256-512MB and create a kind of virtual hybrid hard drive? That would really help the majority of users.
Althouth I really like Linux and the free software, I think that we all have to accept the crushing truth.
In these times it really doesn't matter if is launched KDE 35.0 or Gnome Vista, because while both environments (and others with less weight as IceWM) were worrying in confusing the user with a completely different aspect, Microsoft was consolidating his position as leader in the field of the operating systems of office, first with the operating system Windows XP (that have approximately 90% of the client operating system market) and with its advanced successor, the recently Windows Vista, that offers a new form to interact with its PC. Is faster, friendlier, and more secure.
The reality is that Linux has little to offer the inexperienced user. The same novice that is seen disconcerted by the impossibility to do a simple one copy-paste between QT and GTK applications. Go out and ask to the people how they install a program that does NOT have packages for its distribucción (because each one has its own packege system, completely incompatible with the others and that requires the use of complicated commands). Still the packages of the same format as RPM, they cannot be installed equally in Mandriva or Suse.
Then what we suggest to this user (that is just beginning in the Unix Word) is that he need to download the source code, go to the console, decompress it and compile it. How many they managed to do this? One of each a million, I have to say. We persist in THAT is the normal thing. ..nothing more further from the reality.
Explain him why in his Ubuntu, Kubuntu or Fedora cannot see many web pages: he must download the Flash and the Java plugin, in order then to install them with complicated commands. Also make him know that he won't be able to listen its MP3, WMA and WMV files. Tell to the flaming buyer of a new AMD64 how he can play flash games.A shit.
And the gamers? Obviously they'll return to windows, because even God can't use the hardware acceleration of the most modern graphics cards (besides, the drivers don't come in the distributions. ..becuase of the fucking freedom) and that games...just a few ones. By each Linux videogame we have 500 that run on Windows. And the few ones that run on Linux...Oh! Surprise!...Just Windows binaries on the CD, and you have to download the Linux version from a website. Finally the user return to the best option, the OS most used on home (all we know what OS is).
The proof of the free software failure is seen also in the professional world, either in areas like electronic design (doesn't exist anything similar to Protel), architecture (the standard CAD -all we know wich one-only works on Windows), web design (something similar to Dreamweaver? Don't mention something like NVU, that not only is full of bugs, but also just have the 5% of the Dreamweaver features. Neither Bluefish, Quanta or similars...no one would face a complex project with such a primitive tools). DTP? Scribus is a good try (very immature) but Quark or InDesign are far batter. Flash content creation (A standard, and a flash player installed in the 99% of PCs)? It cannot be done on Linux.
In the software development industry there's not a single decent RAD tool. Gambas seems to promise but for now is shit, Eclipse is a RAM eater (thanks Java) that only can be used with 2GB RAM, Kylix promised give the potential of Delphi to Linux, but it was discontinued because the developers hate to pay for licenses and they prefer to use a primitive tool, like KDevelop. And now that we talk about Borland tools, is not rare that programming gurus like Ian Marteens abandoned Delphi and C++ Builder and now prefer the most powerful system for software development: Microsoft Visual Studio.NET.
A computer game developer would never develop free (as in free spech) games, because they have to eat and there's not a business model compatible with free software. The Linux users don't want free (as in free spech) games, t
As can HP Superdomes. (I know for a fact there's a 1Tb one not far from me, 2Tb is possibly out there [the machine can do it, I just don't know personally if there's one extant.. surprise me if there isn't (see http://h20341.www2.hp.com/integrity/cache/342370-0-0-0-121.html) ]). It wouldn't at all shock me that IBM has machines in this class.
This whole discussion is so PC-centric it is hilarious. Oracle will find a way to make their SGA take 1Tb if you let them.
I don't surf the internet, the internet surfs me.
We haven't yet reached a point where systems, even high-end boxes, come with a terabyte of installed memory
FYI, the Sun M9000+ can be delivered with 2Tb of RAM which, should you so desire, can all be shovelled into a single domain chock full of Solaris 10 goodness.
I suppose I could perform a full scale impact analysis of the Titanic hitting an iceberg in NASTRAN and then perform the CFD analysis to determine how fast it sank based upon fluid ingress flow rate.
This is how Puppy Linux works, when running from the USB pendrive. Everything is in RAM, and saves to USB automatically every 30 minutes.
But the thing is so small, 512 Mb of RAM is usually enough. No need for a Terabyte...
IBM's just-announced z10 mainframe, with 1.5 TB memory.
Hi all,
That would be Daniel Phillips with two ells.
Regards,
Daniel
Have you got your LWN subscription yet?
Maybe a couple of beowulf clusters.
I have mod points and I am not afraid to use them.
I used to work on Linux at IBM, where we did have machines capable of running with a maximum configuration of 2 terabytes of RAM.
http://www-03.ibm.com/systems/p/hardware/highend/595/specs.html
Typically, those machines would be partitioned into smaller logical partitions (LPARs), and I never saw any machine that had a maximum configuration anyway. But supposedly someone does have a 2 terabyte machine running Linux.
So this isn't as far-fetched as one might think.
Sorry, but I've got you beat, sucker!
"Anyone who [rips a CD] is probably engaging in copyright infringement." - David O. Carson
How it seems to work:
Actual "ramdisk" -- that is, like /dev/rd -- that is, appears as a block device. You can run whatever filesystem you want on it, but it's still serializing and writing out to... well, RAM, in this case. No sane way for the kernel to free space on that "disk" that's not actually used.
How I wish it worked:
No Linux that I know of has used an actual ramdisk in forever. Instead, we use tmpfs -- a filesystem which actually grows or shrinks to our needs, up to an optional configurable maximum size. It'll use swap if available/needed. It's basically a RAM filesystem, instead of a RAM disk.
Even initrds are dead now -- we use initramfs. Basically, instead of the kernel booting and reading a ramdisk image directly to /dev/rd0, it instead boots and unpacks a cpio archive (like a tarball, but different/better/worse) into a tmpfs filesystem, and uses that.
So, how I would like this to work is, use a tmpfs filesystem -- as I suspect it will be faster, and in any case simpler, than a ramdisk -- and back it to a real filesystem on-disk. The only challenge here is that it's not as deterministic -- it would be more like a cp than a dd.
An even better (crazier) idea:
Use a filesystem like XFS or Reiser4 -- something which delays allocation until a flush. In either case, it would take a bit of tweaking -- you want to make sure no writes, or fsyncs, block while writing to disk, so long as the power is on -- but you'll hopefully already be caching an obscene amount anyway, so reads will be fast.
In this case, forcing everything out to disk could be as simple as "mount / -o remount,sync" -- or something similar -- forcing an immediate sync, and all future writes to be synchronous.
Conclusion:
Either of the two ideas I suggested should work, and could perform better than a traditional ramdisk. If it is, in fact, a simple disk-backed ramdisk (not ram filesystem), then it's both not as flexible (what if your app suddenly wants 50 gigs of RAM in application space?) and a bit of a hack -- probably a hack around traditional disk-backed filesystems not being able to take advantage of so much RAM by themselves.
In fact, glancing back at TFA, it seems there are some inherent reliability concerns, too:
Now, true, this should never happen, but in the event it does, the inherent problem here is that the ramdisk doesn't know anything about the filesystem, and so it doesn't know in what order it should be writing stuff to disk. Ext3 journaling makes NO sense for a ramdisk when the ramdisk itself knows nothing about the journal -- the journal is just going to slow down the RAM-based operation. Compare this to a sync call to XFS -- individual files might be corrupted, but all the writes will be journaled in some way, so at least the filesystem structure will be intact.
This gets even better with something like Reiser4's (vaporware) transaction API. If the application can define a transaction at the filesystem level, then this consistent-dump-to-disk will happen at the application level, too. Which means that while it would certainly suck to have a UPS fail, it wouldn't be much worse than the same happening to a non-ramdisk device, at least as far as consistency goes. (Some data will be lost, no way around that, but at least this way, some data will be fine.)
Don't thank God, thank a doctor!
my wife just got a new Vista Laptop and against my better judgment, I recomended that one as the hardware was much better then the same priced XP laptop. So when we had it at home with all it's 2 gigs of memory, It did not have enough memory free to install the printer drivers with nothing else running.
I haven't seen anything like this since MS orfice on a 486.
and all this talk of addressing 1 Terabyte has got to bring to mind, "Why would anyone need 1 Terabyte of Ram?" (sarcasm)
You mean what IBM's been doing forever?
http://en.wikipedia.org/wiki/Single_level_store
Actually, Some Linux Systems are already dealing with RAM on the Terabyte level.
Please keep in mind, that the larger the memory pointer, the slower the program.
When the first linux patch came out to use more than 1GB of memory, I applyed the patch, and experenced a significant performance hit, in terms of speed. It was a patch to make SAP run, and a gargantian database like that just goes faster, if its all loaded into RAM, so it becomes a bit better slug, instead of just a ugly slug. ( Do you get the feeling I dont like SAP? ). Suffice to say, the new extension, and the patch before it, are for specific tasks that can take advantage of it.
If you have a ram intensive task, like SAP, its going to show some improvement. If you have a disk intensive task, or a processor intensive task, its probibly going to hurt your performance. Hence, GNU/Emacs, is probibly going to run slower. ( dear god, I think I have the 0.1 distrubution mag tape. )
Windows with 4GB is slower, except for certain operations in Photoshop, and thats both the result of the coagulated slag of spegetti code, and the p*ss poor scheduler. I am going to get a look at the new memory fixes and see how well they work on the big ram box.
Several months ago when hard-drive-speed flash disks were not readily available and I was thinking how to build a no-moving-parts gamebox, I was considering making my fileserver a RAM server as well, export the RAM as disk over the network, then install the rest of the machines at home on iSCSI devices going over this network.
Ironically, problem is not the RAM. You can easily buy 32-64GB for sane amounts of money in 2GB DDR2 sticks.
Problem is cheap commodity motherboards you can put so many sticks in.
IDEA:
PCI Express 16 board with many many many laptop-class SODIMM DDR2 slots. As many as you can fit. Mount them diognally over each other, both sides of the board. Just get as many of them on as you can. Sure the bus (even a PCI-Express 2.0 or 3.0) will limit the aggregate speed to the PCI Express speed of several gigabytes per sec, but this would facilitate cheap RAM servers (with disk-sync) with multiple other machines on the network using the RAM server as their disk and bottlenecked primarily by the underlying gig ethernet.
-
Are we assuming that the time required to write to backing store increases directly with the quantity of RAM? Or is it possible that with a TB of RAM, the "write to backing store" process might take longer than the available battery life?
Reverting to a low-performance mode and scheduling disk activity through the end of battery life might not be the smartest move, particularly if the user is sitting there with knowledge of a particularly important data item that they want to commit to disk in the 10 minutes they have.
-Graham
ps. that was sarcastic
When I have a kid, I want to put him in one of those strollers for twins and then run around the mall looking frantic.
and Sun's X4600 ships with Linux (RHEL or SLES, if you don't like Solaris) and up to .25TB already, in a 4U box. such a sweet machine: 8 Opterons, 16GB per core, GNU/Linux ...
You better skip the memory test.
now we need to go OSS in diesel cars
Texas Memory Systems RAMSAN
http://linux.slashdot.org/comments.pl?sid=494546&cid=22811144
(There is TRULY nothing as flattering, as imitation!)
APK
Once you see the size of some mini-atx boards, it's not inconceivable that you could put 5 cpu systems in one tower case and have a 1TB RAID-5 system in there also.
You know, in the old NeXT Cube, you could install up to 4 motherboards which I think were interconnected over ethernet. The foundation of NexT OS allowed for processor sharing over the network, so you could kind of have slow multiprocessing.
Seth
$5 / month hosted VPS on linux = awesome!
We have an IBM P-series box with ~0.25Tb using about 80Gb of that for RAMdisks for DB temporary space.
Even in the Intel world, HPs new DL785 can do 0.25 Tb now and soon to do 0.5Tb http://h18004.www1.hp.com/products/servers/proliantdl785g5/index.html
This sounds like the wrong solution to a very simple problem: caching.
Why do hardcore people use ramdisks ? Because disk caches are stupid. Why not make the cache smarter ?
I'll give an example of what I do with a ramdisk: I copy various video files to it, do my editing, then save the finished work back to a physical disk. These are all things a good disk cache could manage with ease, but it doesn't. Why not ? Because it evicts my precious video files in favor of less important data. What if my encode is going to take a few hours and I'd like to surf or play a quick game ? All those stupid little files will kick out my "old" video files.
If we could ask the caching system to hold a certain file in memory until released, we could use the cache as a transparent ramdisk, and all would be well. Corollary to this is the ability to specify what NOT to cache. If I'm playing a movie, burning an ISO image, or running a backup, don't cache it! - I won't need it after I'm done. I'm certainly not against caching something if there's plenty of free memory, but there should be a priority system that both the application and the user can control. Make it work transparently for most people, and then allow the power mongers to exert manual control where appropriate.
-Billco, Fnarg.com
Thats the only reason i can see to have that much ram. Unless our current crop of so called programers bloat their code to fill the expansion for yet another worthless feature.
---- Booth was a patriot ----
Well, closer to 1.2 TB. 40 systems with 32Gb each. Want to know what it's used for? Disk cache... It's virtually all I/O buffer.
All RAM is used as cache anyway. When an application allocates some RAM, it's in lieu of directly manipulating the permanent (disk) storage because it's horribly horribly slow. That's really an operating system failure. Network file systems, disk, RAM should all be completely transparent, the OS should abstract all that away and allow application programmers to handle it simply as storage.
Deleted
I seem to recall the ability in Mac OS 7-9 where you could create a RAM disk out of a chunk of your unused memory. There were even programs that would automatically store the contents to disk on shutdown and restore it on startup. How is this new, exactly?
today is spelling optional day.
From the page... 8GB to 1TB of DDR2 SDRAM running at 533 MHz or up to 2TB of DDR2 memory running at 400 MHz
You can already buy computers with 2 TB of ram, silly reporters/bloggers and their outdated articles.
http://h20341.www2.hp.com/integrity/cache/342254-0-0-0-121.html
Or you can buy an HP SuperDome with up to 2TB of RAM.
- Necron69
If I recall correctly, the United States Government installed several large-memory computers systems (in the Terabyte range), for the purposes of holding single instances of very large databases, used for a (very) rapid search by many many stakeholders (I think the Department of Homeland security was the owner, with CIA, FBI, NSA, etc. as stakeholders). It was supposed to be able to handle 100,000 full-space queries per day, and all data was in ram.
www.isoHunt.com
I looked at doing battery backed RAM cache back in the early nineties. At the time, NFS servers were either slow or expensive (Auspex) and it was pretty obvious that one of the things that really slowed them down was the NFS requirement to commit changes to disk before acknowledging the write. So, battery backed RAM write cache!
NetApp had the same idea and brought it to market. If you look at the design of WAFL (NetApp's Write Anywhere File System), it is basically dependent on having a large, stable RAM cache. Doesn't work if the RAM cache isn't stable.
The question that Daniel (the author of the patch) posed was "You just need to believe in your battery, Linux and the hardware it runs on. Which of these do you mistrust?" The answer is - all three. NetApp delivers a quality product that is engineered to work the way it needs to. Trying to get it to work with a bunch of off-the-shelf stuff not designed to do it is a recipe for disaster.
Chip design apps (and I imagine a number of other ones) will likely need 1TB in a year or so. I already know of several companies using boxes with 64G of RAM and the apps are consuming like around 40-50 of it. Designing (& analyzing) those multi-billion transistor designs eat memory. My sw package was designed to allow for ~80G per cell in the hierarchy. Since my system allows 128K cells, thats about 10TB of RAM that could be used. I have even wondered if the 80G limit needs to be increased in the near future.
Speaking of voxels, octrees, and a terabyte (TiB that is; 2^40 bytes):
...
Cosmology simulations take as much memory as you can throw at them. You think a few exabytes is big, but that's just peanuts to space!
This one is one is the most complex (by most measures) cosmological simulation ever run, using just over 10 billion particles and nearly the entire terabyte of the computer's available memory:
http://www.mpa-garching.mpg.de/galform/millennium/
They ran it on a 512-CPU IBM p690, which took about 28 days of parallel runtime. (2^40) / (10^10) ~= 100 bytes per particle, which is high by maybe 50% but accounts for overhead and is a reasonable value. The paper reports ~200 Gflops sustained, which is certainly memory bound in any distributed N-body simulation, giving ~5*10^17 total floating-point ops.
They only did total output at 64 output timesteps because each of those took about 300GB for ~20TB total, which filled up a decent sized storage rack 3+ years ago (and still). The contemporary highest-detail galaxy clusters were modeled with as many as 3 million particles, but the simplest interesting "structures" (the dark-matter halo detection threshold was 20 particles) contained 20~100 particles.
Now for the cool stuff:
- there are ~400 billion galaxies in the observable universe, even if galaxy surveys (Sloan, etc.) catalog only a small fraction of them
- reasonable (i.e. "useful") resolution for typical structures of interest (quasars, typically) is ~1~10 million particles; better if you can get it
So:
You have to model dark matter halos with useful precision. Even if you are satisfied with modeling whole galaxies as point-like objects:
(4*10^11 galaxies) * (100 bytes/particle) = 4*10^13 bytes ~= 40 TB
(~10^12 CDM particles) * (100 bytes/particle) = ~100TB
=> allowing a little slush, 200TB of RAM would get you some very valuable theoretical simulation data of an object/construct/whatever that approaches literally the size and complexity of the observable universe at a galactic scale. More memory will just make that even better, too.
Desktop memory doubles say, every 2 years; look at the typical "consumer" systems the last few years:
1994: 16MB (P1... wow; 16 is a little high for '94 I guess)
1996: 32MB
1998: 64MB
2000: 128MB
2002: 256MB
2004: 512MB
2006: 1GB
2008: 2GB
We want to see when we have about 100,000 times as much memory as now, which is about 16.5 doublings, each of which take around 2 years, so we should see this some time around 2035-2040 on consumer grade machines. A purpose-built supercomputer can contain, say, 1000 times the consumer amount, so today's 4~50TB supercomputers need to double, drumroll.... 2~5.5 times. The top supercomputers will probably have 200 terabytes of ram within 2 years, and the lowly supercomputers cosmology simulations have to settle for will probably have that within 10-12 years; i.e. by 2020 (yeah, it's getting closer!).
It may even be possible to do quad-precision floats in hardware, which would be beneficial for cosmological simulation (or any N-body simulation), and that will cost a doubling too. And after a petabyte or so, the resolution gets *really* interesting because you can start modeling macro-scale systems of micro-scale (you know, individual atoms or stars) as long as you know the force laws, and you can start finding those out numerically if you don't. So there's plenty of use for *truly* astronomical, dizzying amounts of memory way, way beyond one measly terabyte.
Didn't Microsoft already do "proof of concept" on howto use a Terabyte of RAM when they booted up Vista?
I really don't like the idea that this is racing with the UPS. When the battery gets old it's ability to hold a charge drops and a timeout that was sufficient in the old days won't be now. I've also had situations where the battery was supposed to tide you over till the generator kicked in; but the system was never tested for the generator failing at exactly the wrong moment.
I'm pretty sure the answer to this is a simple generation number on the blocks so you can use a database checkpoint scheme.
1) Every write to the ramdisk brands that block with an ever increasing number (transaction number).
2) When you initiate a checkpoint the driver finds all blocks that have changed since the last checkpoint and writes them to a "physical log", followed by the checkpoint marker.
3) The same blocks are then written to the actual disk area; nb application writes to these blocks must be diverted.
4) The "physical log" is cleared.
5) Block diversions from (3) are cleared.
Using this well known scheme the disk is always either in a consistent state or easy to get there.
Note the "diversions" may mean that clean blocks must be discarded from the ramdisk/cache to prevent the applications being blocked by the checkpoint.
If you want the ability to have the system 'roll forward' after a crash you need a transaction log where the updates are written to the log as they happen, because this is linear it happens at the maximum transfer rate of the disk; but it's still limited in performance.
This also looks a lot like doing a backup from a volume snapshot.
Running Windows 7?
-Darkshadow (There was a thing called Heaven; but all the same they used to drink enormous quantities of alcohol.)
That reminded me situation I saw few years ago. New server arrived, with 8 GB of RAM. After few days of use all disk activity almost ceased. Under load systems did some writes sometimes. *Only* writes. No reads from disk. It was little puzzling. Under closer inspection it became obvious that all disk content was cached in RAM. There was about 4GB data on server disks (including operating system) and all of this was cached in RAM. Only changes were written to disk.
This was first time when I saw linux "free" showing 2-3GB of literally free memory. Which couldn't be used for disk cache, because there wasn't any more data to cache.
:wq
This is a good example where people and the market do not understand how far large system and OS technology has reached. Sun has been selling and their customers have been running servers with 1TB since the E25K which came out years ago. Present Sun M9000 servers can have up to 2TB of RAM. Solaris has no problem manging this with 128 cores. Sun servers and Solaris is not stopping at these limits. More to come. Some OSes and perceptions need to catch up. NB Solaris is also open (OpenSolaris) and you can run it on a laptop and PC with 200MB of RAM. Solaris is supported on servers from HP, IBM and 1000's of others.
Oh, wait, that was 640 KB when he said this back in '81.
Considering how software tends to keep up (and usually surpass) hardware, as soon as one hardware "bar" is set, software will find some way to surpass it.
And I bet not too far into the future, we'll be talking about what to do with one petabyte of RAM.
Funny, I was benchmarking an SGI Altix with 1TB of RAM back in 2005. What's this "not available yet" nonsense?
-- *My* journal is more interesting than *yours*...
The question should be not WHAT to fill it with, but how to read/write gargantuan amounts of data quickly.
Upward mobility is a slippery slope - the higher you climb the more you show your ass.
Use Vista to write "Hello World!" in .NET.
http://linux.slashdot.org/comments.pl?sid=494546&cid=22811144
(Again - There is TRULY nothing as flattering, as imitation!)
APK
This is a good example where people and the market do not understand how far large system and OS technology has reached. Sun has been selling and their customers have been running servers with 1TB since the E25K which came out years ago. Present Sun M9000 servers can have up to 2TB of RAM. Solaris has no problem manging this with 128 cores. Sun servers and Solaris is not stopping at these limits. More to come. Some OSes and perceptions need to catch up. NB Solaris is also open (OpenSolaris) and you can run it on a laptop and PC with 200MB of RAM. Solaris is supported on servers from HP, IBM and 1000's of others. Open source Solaris OS on a Open source SPARC chip is already there.
you could use it, for instance, to seed the storage of cookies in real memory...
if this is supposed to be a new economy, how come they still want my old fashioned money?
and the M series from Sun has already been able to do 2TB of memory
http://www.sun.com/servers/highend/m9000/
Just imagine how fast my text game of Zork I would run!
My current notebook, about 2 years old, only has 512MB, because our corporate IT droids didn't think it needed more. Of course, IE didn't have tabs back then, and they weren't running Firefox as their browser. Now that RAM comes free with breakfast cereal (at least if you eat breakfast at Fry's) I suppose I should just go upgrade it myself, but I assume that if I do that they'll upgrade our machines before I've used up $50 worth of Firefox going faster.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Vista supposedly knows how to make more intelligent use of flash as a middle-speed storage tier; good thing, given that it's apparently a memory hog. I don't know if Linux has explicit plans for it, but you could probably hack it to do some thing useful, but even just using one drive for the OS and another for swap could be a big help.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Now, of course, it's hard to get current memory as small as 128MB, and the $20 flash drives at my local pharmacy are bigger than the disk drives on my VAX were.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I don't have much argument with your conclusions, but you got the history wrong - (the "original") VI came before GNU Emacs.
SGI have been doing 128TB for ages - http://www.sgi.com/products/servers/altix/4000//
Here's a 4.1TB system out there (i.e. not just a number on a white paper): http://www.sgi.com/company_info/newsroom/press_releases/2006/september/lite.html/
SGI Altix 4700 goes upto 128TB. Now continue discussions of what to do with it.
1TB of RAM isn't for consumer PCs, so I'm not sure why everyone is talking about web browsers, emacs, etc. Maybe I didn't read deep enough into the replies, but did nobody event mention DB2 or Oracle? 1TB systems already exists. Spend some time surfing this website: www.tpc.org. Its a commercial benchmarking website for high-end database systems. You'll find several systems that are using 1TB+ of memory. Walmart, AT&T, NSA, etc all have databases with >= 100TB of data. Systems of this size DO require that much memory. The key take away from this article is that Linux is attempting to compete in this space - its already behind the proprietary UNIX systems.
and for your brief rant against teh average
you seem to imply that most
Do you want your ram to sit idle the rest of the time, and have your hard drive grind away because
and no, we dont want our memory wasted... which is why most of us run linux (or at least xp rather than vista), because the OS does not require as much memory, again, allowing for a greater percentage of the memory to be free for general use rather than backend stuffs, and (in the case of linux, not xp), it uses whatever is free after the committed memory for cache and whatnot...
so in a short, you seem to be criticizing the average
i dont think i said that as clearly as i could have, but i think you get the point. also, i may have completely misunderstood your post or how the different OSes manage memory (im a bit of a n00b), so *to all
01001010