RE: [SLUG] A ggod one for all of you,,

From: Derek Glidden (dglidden@illusionary.com)
Date: Tue Feb 19 2002 - 15:14:12 EST


On Tue, 2002-02-19 at 13:53, Mikes work account wrote:
> The issue on my system is the sheer volume of reads and writes to the hard
> drive and it is not a linux problem per se. I just need a way to back up a
> ram disk on a regular basis and I will have solved my problems.

Again by putting a heavily-used file on a RAMdrive, you're only going to
exacerbate the problem. You'll be taking RAM away from the system that
would normally be used for read/write cache. The kernel is *still*
going to try to cache reads/writes from/to the file, even if its on a
RAMdisk, but now there will be much less memory available to the kernel
to do that.

There are serious problems with the solution you're using to "solve"
this problem.

Here's one: if the file is in such heavy use, you will not be able to
get a consistent snapshot of the file to "back up" to permanent media.
Linux, and UNIX-alikes in general, allow you to read a file that is
being written to. If you try to copy it off a RAM disk onto the hard
drive while it's being written to, the system will allow it, and now you
will have a corrupted copy of it on your hard drive that is partially
rewritten and partially not.

Here's another problem: what if you're in the midst of copying the file
when the system loses power? The old copy has been partially
overwritten so now you have _no_ copy of it, except for any older
"backup" copies you might have lying around, which are probably
corrupted; see above.

Linux tries *VERY HARD* to order disk I/O to be most efficient given
available resources. Writes get cached until buffers get filled up and
then get flushed all at once, ordered to minimize seeks to the drives.
Reads get cached so if the same file is read later, it's already in
RAM. If you're running into situations where your filesystem cache is
not effective enough, you can tune it with /proc settings, or usually
better yet, you add more RAM.

Since you have enough RAM to be able to make a RAMdisk that is large
enough to hold this "problem" file, you absolutely should have enough
RAM that Linux' filesystem cache could keep the entire contents cached.
If you're having read/write performance issues, they _must_ be related
to something else.

(About the only time a ramdisk is even vaguely useful under Linux is if
you have a local application that likes to make thousands of tiny little
files and then delete them shortly after creating them. Except Reiserfs
handles that kind of activity very efficiently, so nowadays you can just
use Reiserfs in just about every case where a RAMdisk might have been
useful in the past.)

What is the application? Are people accessing it via NFS or Samba or
locally? How much RAM? What kind of filesystem are you using on the
machine? What distro? What kernel version? If people are accessing
it over the network, what kind of network do you have? Switches?
Hubs? 10Mbps or 100Mbps? What kind of hard drives are in the system?
If they're IDE, do you have DMA enabled?

There are lots of questions that can be asked and answered to track down
the specific problem before doing something as dangerous as putting a
critical file on a RAMdisk.
 

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval 

usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec -

http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 16:21:52 EDT