suite à vos réponses, dont je vous remercie, j'ai donc essayé ( sous
Ubuntu ) KHexEdit et Ghex. A moins que cela m'ait échappé, aucun des
deux ne permet d'éditer n'importe quel secteur d'un DD...Ils permettent
juste de choisir et d'éditer un fichier.
Et donc, qqun connait-il un éditeur hexa qui permette, comme WinHEX ou
EditHexa sous XP, d'éditer par exemple le MBR, un EBR, un secteur de boot
d'une partition quelconque ou n'importe quel secteur sur le DD de son choix ?
Le 20 Apr 2008 09:18:52 GMT, Nicolas George <nicolas$ écrivait dans fr.comp.os.linux.configuration:
Denis Beauregard wrote in message :
Comme j'ai une base de données sous forme de 60 000 documents HTML, je vois très bien la différence de l'espace occupé entre le PC en FAT32 et celui en ext3.
Tu vois peut-être bien, mais moi je sais comment est organisé un filesystem ext3, et je maintiens : si, un fichier occupe les blocs par taille entière.
Ils ont des clusters de grandeur variable ? Je croyais que c'était plus simple d'avoir des clusters de grandeur fixe et d'émuler des clusters de grandeur variable en surcouche. Alors, ils doivent avoir des secteurs de 128 octets avec un nombre variable de secteurs par cluster ou quelque chose de similaire.
Quelle taille de clusters utilises-tu sur ta FAT32 ?
Je suppose que j'ai le maximum, soit 32k. Quand j'ai regardé en 2006 (il y avait beaucoup moins de fichiers), cela occupait 200 Mo sur une ext3 (Debian Etch), une NTFS (Win XP) et un cédérom, mais 1 800 Mo sur une FAT32 (Win 98).
Dans la version courante, je lis : 67027 fichiers, 148 dossiers, 265 367 595 octets en occupant 2 265 841 664 (FAT32). Ce n'est qu'en 2010 que je passe à la version suivante et je devrais avoir un PC avec Ubuntu et ext3 durant le cours de 2008. Peu importe ce que j'utilise, je dois m'assurer que tous mes usagers pourront recopier la base sur leur disque dur.
Denis
Le 20 Apr 2008 09:18:52 GMT, Nicolas George
<nicolas$george@salle-s.org> écrivait dans
fr.comp.os.linux.configuration:
Denis Beauregard wrote in message
<p4il04pobe0cu1uq2dj1jqo5hv663vhj79@4ax.com>:
Comme j'ai une base de données sous forme de 60 000 documents HTML,
je vois très bien la différence de l'espace occupé entre le PC en
FAT32 et celui en ext3.
Tu vois peut-être bien, mais moi je sais comment est organisé un filesystem
ext3, et je maintiens : si, un fichier occupe les blocs par taille entière.
Ils ont des clusters de grandeur variable ? Je croyais que c'était
plus simple d'avoir des clusters de grandeur fixe et d'émuler des
clusters de grandeur variable en surcouche. Alors, ils doivent
avoir des secteurs de 128 octets avec un nombre variable de secteurs
par cluster ou quelque chose de similaire.
Quelle taille de clusters utilises-tu sur ta FAT32 ?
Je suppose que j'ai le maximum, soit 32k. Quand j'ai regardé en 2006
(il y avait beaucoup moins de fichiers), cela occupait 200 Mo sur une
ext3 (Debian Etch), une NTFS (Win XP) et un cédérom, mais 1 800 Mo sur
une FAT32 (Win 98).
Dans la version courante, je lis : 67027 fichiers, 148 dossiers,
265 367 595 octets en occupant 2 265 841 664 (FAT32). Ce n'est
qu'en 2010 que je passe à la version suivante et je devrais avoir
un PC avec Ubuntu et ext3 durant le cours de 2008. Peu importe
ce que j'utilise, je dois m'assurer que tous mes usagers pourront
recopier la base sur leur disque dur.
Le 20 Apr 2008 09:18:52 GMT, Nicolas George <nicolas$ écrivait dans fr.comp.os.linux.configuration:
Denis Beauregard wrote in message :
Comme j'ai une base de données sous forme de 60 000 documents HTML, je vois très bien la différence de l'espace occupé entre le PC en FAT32 et celui en ext3.
Tu vois peut-être bien, mais moi je sais comment est organisé un filesystem ext3, et je maintiens : si, un fichier occupe les blocs par taille entière.
Ils ont des clusters de grandeur variable ? Je croyais que c'était plus simple d'avoir des clusters de grandeur fixe et d'émuler des clusters de grandeur variable en surcouche. Alors, ils doivent avoir des secteurs de 128 octets avec un nombre variable de secteurs par cluster ou quelque chose de similaire.
Quelle taille de clusters utilises-tu sur ta FAT32 ?
Je suppose que j'ai le maximum, soit 32k. Quand j'ai regardé en 2006 (il y avait beaucoup moins de fichiers), cela occupait 200 Mo sur une ext3 (Debian Etch), une NTFS (Win XP) et un cédérom, mais 1 800 Mo sur une FAT32 (Win 98).
Dans la version courante, je lis : 67027 fichiers, 148 dossiers, 265 367 595 octets en occupant 2 265 841 664 (FAT32). Ce n'est qu'en 2010 que je passe à la version suivante et je devrais avoir un PC avec Ubuntu et ext3 durant le cours de 2008. Peu importe ce que j'utilise, je dois m'assurer que tous mes usagers pourront recopier la base sur leur disque dur.
Denis
Denis Beauregard
Le Sun, 20 Apr 2008 07:08:02 +0200, Fabien LE LEZ écrivait dans fr.comp.os.linux.configuration:
Par ailleurs, le format du fichier n'intervient en rien ici. Un fichier au sens Unix, que ce soit une partition formatée en ext3 (/dev/sda2) ou un fichier vidéo (/home/moi/machin.mkv), est une simple suite d'octets. Si tu l'ouvres avec un éditeur hexadécimal, c'est à l'utilisateur de se préoccuper de la signification des octets. Ce n'est que si tu l'ouvres avec le programme "approprié" (respectivement, mount et ffmpeg) que le format du fichier prend de l'importance.
Si on lit les messages du posteur initial, c'est pourtant l'accès direct au secteur sur le disque qu'il semble rechercher. Si on veut étudier l'effet d'une panne (la tête d'écriture du disque qui a écrit au mauvais endroit par exemple), on a alors besoin de savoir la position physique et non logique des secteurs affectés.
Denis
Le Sun, 20 Apr 2008 07:08:02 +0200, Fabien LE LEZ
<gramster@gramster.com> écrivait dans fr.comp.os.linux.configuration:
Par ailleurs, le format du fichier n'intervient en rien ici. Un
fichier au sens Unix, que ce soit une partition formatée en ext3
(/dev/sda2) ou un fichier vidéo (/home/moi/machin.mkv), est une simple
suite d'octets. Si tu l'ouvres avec un éditeur hexadécimal, c'est à
l'utilisateur de se préoccuper de la signification des octets.
Ce n'est que si tu l'ouvres avec le programme "approprié"
(respectivement, mount et ffmpeg) que le format du fichier prend de
l'importance.
Si on lit les messages du posteur initial, c'est pourtant l'accès
direct au secteur sur le disque qu'il semble rechercher. Si on
veut étudier l'effet d'une panne (la tête d'écriture du disque
qui a écrit au mauvais endroit par exemple), on a alors besoin de
savoir la position physique et non logique des secteurs affectés.
Le Sun, 20 Apr 2008 07:08:02 +0200, Fabien LE LEZ écrivait dans fr.comp.os.linux.configuration:
Par ailleurs, le format du fichier n'intervient en rien ici. Un fichier au sens Unix, que ce soit une partition formatée en ext3 (/dev/sda2) ou un fichier vidéo (/home/moi/machin.mkv), est une simple suite d'octets. Si tu l'ouvres avec un éditeur hexadécimal, c'est à l'utilisateur de se préoccuper de la signification des octets. Ce n'est que si tu l'ouvres avec le programme "approprié" (respectivement, mount et ffmpeg) que le format du fichier prend de l'importance.
Si on lit les messages du posteur initial, c'est pourtant l'accès direct au secteur sur le disque qu'il semble rechercher. Si on veut étudier l'effet d'une panne (la tête d'écriture du disque qui a écrit au mauvais endroit par exemple), on a alors besoin de savoir la position physique et non logique des secteurs affectés.
Denis
Nicolas George
Denis Beauregard wrote in message :
la tête d'écriture du disque qui a écrit au mauvais endroit par exemple
Ce n'est pas une panne plausible.
on a alors besoin de savoir la position physique et non logique des secteurs affectés.
Il n'y a aucune notion de « position logique des secteurs ».
Denis Beauregard wrote in message
<9kem04lq15pn91gkebl4m93h0lglensmgj@4ax.com>:
la tête d'écriture du disque
qui a écrit au mauvais endroit par exemple
Ce n'est pas une panne plausible.
on a alors besoin de
savoir la position physique et non logique des secteurs affectés.
Il n'y a aucune notion de « position logique des secteurs ».
la tête d'écriture du disque qui a écrit au mauvais endroit par exemple
Ce n'est pas une panne plausible.
on a alors besoin de savoir la position physique et non logique des secteurs affectés.
Il n'y a aucune notion de « position logique des secteurs ».
Michel_D
Le 20 Apr 2008 09:18:52 GMT, Nicolas George <nicolas$ écrivait dans fr.comp.os.linux.configuration:
Denis Beauregard wrote in message :
Comme j'ai une base de données sous forme de 60 000 documents HTML, je vois très bien la différence de l'espace occupé entre le PC en FAT32 et celui en ext3. Tu vois peut-être bien, mais moi je sais comment est organisé un filesystem
ext3, et je maintiens : si, un fichier occupe les blocs par taille entière.
Ils ont des clusters de grandeur variable ? Je croyais que c'était plus simple d'avoir des clusters de grandeur fixe et d'émuler des clusters de grandeur variable en surcouche. Alors, ils doivent avoir des secteurs de 128 octets avec un nombre variable de secteurs par cluster ou quelque chose de similaire.
Non les clusters n'ont pas de taille variable, par contre le FS peut utiliser certaine particularité pour limiter la place occupé sur le support de stockage (spare file, compression) et le FS peut aussi gérer les fichiers de petites tailles différemment comme par exemple le NTFS qui place les datas (jusqu'à une certaine taille) au niveau de la $MFT au lieu d'utiliser un emplacement de cluster classique.
Quelle taille de clusters utilises-tu sur ta FAT32 ?
Je suppose que j'ai le maximum, soit 32k. Quand j'ai regardé en 2006 (il y avait beaucoup moins de fichiers), cela occupait 200 Mo sur une ext3 (Debian Etch), une NTFS (Win XP) et un cédérom, mais 1 800 Mo sur une FAT32 (Win 98).
Ben oui la différence de taille de clusters explique cette différence, c'est que voulait te dire Nicolas George.
Le 20 Apr 2008 09:18:52 GMT, Nicolas George
<nicolas$george@salle-s.org> écrivait dans
fr.comp.os.linux.configuration:
Denis Beauregard wrote in message
<p4il04pobe0cu1uq2dj1jqo5hv663vhj79@4ax.com>:
Comme j'ai une base de données sous forme de 60 000 documents HTML,
je vois très bien la différence de l'espace occupé entre le PC en
FAT32 et celui en ext3.
Tu vois peut-être bien, mais moi je sais comment est organisé un filesystem
ext3, et je maintiens : si, un fichier occupe les blocs par taille entière.
Ils ont des clusters de grandeur variable ? Je croyais que c'était
plus simple d'avoir des clusters de grandeur fixe et d'émuler des
clusters de grandeur variable en surcouche. Alors, ils doivent
avoir des secteurs de 128 octets avec un nombre variable de secteurs
par cluster ou quelque chose de similaire.
Non les clusters n'ont pas de taille variable, par contre le FS peut utiliser
certaine particularité pour limiter la place occupé sur le support de
stockage (spare file, compression) et le FS peut aussi gérer les fichiers de
petites tailles différemment comme par exemple le NTFS qui place les datas
(jusqu'à une certaine taille) au niveau de la $MFT au lieu d'utiliser un
emplacement de cluster classique.
Quelle taille de clusters utilises-tu sur ta FAT32 ?
Je suppose que j'ai le maximum, soit 32k. Quand j'ai regardé en 2006
(il y avait beaucoup moins de fichiers), cela occupait 200 Mo sur une
ext3 (Debian Etch), une NTFS (Win XP) et un cédérom, mais 1 800 Mo sur
une FAT32 (Win 98).
Ben oui la différence de taille de clusters explique cette différence, c'est
que voulait te dire Nicolas George.
Le 20 Apr 2008 09:18:52 GMT, Nicolas George <nicolas$ écrivait dans fr.comp.os.linux.configuration:
Denis Beauregard wrote in message :
Comme j'ai une base de données sous forme de 60 000 documents HTML, je vois très bien la différence de l'espace occupé entre le PC en FAT32 et celui en ext3. Tu vois peut-être bien, mais moi je sais comment est organisé un filesystem
ext3, et je maintiens : si, un fichier occupe les blocs par taille entière.
Ils ont des clusters de grandeur variable ? Je croyais que c'était plus simple d'avoir des clusters de grandeur fixe et d'émuler des clusters de grandeur variable en surcouche. Alors, ils doivent avoir des secteurs de 128 octets avec un nombre variable de secteurs par cluster ou quelque chose de similaire.
Non les clusters n'ont pas de taille variable, par contre le FS peut utiliser certaine particularité pour limiter la place occupé sur le support de stockage (spare file, compression) et le FS peut aussi gérer les fichiers de petites tailles différemment comme par exemple le NTFS qui place les datas (jusqu'à une certaine taille) au niveau de la $MFT au lieu d'utiliser un emplacement de cluster classique.
Quelle taille de clusters utilises-tu sur ta FAT32 ?
Je suppose que j'ai le maximum, soit 32k. Quand j'ai regardé en 2006 (il y avait beaucoup moins de fichiers), cela occupait 200 Mo sur une ext3 (Debian Etch), une NTFS (Win XP) et un cédérom, mais 1 800 Mo sur une FAT32 (Win 98).
Ben oui la différence de taille de clusters explique cette différence, c'est que voulait te dire Nicolas George.
Nicolas George
Denis Beauregard wrote in message :
Ils ont des clusters de grandeur variable ?
Qui « ils » ?
Alors, ils doivent avoir des secteurs de 128 octets avec un nombre variable de secteurs par cluster ou quelque chose de similaire.
Je ne sais pas de quoi tu essaies de parler, mais tu devrais t'abstenir, parce que ça ne veut absolument rien dire.
Un secteur de disque dur fait toujours 512 octets, ni plus ni moins. En ext2 (et ext3, c'est exactement pareil), l'unité d'allocation est le bloc, qui fait en général 4096 octets, mais qui peut faire 1024 ou 2048. Le choix de la taille de bloc est déterminé à la création du filesystem, et n'est pas modifiable a posteriori.
Je suppose que j'ai le maximum, soit 32k.
Un peu de maths niveau lycée permet de se rendre compte que cette taille de clusters est optimale quand tes fichiers font environ 64 Mo en moyenne. Ici, tes fichiers font environ 4423 octets en moyenne, la taille optimale des clusters serait 512 octets (en fait, 256 serait encore mieux, mais ce n'est pas possible).
Denis Beauregard wrote in message
<2odm04dpmb3fch0g28gr1v2u2h8kbdf8lu@4ax.com>:
Ils ont des clusters de grandeur variable ?
Qui « ils » ?
Alors, ils doivent
avoir des secteurs de 128 octets avec un nombre variable de secteurs
par cluster ou quelque chose de similaire.
Je ne sais pas de quoi tu essaies de parler, mais tu devrais t'abstenir,
parce que ça ne veut absolument rien dire.
Un secteur de disque dur fait toujours 512 octets, ni plus ni moins. En
ext2 (et ext3, c'est exactement pareil), l'unité d'allocation est le bloc,
qui fait en général 4096 octets, mais qui peut faire 1024 ou 2048. Le choix
de la taille de bloc est déterminé à la création du filesystem, et n'est pas
modifiable a posteriori.
Je suppose que j'ai le maximum, soit 32k.
Un peu de maths niveau lycée permet de se rendre compte que cette taille de
clusters est optimale quand tes fichiers font environ 64 Mo en moyenne. Ici,
tes fichiers font environ 4423 octets en moyenne, la taille optimale des
clusters serait 512 octets (en fait, 256 serait encore mieux, mais ce n'est
pas possible).
Alors, ils doivent avoir des secteurs de 128 octets avec un nombre variable de secteurs par cluster ou quelque chose de similaire.
Je ne sais pas de quoi tu essaies de parler, mais tu devrais t'abstenir, parce que ça ne veut absolument rien dire.
Un secteur de disque dur fait toujours 512 octets, ni plus ni moins. En ext2 (et ext3, c'est exactement pareil), l'unité d'allocation est le bloc, qui fait en général 4096 octets, mais qui peut faire 1024 ou 2048. Le choix de la taille de bloc est déterminé à la création du filesystem, et n'est pas modifiable a posteriori.
Je suppose que j'ai le maximum, soit 32k.
Un peu de maths niveau lycée permet de se rendre compte que cette taille de clusters est optimale quand tes fichiers font environ 64 Mo en moyenne. Ici, tes fichiers font environ 4423 octets en moyenne, la taille optimale des clusters serait 512 octets (en fait, 256 serait encore mieux, mais ce n'est pas possible).
Thierry B.
--{ Fabien LE LEZ a plopé ceci: }--
D'après un essai (non représentatif de la globalité) que je viens de faire, un périphérique bloc tel que /dev/hda n'est pas forcément "seekable",
Groumpf ? Comment dd fait-il ?
C'est bien la question que je me pose... Mais bon, comme c'est du code de goret, je suppose que le problème est de mon coté.
-- $ man 1 groff The grog command can be used to guess the correct groff command to use to format a file.
--{ Fabien LE LEZ a plopé ceci: }--
D'après un essai (non représentatif de
la globalité) que je viens de faire, un périphérique bloc tel que
/dev/hda n'est pas forcément "seekable",
Groumpf ?
Comment dd fait-il ?
C'est bien la question que je me pose... Mais bon, comme c'est
du code de goret, je suppose que le problème est de mon coté.
--
$ man 1 groff
The grog command can be used to guess the correct groff
command to use to format a file.
