Hello, sous Windows c'est une des tâches qu'on entend comme nécessaires
à faire de temps en temps, il en est quoi sous Linux ? C'est nécessaire
de défragmenter ou pas ? Il y a des programmes de défragmentation ?
--
http://zetrader.info & http://zetrader.fr
Forum http://zeforums.com - http://aribaut.com
tout simplement parce qu'une tâche de fond le fait, dès que son analyse voit que la dispersion les clusters réceptacle d'un fichier ne sont plus contigus, dépasse 10%.
Tu n'as pas marre de ne dire que des bêtises ? Quand tu ne sais pas, tais-toi et apprends.
"zeLittle " , dans le message <op.y47p2ft9c5b0tx@mainate.home>, a
écrit :
tout simplement parce
qu'une tâche de fond le fait, dès que son analyse voit que la dispersion
les clusters réceptacle d'un fichier ne sont plus contigus, dépasse 10%.
Tu n'as pas marre de ne dire que des bêtises ? Quand tu ne sais pas,
tais-toi et apprends.
tout simplement parce qu'une tâche de fond le fait, dès que son analyse voit que la dispersion les clusters réceptacle d'un fichier ne sont plus contigus, dépasse 10%.
Tu n'as pas marre de ne dire que des bêtises ? Quand tu ne sais pas, tais-toi et apprends.
Marc SCHAEFER
JKB wrote:
Sinon, même si on est hors charte, comment fais-tu un fsck en production sur un BSD ? Je n'ai jamais réussi, même avec un FFSv2.
Alors, ça fait des années que je n'ai plus joué avec les *BSD. Mais une référence sur le `background fsck', qui permet de monter un fs en rw alors qu'un fsck est lancé en parallèle: http://blog.e-shell.org/266 "FreeBSD has a nice feature in its UFS2 filesystem called background fsck, which allow dirty filesystems (filesystems that hadn't been unmounted properly/cleanly) to be mounted even if they need fsck to check them. Once mounted, a fsck process is started in the background, checking that partition." (notons que l'article parle de le désactiver, dans certains cas :-> -- et il y a plein de *BSD) NB: j'ai oublié de mentionner qu'il semble qu'en plus de ZFS plutôt orienté `fiabilité' et `intégration de volumes', il y a btrfs, avec notamment du copy&write sans bricolage, assez utile pour lancer 100 machines virtuelles sur le même fs de base avec un fichier de `différence' copy&write par machine: un peu comme un unionfs un peu automatique.
JKB <jkb@koenigsberg.invalid> wrote:
Sinon, même si on est hors charte, comment fais-tu un fsck en
production sur un BSD ? Je n'ai jamais réussi, même avec un FFSv2.
Alors, ça fait des années que je n'ai plus joué avec les *BSD.
Mais une référence sur le `background fsck', qui permet de monter
un fs en rw alors qu'un fsck est lancé en parallèle:
http://blog.e-shell.org/266
"FreeBSD has a nice feature in its UFS2 filesystem called background
fsck, which allow dirty filesystems (filesystems that hadn't been
unmounted properly/cleanly) to be mounted even if they need fsck
to check them. Once mounted, a fsck process is started in
the background, checking that partition."
(notons que l'article parle de le désactiver, dans certains
cas :-> -- et il y a plein de *BSD)
NB: j'ai oublié de mentionner qu'il semble qu'en plus de ZFS
plutôt orienté `fiabilité' et `intégration de volumes', il y a
btrfs, avec notamment du copy&write sans bricolage, assez
utile pour lancer 100 machines virtuelles sur le même fs
de base avec un fichier de `différence' copy&write par
machine: un peu comme un unionfs un peu automatique.
Sinon, même si on est hors charte, comment fais-tu un fsck en production sur un BSD ? Je n'ai jamais réussi, même avec un FFSv2.
Alors, ça fait des années que je n'ai plus joué avec les *BSD. Mais une référence sur le `background fsck', qui permet de monter un fs en rw alors qu'un fsck est lancé en parallèle: http://blog.e-shell.org/266 "FreeBSD has a nice feature in its UFS2 filesystem called background fsck, which allow dirty filesystems (filesystems that hadn't been unmounted properly/cleanly) to be mounted even if they need fsck to check them. Once mounted, a fsck process is started in the background, checking that partition." (notons que l'article parle de le désactiver, dans certains cas :-> -- et il y a plein de *BSD) NB: j'ai oublié de mentionner qu'il semble qu'en plus de ZFS plutôt orienté `fiabilité' et `intégration de volumes', il y a btrfs, avec notamment du copy&write sans bricolage, assez utile pour lancer 100 machines virtuelles sur le même fs de base avec un fichier de `différence' copy&write par machine: un peu comme un unionfs un peu automatique.
JKB
Le Sat, 19 Aug 2017 12:59:34 +0200 (CEST), Marc SCHAEFER écrivait :
JKB wrote:
Sinon, même si on est hors charte, comment fais-tu un fsck en production sur un BSD ? Je n'ai jamais réussi, même avec un FFSv2.
Alors, ça fait des années que je n'ai plus joué avec les *BSD. Mais une référence sur le `background fsck', qui permet de monter un fs en rw alors qu'un fsck est lancé en parallèle: http://blog.e-shell.org/266 "FreeBSD has a nice feature in its UFS2 filesystem called background fsck, which allow dirty filesystems (filesystems that hadn't been unmounted properly/cleanly) to be mounted even if they need fsck to check them. Once mounted, a fsck process is started in the background, checking that partition."
Ah... C'est du FreeBSD, le boubounetou pas sec des BSD. Faire un fsck en background alors que le système est assez instable (je pense au pilote re en particulier qui est capable de mettre le noyau en vrac...) me semble un peu spécieux.
(notons que l'article parle de le désactiver, dans certains cas :-> -- et il y a plein de *BSD)
Ouaips, personnellement, je préfère la stabilité d'un NetBSD aux fonctionnalités expérimentales et pas sèches d'un Free, mais je te remercie pour l'URL.
NB: j'ai oublié de mentionner qu'il semble qu'en plus de ZFS plutôt orienté `fiabilité' et `intégration de volumes', il y a btrfs, avec notamment du copy&write sans bricolage, assez utile pour lancer 100 machines virtuelles sur le même fs de base avec un fichier de `différence' copy&write par machine: un peu comme un unionfs un peu automatique.
Il y a actuellement une bataille sur debian-fr sur ce sujet :-P Cordialement, JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Sat, 19 Aug 2017 12:59:34 +0200 (CEST),
Marc SCHAEFER <schaefer@alphanet.ch> écrivait :
JKB <jkb@koenigsberg.invalid> wrote:
Sinon, même si on est hors charte, comment fais-tu un fsck en
production sur un BSD ? Je n'ai jamais réussi, même avec un FFSv2.
Alors, ça fait des années que je n'ai plus joué avec les *BSD.
Mais une référence sur le `background fsck', qui permet de monter
un fs en rw alors qu'un fsck est lancé en parallèle:
http://blog.e-shell.org/266
"FreeBSD has a nice feature in its UFS2 filesystem called background
fsck, which allow dirty filesystems (filesystems that hadn't been
unmounted properly/cleanly) to be mounted even if they need fsck
to check them. Once mounted, a fsck process is started in
the background, checking that partition."
Ah... C'est du FreeBSD, le boubounetou pas sec des BSD. Faire un
fsck en background alors que le système est assez instable (je pense
au pilote re en particulier qui est capable de mettre le noyau en
vrac...) me semble un peu spécieux.
(notons que l'article parle de le désactiver, dans certains
cas :-> -- et il y a plein de *BSD)
Ouaips, personnellement, je préfère la stabilité d'un NetBSD aux
fonctionnalités expérimentales et pas sèches d'un Free, mais je te
remercie pour l'URL.
NB: j'ai oublié de mentionner qu'il semble qu'en plus de ZFS
plutôt orienté `fiabilité' et `intégration de volumes', il y a
btrfs, avec notamment du copy&write sans bricolage, assez
utile pour lancer 100 machines virtuelles sur le même fs
de base avec un fichier de `différence' copy&write par
machine: un peu comme un unionfs un peu automatique.
Il y a actuellement une bataille sur debian-fr sur ce sujet :-P
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Sat, 19 Aug 2017 12:59:34 +0200 (CEST), Marc SCHAEFER écrivait :
JKB wrote:
Sinon, même si on est hors charte, comment fais-tu un fsck en production sur un BSD ? Je n'ai jamais réussi, même avec un FFSv2.
Alors, ça fait des années que je n'ai plus joué avec les *BSD. Mais une référence sur le `background fsck', qui permet de monter un fs en rw alors qu'un fsck est lancé en parallèle: http://blog.e-shell.org/266 "FreeBSD has a nice feature in its UFS2 filesystem called background fsck, which allow dirty filesystems (filesystems that hadn't been unmounted properly/cleanly) to be mounted even if they need fsck to check them. Once mounted, a fsck process is started in the background, checking that partition."
Ah... C'est du FreeBSD, le boubounetou pas sec des BSD. Faire un fsck en background alors que le système est assez instable (je pense au pilote re en particulier qui est capable de mettre le noyau en vrac...) me semble un peu spécieux.
(notons que l'article parle de le désactiver, dans certains cas :-> -- et il y a plein de *BSD)
Ouaips, personnellement, je préfère la stabilité d'un NetBSD aux fonctionnalités expérimentales et pas sèches d'un Free, mais je te remercie pour l'URL.
NB: j'ai oublié de mentionner qu'il semble qu'en plus de ZFS plutôt orienté `fiabilité' et `intégration de volumes', il y a btrfs, avec notamment du copy&write sans bricolage, assez utile pour lancer 100 machines virtuelles sur le même fs de base avec un fichier de `différence' copy&write par machine: un peu comme un unionfs un peu automatique.
Il y a actuellement une bataille sur debian-fr sur ce sujet :-P Cordialement, JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Marc SCHAEFER
Et pour répondre (autrement) à la question initiale: btrfs semble supporter la défragmentation `en-ligne' d'après https://en.wikipedia.org/wiki/Btrfs#Features Voir aussi https://kernelnewbies.org/Linux_3.0#head-3e596e03408e1d32a7cc381d6f54e87feee22ee4 Apparemment c'est justement le support copy-on-write qui crée ce besoin de défragmentation. (souvent, sous Linux, on parle de fichier non contigu plutôt que de fragments car les fragments étaient des unités de bloc de fs utilisés par plusieurs fichiers). NB: je crois que btrfs est encore béta.
Et pour répondre (autrement) à la question initiale:
btrfs semble supporter la défragmentation `en-ligne' d'après
https://en.wikipedia.org/wiki/Btrfs#Features
Voir aussi https://kernelnewbies.org/Linux_3.0#head-3e596e03408e1d32a7cc381d6f54e87feee22ee4
Apparemment c'est justement le support copy-on-write qui crée ce besoin de
défragmentation.
(souvent, sous Linux, on parle de fichier non contigu plutôt que de
fragments car les fragments étaient des unités de bloc de fs utilisés
par plusieurs fichiers).
Et pour répondre (autrement) à la question initiale: btrfs semble supporter la défragmentation `en-ligne' d'après https://en.wikipedia.org/wiki/Btrfs#Features Voir aussi https://kernelnewbies.org/Linux_3.0#head-3e596e03408e1d32a7cc381d6f54e87feee22ee4 Apparemment c'est justement le support copy-on-write qui crée ce besoin de défragmentation. (souvent, sous Linux, on parle de fichier non contigu plutôt que de fragments car les fragments étaient des unités de bloc de fs utilisés par plusieurs fichiers). NB: je crois que btrfs est encore béta.
Yliur
Le Sat, 19 Aug 2017 12:21:05 +0200 "zeLittle " a écrit :
Le Sat, 19 Aug 2017 12:00:23 +0200, Nicolas George <nicolas$ a écrit:
"zeLittle " , dans le message , a écrit :
tout simplement parce qu'une tâche de fond le fait, dès que son analyse voit que la dispersion les clusters réceptacle d'un fichier ne sont plus contigus, dépasse 10%.
Tu n'as pas marre de ne dire que des bêtises ? Quand tu ne sais pas, tais-toi et apprends.
"How Linux File Systems Work Linux’s ext2, ext3, and ext4 file systems – ext4 being the file system used by Ubuntu and most other current Linux distributions – allocates files in a more intelligent way. Instead of placing multiple files near each other on the hard disk, Linux file systems scatter different files all over the disk, leaving a large amount of free space between them. When a file is edited and needs to grow, there’s usually plenty of free space for the file to grow into.
Cette partie indique que de l'espace est laissé entre les fichiers pour pouvoir ajouter des données dedans plus tard. Au passage : au-delà des journaux, compléter un fichier après coup ne semble pas concerner énormément de fichiers. Est-ce utile parce que Linux ne sait pas combien il y en aura au total quand on lui envoie le début des données à écrire ?
★★★ ➔ If fragmentation does occur, the file system will attempt to move the files around to reduce fragmentation in normal use, without the need for a defragmentation utility. ★★★"
Ça n'indique pas forcément que ça lance un processus en arrière-plan. Ça peut être juste déplacer les fichiers quand ils sont réécrits. En tout cas ça n'indique pas quand ça se passe, ni d'où sortent les 10%
Source: https://www.howtogeek.com/115229/htg-explains-why-linux-doesnt-need-defragmenting/ Et je n'en chercherai pas d'autres. Je m'étais déjà posé la question, et les sources les plus didactives (un mot que tu n'as peut être pas encore appris),
Peut-être parce qu'il n'existe pas ? https://fr.wiktionary.org/wiki/didactique
expliquaient toutes cela avec des variantes sur le quoi et comment et conséquence de quand défragmenter, selon un formatage ext2, ext3, et ext4.
Mais on n'aura pas les fameuses sources ?
Le Sat, 19 Aug 2017 12:21:05 +0200
"zeLittle " <noreply@noreply.net> a écrit :
Le Sat, 19 Aug 2017 12:00:23 +0200, Nicolas George
<nicolas$george@salle-s.org> a écrit:
> "zeLittle " , dans le message <op.y47p2ft9c5b0tx@mainate.home>, a
> écrit :
>> tout simplement
>> parce qu'une tâche de fond le fait, dès que son analyse voit que
>> la dispersion les clusters réceptacle d'un fichier ne sont plus
>> contigus, dépasse 10%.
>
> Tu n'as pas marre de ne dire que des bêtises ? Quand tu ne sais pas,
> tais-toi et apprends.
"How Linux File Systems Work
Linux’s ext2, ext3, and ext4 file systems – ext4 being the file
system used by Ubuntu and most other current Linux distributions –
allocates files in a more intelligent way. Instead of placing
multiple files near each other on the hard disk, Linux file systems
scatter different files all over the disk, leaving a large amount of
free space between them. When a file is edited and needs to grow,
there’s usually plenty of free space for the file to grow into.
Cette partie indique que de l'espace est laissé entre les fichiers pour
pouvoir ajouter des données dedans plus tard.
Au passage : au-delà des journaux, compléter un fichier après coup ne
semble pas concerner énormément de fichiers. Est-ce utile parce que
Linux ne sait pas combien il y en aura au total quand on lui envoie le
début des données à écrire ?
★★★ ➔ If fragmentation does occur, the file system will attempt to
move the files around to reduce fragmentation in normal use, without
the need for a defragmentation utility. ★★★"
Ça n'indique pas forcément que ça lance un processus en arrière-plan.
Ça peut être juste déplacer les fichiers quand ils sont réécrits. En
tout cas ça n'indique pas quand ça se passe, ni d'où sortent les 10%
Source:
https://www.howtogeek.com/115229/htg-explains-why-linux-doesnt-need-defragmenting/
Et je n'en chercherai pas d'autres. Je m'étais déjà posé la question,
et les sources les plus didactives (un mot que tu n'as peut être pas
encore appris),
Peut-être parce qu'il n'existe pas ?
https://fr.wiktionary.org/wiki/didactique
expliquaient toutes cela avec des variantes sur le
quoi et comment et conséquence de quand défragmenter, selon un
formatage ext2, ext3, et ext4.
Le Sat, 19 Aug 2017 12:21:05 +0200 "zeLittle " a écrit :
Le Sat, 19 Aug 2017 12:00:23 +0200, Nicolas George <nicolas$ a écrit:
"zeLittle " , dans le message , a écrit :
tout simplement parce qu'une tâche de fond le fait, dès que son analyse voit que la dispersion les clusters réceptacle d'un fichier ne sont plus contigus, dépasse 10%.
Tu n'as pas marre de ne dire que des bêtises ? Quand tu ne sais pas, tais-toi et apprends.
"How Linux File Systems Work Linux’s ext2, ext3, and ext4 file systems – ext4 being the file system used by Ubuntu and most other current Linux distributions – allocates files in a more intelligent way. Instead of placing multiple files near each other on the hard disk, Linux file systems scatter different files all over the disk, leaving a large amount of free space between them. When a file is edited and needs to grow, there’s usually plenty of free space for the file to grow into.
Cette partie indique que de l'espace est laissé entre les fichiers pour pouvoir ajouter des données dedans plus tard. Au passage : au-delà des journaux, compléter un fichier après coup ne semble pas concerner énormément de fichiers. Est-ce utile parce que Linux ne sait pas combien il y en aura au total quand on lui envoie le début des données à écrire ?
★★★ ➔ If fragmentation does occur, the file system will attempt to move the files around to reduce fragmentation in normal use, without the need for a defragmentation utility. ★★★"
Ça n'indique pas forcément que ça lance un processus en arrière-plan. Ça peut être juste déplacer les fichiers quand ils sont réécrits. En tout cas ça n'indique pas quand ça se passe, ni d'où sortent les 10%
Source: https://www.howtogeek.com/115229/htg-explains-why-linux-doesnt-need-defragmenting/ Et je n'en chercherai pas d'autres. Je m'étais déjà posé la question, et les sources les plus didactives (un mot que tu n'as peut être pas encore appris),
Peut-être parce qu'il n'existe pas ? https://fr.wiktionary.org/wiki/didactique
expliquaient toutes cela avec des variantes sur le quoi et comment et conséquence de quand défragmenter, selon un formatage ext2, ext3, et ext4.
Mais on n'aura pas les fameuses sources ?
Nicolas George
Yliur , dans le message , a écrit :
Au passage : au-delà des journaux, compléter un fichier après coup ne semble pas concerner énormément de fichiers. Est-ce utile parce que Linux ne sait pas combien il y en aura au total quand on lui envoie le début des données à écrire ?
C'est en gros ça. L'interface pour créer et remplir des fichiers n'a quasiment pas évolué depuis les premiers Unix : on ouvre/crée le fichier, on écrit dedans, on ferme. Il n'y a pas de moyen standard pour indiquer la taille prévue du fichier. Si on devait concevoir les choses de nos jours à neuf, je pense qu'on utiliserait principalement un appel système pour créer un fichiers avec son contenu.
Ça n'indique pas forcément que ça lance un processus en arrière-plan. Ça peut être juste déplacer les fichiers quand ils sont réécrits. En tout cas ça n'indique pas quand ça se passe, ni d'où sortent les 10%
Tu as eu le courage d'expliciter exactement où ton interlocuteur affabule.
Yliur , dans le message <20170819143237.09304735@free.fr>, a écrit :
Au passage : au-delà des journaux, compléter un fichier après coup ne
semble pas concerner énormément de fichiers. Est-ce utile parce que
Linux ne sait pas combien il y en aura au total quand on lui envoie le
début des données à écrire ?
C'est en gros ça. L'interface pour créer et remplir des fichiers n'a
quasiment pas évolué depuis les premiers Unix : on ouvre/crée le
fichier, on écrit dedans, on ferme. Il n'y a pas de moyen standard pour
indiquer la taille prévue du fichier.
Si on devait concevoir les choses de nos jours à neuf, je pense qu'on
utiliserait principalement un appel système pour créer un fichiers avec
son contenu.
Ça n'indique pas forcément que ça lance un processus en arrière-plan.
Ça peut être juste déplacer les fichiers quand ils sont réécrits. En
tout cas ça n'indique pas quand ça se passe, ni d'où sortent les 10%
Tu as eu le courage d'expliciter exactement où ton interlocuteur
affabule.
Au passage : au-delà des journaux, compléter un fichier après coup ne semble pas concerner énormément de fichiers. Est-ce utile parce que Linux ne sait pas combien il y en aura au total quand on lui envoie le début des données à écrire ?
C'est en gros ça. L'interface pour créer et remplir des fichiers n'a quasiment pas évolué depuis les premiers Unix : on ouvre/crée le fichier, on écrit dedans, on ferme. Il n'y a pas de moyen standard pour indiquer la taille prévue du fichier. Si on devait concevoir les choses de nos jours à neuf, je pense qu'on utiliserait principalement un appel système pour créer un fichiers avec son contenu.
Ça n'indique pas forcément que ça lance un processus en arrière-plan. Ça peut être juste déplacer les fichiers quand ils sont réécrits. En tout cas ça n'indique pas quand ça se passe, ni d'où sortent les 10%
Tu as eu le courage d'expliciter exactement où ton interlocuteur affabule.
Marc SCHAEFER
Nicolas George <nicolas$ wrote:
fichier, on écrit dedans, on ferme. Il n'y a pas de moyen standard pour indiquer la taille prévue du fichier.
Et souvent c'est mieux, vu le fonctionnement en filtre de nombreux programmes UNIX. On peut toutefois faire un seek à l'endroit de la taille, puis écrire quelque chose. Mais ça crée un sparse file (un fichier dont les blocs non écrits sont lus à zéro et si écrits, alloués). Donc ici, on ne veut surtout pas que les blocs intermédiaires soient alloués.
Si on devait concevoir les choses de nos jours à neuf, je pense qu'on utiliserait principalement un appel système pour créer un fichiers avec son contenu.
Quelle horreur :) NB: si tu as le contenu du fichiers, écris-le alors, et la plupart des fs modernes vont joliment répartir les données de manière non fragmentée. Rien à faire de spécial. NB/2: le seul fs qui je crois utilise la taille des fichiers pour les créer c'est isofs, en read-only.
Nicolas George <nicolas$george@salle-s.org> wrote:
fichier, on écrit dedans, on ferme. Il n'y a pas de moyen standard pour
indiquer la taille prévue du fichier.
Et souvent c'est mieux, vu le fonctionnement en filtre de nombreux
programmes UNIX.
On peut toutefois faire un seek à l'endroit de la taille, puis écrire
quelque chose. Mais ça crée un sparse file (un fichier dont les blocs
non écrits sont lus à zéro et si écrits, alloués). Donc ici, on ne
veut surtout pas que les blocs intermédiaires soient alloués.
Si on devait concevoir les choses de nos jours à neuf, je pense qu'on
utiliserait principalement un appel système pour créer un fichiers avec
son contenu.
Quelle horreur :)
NB: si tu as le contenu du fichiers, écris-le alors, et la plupart
des fs modernes vont joliment répartir les données de manière non
fragmentée. Rien à faire de spécial.
NB/2: le seul fs qui je crois utilise la taille des fichiers pour les
créer c'est isofs, en read-only.
fichier, on écrit dedans, on ferme. Il n'y a pas de moyen standard pour indiquer la taille prévue du fichier.
Et souvent c'est mieux, vu le fonctionnement en filtre de nombreux programmes UNIX. On peut toutefois faire un seek à l'endroit de la taille, puis écrire quelque chose. Mais ça crée un sparse file (un fichier dont les blocs non écrits sont lus à zéro et si écrits, alloués). Donc ici, on ne veut surtout pas que les blocs intermédiaires soient alloués.
Si on devait concevoir les choses de nos jours à neuf, je pense qu'on utiliserait principalement un appel système pour créer un fichiers avec son contenu.
Quelle horreur :) NB: si tu as le contenu du fichiers, écris-le alors, et la plupart des fs modernes vont joliment répartir les données de manière non fragmentée. Rien à faire de spécial. NB/2: le seul fs qui je crois utilise la taille des fichiers pour les créer c'est isofs, en read-only.
Pascal Hambourg
Le 19/08/2017 à 01:05, Th.A.C a écrit :
Le 18/08/2017 à 23:03, Nicolas George a écrit :
"Th.A.C" , dans le message <59975215$0$3318$, a écrit :
Parce qu'ils vont occuper de grosses zones et donc laisser de petites zones.
Ton raisonnement n'est pas logique. S'il y a un gros fichier, il laisse deux zones, donc leur taille moyenne est la moitié de l'espace disponible. S'il y a dix petits fichiers, ils laissent onze zones, donc leur taille moyenne est un onzième de l'espace disponible.
Parce qu'il est bien plus difficile de garder de grosses zones libres en mettant des gros fichiers quand on arrive à un certain taux d'occupation.
Plus difficile qu'en mettant des petits fichiers occupant la même quantité d'espace que des gros fichiers ?
Il arrivera forcément un moment ou mettre un gros fichier ne laissera plus que (ou presque) des 'petites zones'. S'il ne reste que des petites zones, le système aura plus de mal à limiter la fragmentation. Alors qu'avec de petits fichiers, il y a plus de chance de 'combler' des trous pour laisser de grosses zones libres.
Quelle importance ? Et puis c'est quoi un "gros" fichier, une "grosse" zone libre ? Qu'un fichier de 10 Mo soit contigu ou fragmenté en 2 ou 3 n'a qu'un impact négligeable sur son temps de lecture sur un disque dur. Avec un fichier de 10 ko, c'est très différent. A mon avis, un des problèmes de la fragmentation est la pertinence de la métrique. Une métrique pertinente devrait permettre d'estimer l'impact sur les performances. Or le seul pourcentage des fichiers non contigus tel qu'affiché par fsck ne suffit pas. Pour cela, il plutôt afficher le nombre de fragments.
Le 19/08/2017 à 01:05, Th.A.C a écrit :
Le 18/08/2017 à 23:03, Nicolas George a écrit :
"Th.A.C" , dans le message <59975215$0$3318$426a74cc@news.free.fr>, a
écrit :
Parce qu'ils vont occuper de grosses zones et donc laisser de petites
zones.
Ton raisonnement n'est pas logique. S'il y a un gros fichier, il laisse
deux zones, donc leur taille moyenne est la moitié de l'espace
disponible. S'il y a dix petits fichiers, ils laissent onze zones, donc
leur taille moyenne est un onzième de l'espace disponible.
Parce qu'il est bien plus difficile de garder de grosses zones libres en
mettant des gros fichiers quand on arrive à un certain taux d'occupation.
Plus difficile qu'en mettant des petits fichiers occupant la même
quantité d'espace que des gros fichiers ?
Il arrivera forcément un moment ou mettre un gros fichier ne laissera
plus que (ou presque) des 'petites zones'.
S'il ne reste que des petites zones, le système aura plus de mal à
limiter la fragmentation.
Alors qu'avec de petits fichiers, il y a plus de chance de 'combler' des
trous pour laisser de grosses zones libres.
Quelle importance ?
Et puis c'est quoi un "gros" fichier, une "grosse" zone libre ?
Qu'un fichier de 10 Mo soit contigu ou fragmenté en 2 ou 3 n'a qu'un
impact négligeable sur son temps de lecture sur un disque dur. Avec un
fichier de 10 ko, c'est très différent.
A mon avis, un des problèmes de la fragmentation est la pertinence de la
métrique. Une métrique pertinente devrait permettre d'estimer l'impact
sur les performances. Or le seul pourcentage des fichiers non contigus
tel qu'affiché par fsck ne suffit pas. Pour cela, il plutôt afficher le
nombre de fragments.
"Th.A.C" , dans le message <59975215$0$3318$, a écrit :
Parce qu'ils vont occuper de grosses zones et donc laisser de petites zones.
Ton raisonnement n'est pas logique. S'il y a un gros fichier, il laisse deux zones, donc leur taille moyenne est la moitié de l'espace disponible. S'il y a dix petits fichiers, ils laissent onze zones, donc leur taille moyenne est un onzième de l'espace disponible.
Parce qu'il est bien plus difficile de garder de grosses zones libres en mettant des gros fichiers quand on arrive à un certain taux d'occupation.
Plus difficile qu'en mettant des petits fichiers occupant la même quantité d'espace que des gros fichiers ?
Il arrivera forcément un moment ou mettre un gros fichier ne laissera plus que (ou presque) des 'petites zones'. S'il ne reste que des petites zones, le système aura plus de mal à limiter la fragmentation. Alors qu'avec de petits fichiers, il y a plus de chance de 'combler' des trous pour laisser de grosses zones libres.
Quelle importance ? Et puis c'est quoi un "gros" fichier, une "grosse" zone libre ? Qu'un fichier de 10 Mo soit contigu ou fragmenté en 2 ou 3 n'a qu'un impact négligeable sur son temps de lecture sur un disque dur. Avec un fichier de 10 ko, c'est très différent. A mon avis, un des problèmes de la fragmentation est la pertinence de la métrique. Une métrique pertinente devrait permettre d'estimer l'impact sur les performances. Or le seul pourcentage des fichiers non contigus tel qu'affiché par fsck ne suffit pas. Pour cela, il plutôt afficher le nombre de fragments.
Yliur
Le Sat, 19 Aug 2017 23:10:44 +0200 "zeLittle " a écrit :
Le Sat, 19 Aug 2017 14:32:37 +0200, Yliur a écrit:
Cette partie indique que de l'espace est laissé entre les fichiers pour pouvoir ajouter des données dedans plus tard.
Merci. C'est donc plus un astucieux système qui empêche la fragmentation, qu'une défragmentation.
Plutôt, oui.
Ben, ext4 joue moins sur les mots: il vient avec un utilitaire "e4defrag", [...] je vais me faire une tâche CRON qui le lancera régulièrement. Ça ne peut que m'informer visuellement sur l'état de mon disque dur selon les changements de contenu qu'il a subit, et lui faire du bien.
Il est probable que le travail d'ext4 au jour le jour soit déjà très satisfaisant, sans qu'il y ait besoin de repasser derrière (pas de dégradation progressive). Quel est l'intérêt de passer régulièrement des opérations de maintenance si en permanence le système de fichiers est déjà dans un très bon état ? Le fait de le passer dans un état "parfaitement propre" est assez illusoire, à moins que tu aies un besoin très particulier.
Le Sat, 19 Aug 2017 23:10:44 +0200
"zeLittle " <noreply@noreply.net> a écrit :
Le Sat, 19 Aug 2017 14:32:37 +0200, Yliur <yliur@free.fr> a écrit:
> Cette partie indique que de l'espace est laissé entre les fichiers
> pour pouvoir ajouter des données dedans plus tard.
Merci. C'est donc plus un astucieux système qui empêche la
fragmentation, qu'une défragmentation.
Plutôt, oui.
Ben, ext4 joue moins sur les mots: il vient avec un utilitaire
"e4defrag", [...] je vais me faire une tâche CRON qui le
lancera régulièrement. Ça ne peut que m'informer visuellement sur
l'état de mon disque dur selon les changements de contenu qu'il a
subit, et lui faire du bien.
Il est probable que le travail d'ext4 au jour le jour soit déjà très
satisfaisant, sans qu'il y ait besoin de repasser derrière (pas de
dégradation progressive). Quel est l'intérêt de passer régulièrement des
opérations de maintenance si en permanence le système de fichiers est
déjà dans un très bon état ? Le fait de le passer dans un état
"parfaitement propre" est assez illusoire, à moins que tu aies un
besoin très particulier.
Le Sat, 19 Aug 2017 23:10:44 +0200 "zeLittle " a écrit :
Le Sat, 19 Aug 2017 14:32:37 +0200, Yliur a écrit:
Cette partie indique que de l'espace est laissé entre les fichiers pour pouvoir ajouter des données dedans plus tard.
Merci. C'est donc plus un astucieux système qui empêche la fragmentation, qu'une défragmentation.
Plutôt, oui.
Ben, ext4 joue moins sur les mots: il vient avec un utilitaire "e4defrag", [...] je vais me faire une tâche CRON qui le lancera régulièrement. Ça ne peut que m'informer visuellement sur l'état de mon disque dur selon les changements de contenu qu'il a subit, et lui faire du bien.
Il est probable que le travail d'ext4 au jour le jour soit déjà très satisfaisant, sans qu'il y ait besoin de repasser derrière (pas de dégradation progressive). Quel est l'intérêt de passer régulièrement des opérations de maintenance si en permanence le système de fichiers est déjà dans un très bon état ? Le fait de le passer dans un état "parfaitement propre" est assez illusoire, à moins que tu aies un besoin très particulier.
capfree
Le 20/08/2017 à 00:30, Yliur a écrit :
Il est probable que le travail d'ext4 au jour le jour soit déjà très satisfaisant, sans qu'il y ait besoin de repasser derrière (pas de dégradation progressive). Quel est l'intérêt de passer régulièrement des opérations de maintenance si en permanence le système de fichiers est déjà dans un très bon état ? Le fait de le passer dans un état "parfaitement propre" est assez illusoire, à moins que tu aies un besoin très particulier.
Question, si à l'occasion on transfère système et home sur un disque pré-partitionné mais vide, la localisation des fichiers serait-elle idéale? -- capfree -
Le 20/08/2017 à 00:30, Yliur a écrit :
Il est probable que le travail d'ext4 au jour le jour soit déjà très
satisfaisant, sans qu'il y ait besoin de repasser derrière (pas de
dégradation progressive). Quel est l'intérêt de passer régulièrement
des opérations de maintenance si en permanence le système de fichiers
est déjà dans un très bon état ? Le fait de le passer dans un état
"parfaitement propre" est assez illusoire, à moins que tu aies un
besoin très particulier.
Question, si à l'occasion on transfère système et home sur un disque
pré-partitionné mais vide, la localisation des fichiers serait-elle idéale?
Il est probable que le travail d'ext4 au jour le jour soit déjà très satisfaisant, sans qu'il y ait besoin de repasser derrière (pas de dégradation progressive). Quel est l'intérêt de passer régulièrement des opérations de maintenance si en permanence le système de fichiers est déjà dans un très bon état ? Le fait de le passer dans un état "parfaitement propre" est assez illusoire, à moins que tu aies un besoin très particulier.
Question, si à l'occasion on transfère système et home sur un disque pré-partitionné mais vide, la localisation des fichiers serait-elle idéale? -- capfree -
