J'entreprend actuellement de graver une image iso de la gentoo 1.2 (celle distribuée dans login: ).
Je savais à la base ke l'échange entre le lecteur cd et le graveur allait me poser un pb (c aussi ça ki m'intéressait).
 
G déjà fait 2 simulations; une en X2 l'autre en X4 avec 0 comme mémoire tampon.
 
L'essai en X2 n'a pas posé de problème (heureuesement l'image ne fait que 135 MO)
En X4 ça a planté.
 
Pour passer en X4 ou X8 faut que j'utilise une mémoire tampon, je vais donc faire des tests en X4 avec différentes valeurs.
 
Je n'ai qu'une idée très vague de ce ke pourrait être une valeur adéquate voire idéale et de quoi elle doit dépendre.
 
Est-ce ke vous pouvez me dire laquelle vous utilisez ?

Tampax king size, 23 cm.

essaye une valeur en Mo ~ 1/2*vitesse de gravure

hummm
 
g mis 1024 (en pensant k'il comprendrait 1024Ko) et voila ce k'il me répond
 
/usr//bin/cdrecord: write-buffer too small, minimum is 192k. Disabling.
 

alors faut que tu essaye 1 048 576 ou 2 097 152 ou 4 194 304

 
Oui c ce ke je me disais mais je viens de le faire planter en entrant à tout hasard "192K".
Ils devraient quand même préciser si les valeurs a entrer sont en octets, koctets ou Moctets (je trouve rien avec google)

c bon je sais comment il faut faire maintenant ... en fait y'a un message ki apparait sur l'input "memoire tampon" de Gcombust lorsk'on laisse la souris dessus, il précise ke la définition de la taille obéit à la même syntaxe ke celle utilisée par cdrecord, suffit donc de ce reporter au manuel de cdrecord.
 
En bref je vais faire passer la taille de mon tempon à 16MO ou 32 Mo.
 
Voilà ce ke g trouvé sur internet à ce sujet.
 
 
 
fs=#
 Positionner la taille du fifo (tampon circulaire). Vous pouvez utiliser la même méthode que dans dd(1), sdd(1) ou star(1). Le nombre représentant la taille est prise en octets à moins que spécifié autrement. Si un nombre est suivi directement par la lettre b, k, m, s ou f, la taille est multipliée par 512, 1024, 1024*1024, 2048 ou 2352. Si la taille est composée de nombres séparés par x ou *, une multiplication des deux nombres est effectuée. Ainsi, fs=10x63k spécifie une taille du fifo de 630Ko.  
 
La taille spécifiée par l'argument fs= inclut le mémoire partagée nécessaire à l'administration. C'est au moins un page de mémoire. Si aucune option fs= n'est présente, cdrecord essaiera d'obtenir la valeur de la taille du fifo à partir de la variable d'environnement CDR_FIFOSIZE. La taille par défaut du fifo est actuellement 4 Mo.  
 
Le fifo est utilisé pour augmenter le tampon pour le processus d'écriture en temps réel. Il permet de faire fonctionner un tuyau à partir de mkisofs directement dans cdrecord. Si le fifo est actif et un tuyau entre mkisofs et cdrecord est utilisé pour créer un CD, cdrecord s'arrêtera avant de faire des modifications sur le disque si mkisofs termine avant qu'il ne commence d'écrire. La taille de fifo recommandée est entre 4 et 32 Mo. Comme règle, la taille du fifo devrait être au moins égale à la taille du tampon interne du graveur et pas plus que la moitié de la RAM disponible dans la machine. Si la taille de fifo est assez grande, les statistiques du fifo afficheront un compte de zéro et le remplissage minimum du fifo n'est pas inférieur à 20 %. Il n'est pas raisonnable d'utiliser trop d'espace pour le fifo. Si vous avez besoin de plus de 8 Mo pour écrire un CD sur une machine inactive, votre machine est soit pas assez puissante, a un problème matériel ou est mal configurée. L'architecture sun4c (ex : une Sparcstation-2) a seulement des entrées de table de page MMU pour 16 Mo par processus. Utiliser plus que 14 Mo pour le fifo peut dans ce cas entraîner le système d'exploitation à dépenser trop de temps à recharger constamment les tables MMU. Les machines plus récentes de Sun n'ont pas ce problème matériel. Je n'ai pas d'information sur le matériel PC reflétant ce problème.  
 
Si vous avez un sous-charge de tampon ou des problèmes similaires et observez un compte vide de fifo zéro, vous avez un problème matériel. La taille du fifo dans ce cas est suffisante.