You'd be at least doubling the number of writes, probably much more than
that since you'd have to hack up something very untidy to support
writing to multiple files at once if it weren't part of the
application. At the best - assuming you write support into the
application or hack something up that can actually be stable enough to
work - you're doing a write both to the file on the filesystem and to
the one in the ramdisk at the same time which gains you nothing but a
slowdown on write performance. At worst, any time the file on the
filesystem is updated, you recopy the entire file into ramdisk which
brings the entire machine to its knees if the file is written to
frequently.
I said it before and I'll say it again: if there are performance issues
with reading/writing to a file on the filesystem, but there is
sufficient RAM in the box to create a ramdisk large enough to hold the
entire file in memory, then there is sufficient memory for the Linux
filesystem cache to hold the file in RAM and moving the file into a
ramdisk is not going to solve the problem. There are other issues that
need to be addressed to solve the actual performance problem.
Nothing at all personal meant to those involved, but I've posted several
messages for things to look at to determine where the problem may lie
and never got a response, so I've been avoiding this thread since then
for the most part. You can only try so much...
On Tue, 2002-02-26 at 15:37, Grantham, Patrick wrote:
> Seems odd to me, say this is accomplished. What price would be paid in the
> way of overhead on the server, constantly synching the file in ram (read)
> with the file on the disk (writes)?
>
> -----Original Message-----
> From: R P Herrold [mailto:herrold@owlriver.com]
> Sent: Tuesday, February 26, 2002 2:17 PM
> To: slug@nks.net
> Subject: Re: [SLUG] Ok we have it now,,
>
>
> On Tue, 26 Feb 2002, Mikes work account wrote:
>
> > What if I made links to the real files from the ram drive and left the
> ram
> > drive as RO?
> > Could that be done so that the writes would follow the link? There must
> be
> > some way to trap access to filesystems and catch the writes and redirect
> > them to another filesystem. Is anyone out there technical enough to
> explain
> > why this cannot be? Or better yet is anyone out there thinking outside the
> > box today and can tell me hoe to accomplish this?
>
> it may be possible -- but it is a major undertaking --
> certainly nothing I have ever seen
>
> -- Russ herrold
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/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:47:47 EDT