g_vfs_done():md2[WRITE(offset=434585600, length=131072)]error = 28

g_vfs_done():md2[WRITE(offset=434585600, length=131072)]error = 28

La cause ne semble pas être le cd... mais un manque de mémoire... m'as essayer de faire de la swap et un swapon et de jouer avec la taille du ramdisc avant install au hdd...

J'ai des indices qui suivent en dessous;

Extrait de:

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2005-12/msg02078.html


What do I need to fix to be able to use a RAM-backed filesystem?


From mdconfig(8):


-t type
Select the type of the memory disk.


malloc Storage for this type of memory disk is allocated with
malloc(9). This limits the size to the malloc bucket
limit in the kernel. If the -o reserve option is not
set, creating and filling a large malloc-backed memory
disk is a very easy way to panic a system.




It allocates kernel address space which is quite scarce on 32-bit
platforms. I'm not sure if it allocated physical memory. Given the
panicking behavior, I suspect that is deferred.


Yes, that's why -o reserve is recommended to allocate it all up-front.

J'ai testé un install2hdd malloc -o;
y'a skippé complètement la copie des fichiers...
Le script m'a aussi dit que l,install était réussie.
Connard. 

I believe this is mostly accurate. If you're actually out of memory,
there's a good chance you're going to be swapping anyway so this might
or might not actually cost you anything. If you have frequent, randomly
distributed access to the file system it's likely to be expensive. On
the other hand, if there are hot spots, the swapping may be beneficial
because it will allow other processes to proceed more efficiently.


Also in the case when you are not swapping, swap-backed md is actually faster than malloc backed.

En fait, dans mon cas spécifiquement, y'a bien un swap file, mais le live-cd s'en sert pas, même avec un swapon...  Bordel.

Really you need to make sure that whatever you use your system for, you have enough RAM that you never need to swap. Otherwise you're throwing away most of your system's performance for no good reason.

===================================================
Extrait qui peut aider:

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-08/msg00528.html



Re: kernel panic with memory disks
From: Stefan Lambrev <stefan.lambrev@xxxxxxxxxxxxxxxx>
Date: Tue, 21 Aug 2007 10:32:45 +0300
Hello,


Eric Kjeldergaard wrote:
On 20/08/07, Stefan Lambrev <stefan.lambrev@xxxxxxxxxxxxxxxx> wrote:
Hello,


I do not know if this is know behavior, and I know that 6.2 panic if the
memory disk got full,
but on 7-current the panic is before the disk got full.


Here is what I do:


mdconfig -a -t malloc -s 800m
newfs /dev/md0
mount /dev/md0 /mnt
cp 600mb.file /mnt

Si je suis pas dans le champs, le gars assignait ici 800 megs dans son malloc...

-t type
Select the type of the memory disk.


malloc Storage for this type of memory disk is allocated with
malloc(9). This limits the size to the malloc bucket
limit in the kernel. If the -o reserve option is not
set, creating and filling a large malloc-backed memory
disk is a very easy way to panic a system.
-- mdconfig(8)


I really should read manuals more carefully :) Thanks for the information.


Just one more question - to prevent panic I should use "-o reserve" and have to increase:
vfs.maxmallocbufspace
vfs.bufmallocspace