hi,
i've just tried to "search for something in the RAM", so i thougt
/proc/kcore would be a good address to start. i really only wanted to
grep for raw data throught it, i did not need any specific meta-data.
ok, i checked:
$ ls -lah /proc/kcore
-r-------- 1 root root 256M Mar 4 23:25 /proc/kcore
which makes sense, since i have 256MB RAM.
$ su -
Password:
root$ cp /proc/kcore /data/Incoming/
`/proc/kcore' -> `/data/Incoming/kcore'
root$ ls -la /proc/kcore /data/Incoming/kcore
-r-------- 1 root root 1.0G Mar 4 23:26 /data/Incoming/kcore
-r-------- 1 root root 1.0G Mar 4 23:27 /proc/kcore
whooha! /proc/kcore and its new on-disk copy are now both 1GB in size.
how comes? i could imagine, that when "cp" tried to copy /proc/kcore the
RAM gets filled with /proc/kcore again, thus doubling it...somehow...but
cp continued with no errors, why should it double /proc/kcore
(256MB->512MB) and then again (512MB->1024MB), but stop after this? i
would've expected cp to never stop copying...
i don't get it,
Christian.
Tony Luck wrote:
>
> Take a look at the driver (fs/proc/kcore.c) that creates this pseudo-file.
will do ;)
> Initially the size of the file is set from the size of your memory.
>
> Reading the file has the side-effect of setting up the ELF headers to make
> this look like an ELF file ... in fact a sparse one. Use "objdump" (with the
> "-p" flag I think) to show the headers, and you'll see which offsets in the file
> correspond to which kernel virtual addresses.
ah, well. i was just curious, why the file on the filesystem did not grow
beyond 4 times of the size of the ram. i just reproduced it on another
machine, booted with "mem=48M" and "dd" tried to write out a file until
E_NOSPACE happens, just as expected.
thank you,
Christian.
--
BOFH excuse #133:
It's not plugged in.