Est-il possible qu'un fichier core de 1 GB ne prenne quasiment pas de
place sur disque?
ay:~> df -T .; ls -l core; rm -f core; ls core; df -T .
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/hda5 ext3 5621496 4182900 1153032 79% /home
-rw------- 1 lefevre lefevre 1180438528 2003-07-09 09:26 core
ls: core: No such file or directory
zsh: exit 1 ls core
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/hda5 ext3 5621496 4174472 1161460 79% /home
i.e. moins de 10 Mo étaient réellement pris sur le disque.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Le Wed, 9 Jul 2003 07:29:44 +0000 (UTC), Vincent Lefevre <vincent+ écrivait :
Est-il possible qu'un fichier core de 1 GB ne prenne quasiment pas de place sur disque?
Oui, s'il est à trous.
Ah, je ne savais pas que ça existait en pratique.
Ça peut peut-etre arriver si deux applis dumpent le meme core en meme temps.
Il n'y avait qu'une seule appli, mais je suppose qu'il doit y avoir un gros trou entre les données et la pile.
Merci,
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Olivier Aumage
Salut Vincent,
Vincent Lefevre <vincent+ writes:
Dans l'article , Stephane CHAZELAS écrit:
Le Wed, 9 Jul 2003 07:29:44 +0000 (UTC), Vincent Lefevre <vincent+ écrivait :
Est-il possible qu'un fichier core de 1 GB ne prenne quasiment pas de place sur disque?
Oui, s'il est à trous.
Ah, je ne savais pas que ça existait en pratique.
Il n'y a d'ailleur pas besoin de deux applications pour faire un fichier à trous. Le trou est crée quand on fait un 'seek' au-dela de la fin du fichier suivi d'une écriture. Le seek ne génère pas de contenu effectif (chaque octet est supposé égal à 0).
La place occupée par 'a' est de 12 octets sur mon système (Linux), la taille indiqué par ls est de 1 go + 1 octet.
Dans le cas du core, les trous correspondent vraisemblablement aux pages mémoire allouées par le processus mais non utilisées.
-- Olivier
Salut Vincent,
Vincent Lefevre <vincent+news@vinc17.org> writes:
Dans l'article <slrnbgnima.43.stephane_chazelas@pcchazelas.free.fr>,
Stephane CHAZELAS <stephane_chazelas@yahoo.fr> écrit:
Le Wed, 9 Jul 2003 07:29:44 +0000 (UTC), Vincent Lefevre <vincent+news@vinc17.org> écrivait :
Est-il possible qu'un fichier core de 1 GB ne prenne quasiment pas de
place sur disque?
Oui, s'il est à trous.
Ah, je ne savais pas que ça existait en pratique.
Il n'y a d'ailleur pas besoin de deux applications pour faire un
fichier à trous. Le trou est crée quand on fait un 'seek' au-dela de
la fin du fichier suivi d'une écriture. Le seek ne génère pas de
contenu effectif (chaque octet est supposé égal à 0).
Le Wed, 9 Jul 2003 07:29:44 +0000 (UTC), Vincent Lefevre <vincent+ écrivait :
Est-il possible qu'un fichier core de 1 GB ne prenne quasiment pas de place sur disque?
Oui, s'il est à trous.
Ah, je ne savais pas que ça existait en pratique.
Il n'y a d'ailleur pas besoin de deux applications pour faire un fichier à trous. Le trou est crée quand on fait un 'seek' au-dela de la fin du fichier suivi d'une écriture. Le seek ne génère pas de contenu effectif (chaque octet est supposé égal à 0).
Il n'y a d'ailleur pas besoin de deux applications pour faire un fichier à trous. Le trou est crée quand on fait un 'seek' au-dela de la fin du fichier suivi d'une écriture. Le seek ne génère pas de contenu effectif (chaque octet est supposé égal à 0).
Exemple rapide en Perl: [...]
Oui, ou simplement l'exemple avec "dd seek=" que je donnais.
[...]
Dans le cas du core, les trous correspondent vraisemblablement aux pages mémoire allouées par le processus mais non utilisées.
Probable en effet. Ce que je pensais avec mes deux applis qui corent en meme temps, c'est.
une qui fait le.
open("core", O_CREAT|O_TRUNC|O_WRONLY) qui écrit 120 Mo à ce moment-là c'est l'autre qui core: open("core", O_CREAT|O_TRUNC|O_WRONLY) les 120 premiers Mo écrits par la première appli sont perdus, et il aura un trou entre la fin du core de l'appli2 (qu'on supposera plus petit que 120Mo) et l'offset 120Mo.
Maintenant, il est possible que le systeme fasse un unlink("core") avant de dumper un core ou qu'il refuse d'écraser un core et que le cas que je décris ne puisse pas se produire. En tout cas, j'ai pu le produire sous Linux.
Il n'y a d'ailleur pas besoin de deux applications pour faire un
fichier à trous. Le trou est crée quand on fait un 'seek' au-dela de
la fin du fichier suivi d'une écriture. Le seek ne génère pas de
contenu effectif (chaque octet est supposé égal à 0).
Exemple rapide en Perl:
[...]
Oui, ou simplement l'exemple avec "dd seek=" que je donnais.
[...]
Dans le cas du core, les trous correspondent vraisemblablement aux
pages mémoire allouées par le processus mais non utilisées.
Probable en effet. Ce que je pensais avec mes deux applis qui
corent en meme temps, c'est.
une qui fait le.
open("core", O_CREAT|O_TRUNC|O_WRONLY)
qui écrit 120 Mo
à ce moment-là c'est l'autre qui core:
open("core", O_CREAT|O_TRUNC|O_WRONLY)
les 120 premiers Mo écrits par la première appli sont perdus, et
il aura un trou entre la fin du core de l'appli2 (qu'on
supposera plus petit que 120Mo) et l'offset 120Mo.
Maintenant, il est possible que le systeme fasse un
unlink("core") avant de dumper un core ou qu'il refuse d'écraser
un core et que le cas que je décris ne puisse pas se produire.
En tout cas, j'ai pu le produire sous Linux.
Il n'y a d'ailleur pas besoin de deux applications pour faire un fichier à trous. Le trou est crée quand on fait un 'seek' au-dela de la fin du fichier suivi d'une écriture. Le seek ne génère pas de contenu effectif (chaque octet est supposé égal à 0).
Exemple rapide en Perl: [...]
Oui, ou simplement l'exemple avec "dd seek=" que je donnais.
[...]
Dans le cas du core, les trous correspondent vraisemblablement aux pages mémoire allouées par le processus mais non utilisées.
Probable en effet. Ce que je pensais avec mes deux applis qui corent en meme temps, c'est.
une qui fait le.
open("core", O_CREAT|O_TRUNC|O_WRONLY) qui écrit 120 Mo à ce moment-là c'est l'autre qui core: open("core", O_CREAT|O_TRUNC|O_WRONLY) les 120 premiers Mo écrits par la première appli sont perdus, et il aura un trou entre la fin du core de l'appli2 (qu'on supposera plus petit que 120Mo) et l'offset 120Mo.
Maintenant, il est possible que le systeme fasse un unlink("core") avant de dumper un core ou qu'il refuse d'écraser un core et que le cas que je décris ne puisse pas se produire. En tout cas, j'ai pu le produire sous Linux.
-- Stéphane
Jean-Yves LENHOF
On Wed, 09 Jul 2003 07:29:44 +0000, Vincent Lefevre wrote:
Est-il possible qu'un fichier core de 1 GB ne prenne quasiment pas de place sur disque?
Une autre piste éventuellement ulimit -c est-il à autre chose qu'a 0 ?
JYL
On Wed, 09 Jul 2003 07:29:44 +0000, Vincent Lefevre wrote:
Est-il possible qu'un fichier core de 1 GB ne prenne quasiment pas de
place sur disque?
Une autre piste éventuellement ulimit -c est-il à autre chose qu'a 0 ?
Oui, ou simplement l'exemple avec "dd seek=" que je donnais.
En effet, j'avais lu un peu vite... :-)
Dans le cas du core, les trous correspondent vraisemblablement aux pages mémoire allouées par le processus mais non utilisées.
Probable en effet. Ce que je pensais avec mes deux applis qui corent en meme temps, c'est.
[snip]
Maintenant, il est possible que le systeme fasse un unlink("core") avant de dumper un core ou qu'il refuse d'écraser un core et que le cas que je décris ne puisse pas se produire. En tout cas, j'ai pu le produire sous Linux.
C'est un peu étonnant, mais puisque tu affirmes l'avoir produit, je ne conteste pas :-).
Cela dit, j'ai jeté un coup d'oeil au code de mon kernel hier soir (2.4.18, je crois) et la création du fichier core est dans une section critique, donc a priori, il n'est apparamment pas possible d'avoir deux applications qui génère un core en même temps avec cette version de noyau, sauf avec un système de fichier distribué.
%----[fs/exec.c]-------------------------------------- int do_coredump(long signr, struct pt_regs * regs) { struct linux_binfmt * binfmt; [...] int retval = 0;
Oui, ou simplement l'exemple avec "dd seek=" que je donnais.
En effet, j'avais lu un peu vite... :-)
Dans le cas du core, les trous correspondent vraisemblablement aux
pages mémoire allouées par le processus mais non utilisées.
Probable en effet. Ce que je pensais avec mes deux applis qui
corent en meme temps, c'est.
[snip]
Maintenant, il est possible que le systeme fasse un
unlink("core") avant de dumper un core ou qu'il refuse d'écraser
un core et que le cas que je décris ne puisse pas se produire.
En tout cas, j'ai pu le produire sous Linux.
C'est un peu étonnant, mais puisque tu affirmes l'avoir produit, je ne
conteste pas :-).
Cela dit, j'ai jeté un coup d'oeil au code de mon kernel hier soir
(2.4.18, je crois) et la création du fichier core est dans une section
critique, donc a priori, il n'est apparamment pas possible d'avoir
deux applications qui génère un core en même temps avec cette version
de noyau, sauf avec un système de fichier distribué.
%----[fs/exec.c]--------------------------------------
int do_coredump(long signr, struct pt_regs * regs)
{
struct linux_binfmt * binfmt;
[...]
int retval = 0;
Oui, ou simplement l'exemple avec "dd seek=" que je donnais.
En effet, j'avais lu un peu vite... :-)
Dans le cas du core, les trous correspondent vraisemblablement aux pages mémoire allouées par le processus mais non utilisées.
Probable en effet. Ce que je pensais avec mes deux applis qui corent en meme temps, c'est.
[snip]
Maintenant, il est possible que le systeme fasse un unlink("core") avant de dumper un core ou qu'il refuse d'écraser un core et que le cas que je décris ne puisse pas se produire. En tout cas, j'ai pu le produire sous Linux.
C'est un peu étonnant, mais puisque tu affirmes l'avoir produit, je ne conteste pas :-).
Cela dit, j'ai jeté un coup d'oeil au code de mon kernel hier soir (2.4.18, je crois) et la création du fichier core est dans une section critique, donc a priori, il n'est apparamment pas possible d'avoir deux applications qui génère un core en même temps avec cette version de noyau, sauf avec un système de fichier distribué.
%----[fs/exec.c]-------------------------------------- int do_coredump(long signr, struct pt_regs * regs) { struct linux_binfmt * binfmt; [...] int retval = 0;
Avec les logiciels de p2p on a aussi ce phénomène, ls -l renvoie la taille finale du fichier, mais du lui arrive à donner la taille correcte à l'instant t, donc il doit avoir une autre façon de vérifier, si quelqu'un (stephane au hasard :) sait pourquoi, je suis preneur pour mon éducation.
Ils créent un fichier à trou de la taille finale (initialement juste un grand trou tout vide). Et ensuite écrivent dedans en parallèle à plusieurs endroits (suivant les connexions aux multiples peers), en l'ouvrant concurrentiellement sans O_TRUNC et en faisant les lseek qui vont bien.
Seul ton logiciel de p2p sait quand tous les trous ont été comblés.
Avec les logiciels de p2p on a aussi ce phénomène, ls -l renvoie la
taille finale du fichier, mais du lui arrive à donner la taille correcte
à l'instant t, donc il doit avoir une autre façon de vérifier, si
quelqu'un (stephane au hasard :) sait pourquoi, je suis preneur pour mon
éducation.
Ils créent un fichier à trou de la taille finale (initialement
juste un grand trou tout vide). Et ensuite écrivent dedans en
parallèle à plusieurs endroits (suivant les connexions aux
multiples peers), en l'ouvrant concurrentiellement sans O_TRUNC
et en faisant les lseek qui vont bien.
Seul ton logiciel de p2p sait quand tous les trous ont été
comblés.
Avec les logiciels de p2p on a aussi ce phénomène, ls -l renvoie la taille finale du fichier, mais du lui arrive à donner la taille correcte à l'instant t, donc il doit avoir une autre façon de vérifier, si quelqu'un (stephane au hasard :) sait pourquoi, je suis preneur pour mon éducation.
Ils créent un fichier à trou de la taille finale (initialement juste un grand trou tout vide). Et ensuite écrivent dedans en parallèle à plusieurs endroits (suivant les connexions aux multiples peers), en l'ouvrant concurrentiellement sans O_TRUNC et en faisant les lseek qui vont bien.
Seul ton logiciel de p2p sait quand tous les trous ont été comblés.
-- Stéphane
Manu
shaddai wrote:
Avec les logiciels de p2p on a aussi ce phénomène, ls -l renvoie la taille finale du fichier, mais du lui arrive à donner la taille correcte à l'instant t, donc il doit avoir une autre façon de vérifier, si quelqu'un (stephane au hasard :) sait pourquoi, je suis preneur pour mon éducation.
Je suppose que du regarde la taille du fichier en nombre de blocs. Or dans un "fichier à trous", dans les infos de l'inoeud où on trouve la taille du fichier en octet et le nombre de bloc: taille fichier != nombre de blocs * taille d'un bloc
-=( manu )=-
shaddai wrote:
Avec les logiciels de p2p on a aussi ce phénomène, ls -l renvoie la
taille finale du fichier, mais du lui arrive à donner la taille correcte
à l'instant t, donc il doit avoir une autre façon de vérifier, si
quelqu'un (stephane au hasard :) sait pourquoi, je suis preneur pour mon
éducation.
Je suppose que du regarde la taille du fichier en nombre de blocs.
Or dans un "fichier à trous", dans les infos de l'inoeud où on trouve la
taille du fichier en octet et le nombre de bloc:
taille fichier != nombre de blocs * taille d'un bloc
Avec les logiciels de p2p on a aussi ce phénomène, ls -l renvoie la taille finale du fichier, mais du lui arrive à donner la taille correcte à l'instant t, donc il doit avoir une autre façon de vérifier, si quelqu'un (stephane au hasard :) sait pourquoi, je suis preneur pour mon éducation.
Je suppose que du regarde la taille du fichier en nombre de blocs. Or dans un "fichier à trous", dans les infos de l'inoeud où on trouve la taille du fichier en octet et le nombre de bloc: taille fichier != nombre de blocs * taille d'un bloc
-=( manu )=-
Laurent Wacrenier
Vincent Lefevre <vincent+ écrit:
Il n'y avait qu'une seule appli, mais je suppose qu'il doit y avoir un gros trou entre les données et la pile.
4 Go est l'espace adressable sur 32 bits. Les trous correspondent à de l'espace non alloué.
Vincent Lefevre <vincent+news@vinc17.org> écrit:
Il n'y avait qu'une seule appli, mais je suppose qu'il doit y avoir
un gros trou entre les données et la pile.
4 Go est l'espace adressable sur 32 bits.
Les trous correspondent à de l'espace non alloué.
Il n'y avait qu'une seule appli, mais je suppose qu'il doit y avoir un gros trou entre les données et la pile.
4 Go est l'espace adressable sur 32 bits. Les trous correspondent à de l'espace non alloué.
kanze
jsp Olivier Aumage wrote in message news:...
Vincent Lefevre <vincent+ writes:
Dans l'article , Stephane CHAZELAS écrit:
Le Wed, 9 Jul 2003 07:29:44 +0000 (UTC), Vincent Lefevre <vincent+ écrivait :
Est-il possible qu'un fichier core de 1 GB ne prenne quasiment pas de place sur disque?
Oui, s'il est à trous.
Ah, je ne savais pas que ça existait en pratique.
Il n'y a d'ailleur pas besoin de deux applications pour faire un fichier à trous. Le trou est crée quand on fait un 'seek' au-dela de la fin du fichier suivi d'une écriture. Le seek ne génère pas de contenu effectif (chaque octet est supposé égal à 0).
La place occupée par 'a' est de 12 octets sur mon système (Linux), la taille indiqué par ls est de 1 go + 1 octet.
Ça m'étonnerait que la place occupée soit seulement 12 octets.
En fait, un fichier a une taille logique, et une taille physique. La taille logique, c'est ce que tu trouves dans le champs st_size d'un struct stat ; c'est aussi ce qu'affiche ls. Elle correspond au nombre d'octets que tu pourrais lire. Tu n'as normalement pas de moyen de voir la taille physique, au moins, pas de façon portable. Mais grosso modo, c'est la place que le fichier occupe physiquement sur disque. Et c'est toujours une multiple de la taille d'un bloc d'allocation (qui lui est toujours une multiple de 512).
Ni l'une ni l'autre ne prend en compte les octets occupés par le inode ou par le nom du fichier dans le répertoire.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
jsp
Olivier Aumage <olivier.aumage@wanadoo.nl> wrote in message
news:<87el0zpsjm.fsf@wanadoo.nl>...
Vincent Lefevre <vincent+news@vinc17.org> writes:
Dans l'article <slrnbgnima.43.stephane_chazelas@pcchazelas.free.fr>,
Stephane CHAZELAS <stephane_chazelas@yahoo.fr> écrit:
Le Wed, 9 Jul 2003 07:29:44 +0000 (UTC), Vincent Lefevre
<vincent+news@vinc17.org> écrivait :
Est-il possible qu'un fichier core de 1 GB ne prenne quasiment
pas de place sur disque?
Oui, s'il est à trous.
Ah, je ne savais pas que ça existait en pratique.
Il n'y a d'ailleur pas besoin de deux applications pour faire un
fichier à trous. Le trou est crée quand on fait un 'seek' au-dela de
la fin du fichier suivi d'une écriture. Le seek ne génère pas de
contenu effectif (chaque octet est supposé égal à 0).
La place occupée par 'a' est de 12 octets sur mon système (Linux), la
taille indiqué par ls est de 1 go + 1 octet.
Ça m'étonnerait que la place occupée soit seulement 12 octets.
En fait, un fichier a une taille logique, et une taille physique. La
taille logique, c'est ce que tu trouves dans le champs st_size d'un
struct stat ; c'est aussi ce qu'affiche ls. Elle correspond au nombre
d'octets que tu pourrais lire. Tu n'as normalement pas de moyen de voir
la taille physique, au moins, pas de façon portable. Mais grosso modo,
c'est la place que le fichier occupe physiquement sur disque. Et c'est
toujours une multiple de la taille d'un bloc d'allocation (qui lui est
toujours une multiple de 512).
Ni l'une ni l'autre ne prend en compte les octets occupés par le inode
ou par le nom du fichier dans le répertoire.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Le Wed, 9 Jul 2003 07:29:44 +0000 (UTC), Vincent Lefevre <vincent+ écrivait :
Est-il possible qu'un fichier core de 1 GB ne prenne quasiment pas de place sur disque?
Oui, s'il est à trous.
Ah, je ne savais pas que ça existait en pratique.
Il n'y a d'ailleur pas besoin de deux applications pour faire un fichier à trous. Le trou est crée quand on fait un 'seek' au-dela de la fin du fichier suivi d'une écriture. Le seek ne génère pas de contenu effectif (chaque octet est supposé égal à 0).
La place occupée par 'a' est de 12 octets sur mon système (Linux), la taille indiqué par ls est de 1 go + 1 octet.
Ça m'étonnerait que la place occupée soit seulement 12 octets.
En fait, un fichier a une taille logique, et une taille physique. La taille logique, c'est ce que tu trouves dans le champs st_size d'un struct stat ; c'est aussi ce qu'affiche ls. Elle correspond au nombre d'octets que tu pourrais lire. Tu n'as normalement pas de moyen de voir la taille physique, au moins, pas de façon portable. Mais grosso modo, c'est la place que le fichier occupe physiquement sur disque. Et c'est toujours une multiple de la taille d'un bloc d'allocation (qui lui est toujours une multiple de 512).
Ni l'une ni l'autre ne prend en compte les octets occupés par le inode ou par le nom du fichier dans le répertoire.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
