Author Topic: In search of ... RAMdisk opinions (Read 37018 times)

barney · « **on:** September 22, 2012, 11:48 PM »

Just got back from an alcohol-fueled conversation with some compatriots about RAMdisks. There were four (4) of us, and I think there were six (6) opinions voiced (I said it was alcohol-fueled

).

At any rate, it got me to wondering whether a RAMdisk is really effective anymore. Made heavy use of them back in the DOS days - TSRs and RAMdisks made things much faster and more convenient. However, I've not used such in probably two (2) decades.

One (1) of us was a proponent of RAMdisks in Windows for the temp files that Windows uses. Another agreed, to some extent, but thought the swap file was a better usage. No. three (3) thought running specific apps there was a better usage. (I didn't get to say much, 'cause I was the designated buyer $:-\$ , and it was a very thirsty conversation

.)

Anyway, now that I'm in a thimk mode - and semi-sober - I'm wondering how the rest of you feel on the topic. Would you use? If so, what would be your preferred usage? And is there a particularly good - or bad - implementation for the purpose? (I can remember some real stinkers in my DOS days

.)

Renegade · « **Reply #1 on:** September 23, 2012, 01:12 AM »

Anyway, now that I'm in a thimk mode - and semi-sober - I'm wondering how the rest of you feel on the topic. Would you use?
-barney (September 22, 2012, 11:48 PM)

Well, being semi-sober is a serious problem. I'd recommend against using any of those candy-ass little pint glasses and get yourself a respectable flower vase. Good for holding about a pitcher of beer, or a pitcher of scotch. Either way, you're in better shape than those pint-holding posers.

Do get a glass or crystal flower vase though, and not a ceramic one -- let's people see just how serious your ~~alcohol problem~~ thirst is. But don't call it a 'flower vase'. Instead, call it something a bit cooler, like, "this is my not-candy-assed beer glass, you pansy!"

Insults at the end always sound cooler too. South Park has many good ones that you can use for inspiration:

NSFW

Donkey-raping shit-eater
Transvestite donkey-witch

Do try to keep it as plain as possible. There are ones out there that look identical to pint glasses, but just much bigger.

Anyways, that should help solve the unwanted-sobriety problem. Let me know if you need more help there as I am quite the expert on the topic.

For RAMdisks, I don't use them as computers now as so fast, and I have an SSD, so there's not much point. I'm probably of less use to you in that area.

EDIT:

Back to the real problem here... This is what I mean:

nosh · « **Reply #2 on:** September 23, 2012, 01:50 AM »

HAHAHAHA!

SQUIDMAN · « **Reply #3 on:** September 23, 2012, 02:01 AM »

I like the concept of RAMdisk or RAMdrive read a brief article in I believe PC World. But when I tried finding out more info all my tech friends didn't really know that much. I think the article said it was 10 times faster than a SSD drive, but since I never used it, wasn't sure how to make it work with a program.

Just deep down like the idea.

40hz · « **Reply #4 on:** September 23, 2012, 02:08 AM »

RAMdisks have their place although they're far less important or necessary than they used to be thanks to cheap RAM, faster drives, and multicore processors

They still find good use on a busy server when you have some running application with a very active log or busy temp caching requirement. But now, with affordable SSDs (which I will go on record saying I still don't sufficiently trust for anything important) it's become fairly moot. At least as far as workstation use is concerned.

Just my

40hz · « **Reply #5 on:** September 23, 2012, 02:20 AM »

wasn't sure how to make it work with a program.
-SQUIDMAN (September 23, 2012, 02:01 AM)

You generally just point where your program looks for its datafiles to the RAMdisk and cut the HD out of the equation.

Since nothing goes out over the drive's databus you're operating at close to systemboard speed for data I/O. There is some extra system overhead involved to administrate the RAMdisk. So it isn't at full system speed. But it is still very very fast.

Caveat: some improperly coded applications don't handle speed all that well and may become unstable when using a RAMdisk as opposed to a physical HD. Rare. But it does happen.

Renegade · « **Reply #6 on:** September 23, 2012, 02:55 AM »

Caveat: some improperly coded applications don't handle speed all that well and may become unstable when using a RAMdisk as opposed to a physical HD. Rare. But it does happen.
-40hz (September 23, 2012, 02:20 AM)

I'm curious - how would you manage that? I mean, manage to get a program not to work there?

I'm still curious, so going to give the freeware version here a shot:

http://memory.datara...ces/software/ramdisk

4 GB is lots. I can't see needing more unless you're doing some pretty heavy lifting, though programs like Photoshop and video editing can easily chew that up... regular use? Seems like tonnes.

Shades · « **Reply #7 on:** September 23, 2012, 06:58 AM »

I believe there was a discussion/thread before this one here on DC with regards to RAM disks. As this one also describes how to defeat man´s greatest enemy, called: sobriety, I´ll guess its warranted.

For me the following concept is interesting though. Say I equip an 32-bit OS with 8GByte of RAM. The first 4GYte is then usable for Windows. The remaining 4GByte would ideally serve as RAM disk (with no possibility of the OS stealing any capacity away from the RAM drive).

And this would be the thread I was talking about.

40hz · « **Reply #8 on:** September 23, 2012, 11:09 AM »

I'm curious - how would you manage that? I mean, manage to get a program not to work there?
-Renegade (September 23, 2012, 02:55 AM)

I don't remember the exact names of the apps. They were both mid-tier multi-user accounting/CRM applications used in the magazine and publishing industry. I tried moving certain data files into RAMdisk to speed up user searches and queries.

And...yikes!

Both apps experienced record corruption problems once RAM disks were introduced into the mix. I suspect something in the code encountered timing issues with the file handles or record locks. Either way both experienced similar problems. On exit from certain modules, the systems would throw a record or header exception about one time in four.

Fortunately, the internal data integrity checks did catch and fix (or at least move) the bad records so it wasn't like it was a full database corruption issue.

When asked, both devs said that RAMdisks were "not recommended or supported" so I'm guessing we weren't the only users that were having problems with that. Once we moved the data files back onto a HD everything worked perfectly.

f0dder · « **Reply #9 on:** September 23, 2012, 11:45 AM »

I don't remember the exact names of the apps. They were both mid-tier multi-user accounting/CRM applications used in the magazine and publishing industry. I tried moving certain data files into RAMdisk to speed up user searches and queries.
-40hz (September 23, 2012, 11:09 AM)

Sounds like badly programmed software.

Since the thread that Shades mentioned, I've upgraded my main system to 16 gigabytes of RAM, and my permanent %TEMP% ramdisk is now 1gig... plus I have the option of creating "plenty big" temporary ramdisks. I used an 8gig ramdisk while rebuilding my rt7-stripped-down windows ISO, and it cut down on the time spent on rebuilding quite a bit.

40hz · « **Reply #10 on:** September 23, 2012, 01:39 PM »

Sounds like badly programmed software.
-f0dder (September 23, 2012, 11:45 AM)

Agree. Sad thing was they were both fairly popular in their industry. Or so I had been told.

With one package, there was a lot of behind the scenes remote-in sessions to fix things by the devs too. They even requested formatting the server it ran on to use a specific cluster size under windows. All well and fine I suppose...since there are situations in database design where it could make sense to do that. But for anything written after 1990? C'mon guys!

f0dder · « **Reply #11 on:** September 23, 2012, 02:16 PM »

They even requested formatting the server it ran on to use a specific cluster size under windows.
-40hz (September 23, 2012, 01:39 PM)

Say... what?

Might make sense to offer that as a performance tuning advice, but... as part of problem resolution? W T F? Also, it really shouldn't be necessary for performance tweaking, unless they're retards and don't do any kind of pre-allocation.

Pray tell, what software package or company name? Sounds like something to stay waaaaaaaaaaay clear of.

Steven Avery · « **Reply #12 on:** September 24, 2012, 04:59 AM »

Hi,

I've noticed some people place an emphasis on placing temp file directories in ramdisk. This might make sense, since there is nothing there to lose. Although the advantages of just that element might be quite limited.

If you are updating your Linkman data in a Ramdisk, and the power goes off (or the OS locks up) then it seems like all the work that was done since the ramdisk loading will be lost. (If there is a periodic save, that can develop its own concerns.) Isn't this always one potential problem ?

Steven Avery
Bayside, NY

Shades · « **Reply #13 on:** September 24, 2012, 06:55 AM »

@ Steven Avery:
Yes, but that situation is not much different without using a RAMdisk. Actually, when the power fails and the OS was just writing to disk, I rather loose the work that has been done (RAMdisk) than potential file corruption (hard disk), which can have all kinds of "weird" effects and the (obligatory) CHKDSK takes time to complete as well.

40hz · « **Reply #14 on:** September 24, 2012, 08:05 AM »

I've noticed some people place an emphasis on placing temp file directories in ramdisk. This might make sense, since there is nothing there to lose. Although the advantages of just that element might be quite limited.
-Steven Avery (September 24, 2012, 04:59 AM)

There were a couple of discussions touching on this topic previously that might be worth a glance. The XP thread (thank you Shades

) is here. The Win7 thread is here.

----------------------

Every time is see a discussion like this I keep wishing we had a more formal tech KB at DoCo, Something along the lines of a nicely done wiki would be good. There is a deal of good information lurking down in the forum threads just waiting to be mined.

tomos · « **Reply #15 on:** September 24, 2012, 08:54 AM »

Every time is see a discussion like this I keep wishing we had a more formal tech KB at DoCo, Something along the lines of a nicely done wiki would be good. There is a deal of good information lurking down in the forum threads just waiting to be mined.
-40hz (September 24, 2012, 08:05 AM)

+1

Nod5 · « **Reply #16 on:** September 24, 2012, 01:53 PM »

For Windows 7 I recommend ImDisk. It is free and just works.
http://www.ltr-data....pencode.html/#ImDisk

barney · « **Reply #17 on:** September 24, 2012, 02:08 PM »

Every time is see a discussion like this I keep wishing we had a more formal tech KB at DoCo, Something along the lines of a nicely done wiki would be good. There is a deal of good information lurking down in the forum threads just waiting to be mined.
-40hz (September 24, 2012, 08:05 AM)

Sure gets my vote

. One (1) of the biggest problems I have here is finding whether a topic has already been covered $:-\$ .

40hz · « **Reply #18 on:** September 24, 2012, 02:26 PM »

Every time is see a discussion like this I keep wishing we had a more formal tech KB at DoCo, Something along the lines of a nicely done wiki would be good. There is a deal of good information lurking down in the forum threads just waiting to be mined.
-40hz (September 24, 2012, 08:05 AM)

Sure gets my vote . One (1) of the biggest problems I have here is finding whether a topic has already been covered $:-\$ .
-barney (September 24, 2012, 02:08 PM)

Fortunately, at DoCo we don't get too many "forum-cops" or "discussion historians" who just loooove to point out there's already been a thread about that "new" topic you just posted.

Steven Avery · « **Reply #19 on:** September 24, 2012, 02:40 PM »

Hi,

@ Steven Avery: Yes, but that situation is not much different without using a RAMdisk. Actually, when the power fails and the OS was just writing to disk, I rather loose the work that has been done (RAMdisk) than potential file corruption (hard disk), which can have all kinds of "weird" effects and the (obligatory) CHKDSK takes time to complete as well.
-Shades (September 24, 2012, 06:55 AM)

I frequently (once or twice a day) do hard reboots, just to save time, and never have a corruption problem. (Granted, sometimes I just do a Firefox reboot, since the 100 windows with some PDFs and plug-ins galore is the main slow-down.) I also occasionally have OS lockups and never have corruption. (I do try to make sure not to have the same files open by two users on the puter, which can be problematic.)

I use Linkman as my example. I have it set to do backups every fifteen minutes or so and I am adding work throughout the day. Losing fifteen minutes of work frequently is unacceptable, and generally after the reboot I reload the live data .lmd file. Occasionally for some reason the last backup is bigger, and I use that. For months now I have not lost a smidgen of data, afaik, but I do check to make sure after the reboot that the .lmd file is big file. Its complicated.

With a ramdisk it is pretty obvious that I will frequently lose the differential from the last backup which could be maybe five urls (there is research involved for writing on Bible issues) and some modifications . That loss is a no-go, especially as this is the current, active work. Any such loss is very annoying (I used to have it more frequently before I closed the gap.) The only way it could work with a ramdisk is to take hard reboots off the table, but even then I will have loss on the approximately weekly OS stoppage-lock. Where the CPU is wild and the living is easy.

Thus I would not find the ramdisk acceptable on my most active data file. That is why I wonder if it is worth the effort for the temp files, where I do not care about losing data.

Steven

f0dder · « **Reply #20 on:** September 24, 2012, 02:59 PM »

I frequently (once or twice a day) do hard reboots, just to save time, and never have a corruption problem. (Granted, sometimes I just do a Firefox reboot, since the 100 windows with some PDFs and plug-ins galore is the main slow-down.) I also occasionally have OS lockups and never have corruption. (I do try to make sure not to have the same files open by two users on the puter, which can be problematic.)
-Steven Avery (September 24, 2012, 02:40 PM)

You're joking, right? Please tell me you're joking.

NTFS is relatively resilient, but doing hard reboots like that is asking for a disaster. You might not be seeing all-out catastrophic filesystem bomb-out, but isn't the worst kind of corruption is the kind you don't discover until it's crept into your backup archives?

Thus I would not find the ramdisk acceptable on my most active data file. That is why I wonder if it is worth the effort for the temp files, where I do not care about losing data.
-Steven Avery (September 24, 2012, 02:40 PM)

In my experience, yes. I wouldn't be running important important data on a ramdisk, at least not without an UPS, but it's fine %TEMP% and firefox profiles - add a backup program works on file change notifications instead of stupid timer intervals, and you're pretty well off for not highly critical data.

barney · « **Reply #21 on:** September 24, 2012, 03:26 PM »

Well,

The concensus - if you can get a bunch of drunks to agree on anything

- of our discussion was that a RAMdisk for temporary files and another for the swap file was probably the best way to go. Nothing lost in case of a hard shutdown or system crash

- assuming, of course, that work was properly saved in process

.

f0dder · « **Reply #22 on:** September 24, 2012, 03:32 PM »

of our discussion was that a RAMdisk for temporary files and another for the swap file was probably the best way to go.
-barney (September 24, 2012, 03:26 PM)

Using a RAMdisk for swap has one acceptable use case: a system with >4GB RAM running a 32bit version of windows, where windows itself cannot access the >4GB ram. Otherwise, it's plain idiotic - the RAM you're swapping to would have been better spent serving memory requests instead of swap. Better get enough RAM and disable the pagefile altogether.

And in the situation where you have >4GB ram installed in a machine - why the heck aren't you running a 64bit OS then? :-)

40hz · « **Reply #23 on:** September 24, 2012, 03:39 PM »

I frequently (once or twice a day) do hard reboots, just to save time, and never have a corruption problem. (Granted, sometimes I just do a Firefox reboot, since the 100 windows with some PDFs and plug-ins galore is the main slow-down.) I also occasionally have OS lockups and never have corruption. (I do try to make sure not to have the same files open by two users on the puter, which can be problematic.)
-Steven Avery (September 24, 2012, 02:40 PM)
You're joking, right? Please tell me you're joking.

NTFS is relatively resilient, but doing hard reboots like that is asking for a disaster.
-f0dder (September 24, 2012, 02:59 PM)

+1 x 1000!

Unless you have a genuine virus or worm running completely amuck, or you see smoke, it's generally not a good idea to do a shutdown to "fix" a problem. Like airliners, the most likely time to experience a catastrophic system failure is on start-up or (to a lesser extent) on shutdown.

You might not be seeing all-out catastrophic filesystem bomb-out, but isn't the worst kind of corruption is the kind you don't discover until it's crept into your backup archives?

Which you'll usually only discover after you reboot and realize things are no longer working.

P.S. If I had a dollar each time a critical backup (made using standard "enterprise grade" backup software) ended up being corrupted (and sometimes not recoverable) I'd have enough money to take a not overly modest vacation on the Continent.

barney · « **Reply #24 on:** September 24, 2012, 04:13 PM »

And in the situation where you have >4GB ram installed in a machine - why the heck aren't you running a 64bit OS then? :-)
-f0dder (September 24, 2012, 03:32 PM)

I am

.

Using a RAMdisk for swap has one acceptable use case: a system with >4GB RAM running a 32bit version of windows, where windows itself cannot access the >4GB ram. Otherwise, it's plain idiotic - the RAM you're swapping to would have been better spent serving memory requests instead of swap. Better get enough RAM and disable the pagefile altogether.
-f0dder (September 24, 2012, 03:32 PM)

Wrong

. Well, presumptive.

I know a bunch of folk still on 32-bit systems, several still on Win98

, one (1) old geezer still running Win3.1

. (They did upgrade hardware, to some extent, just not software.) For these folk, the RAMdisk question can be important. They don't want to upgrade the OS - they're comfortable with what they have and have no desire to lean a new OS - but they do want to maximize wherever possible. These are not the cognoscenti, just average folk who have other things to do than live in our hardware/software world, and they have other priorities than getting the latest, greatest hardware/software. But they do want performance when they're here.

Hence, the RAMdisk question.

On another note, the machine I'm on right now has 6G RAM. Running Win7-64. Intel i7. I use a desktop gadget to watch memory and core usages. Seldom see RAM usage above 60%, never above 75%. So, isn't that 1.5G RAM wasted? It's not being used by system or software. So why not make that a RAMdisk as mentioned previously, thus decreasing writes to HDD or SSD, thus decreasing wear & tear? Prolly not a perceived speed increase, considering the machine in use. And, since temporary files, for the most part, don't matter, nor does the pagefile system, once you reboot, there's no harm, no foul, for a RAMdisk, is there? Am I wrong here? If so, show me.