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
Le 18/08/2017 à 17:03, Pierre www.zetrader.fr a écrit :
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 ?
Ni sous Linux, ni sous Windows (avec NTFS...) cela est nécessaire. C'était valable sous MS-DOS et Windows 9x, mais avec extx (sous Linux) et NTFS (sous Windows), la défragmentation ne sert à rien. C'est une légende urbaine colportée par les vendeurs de programmes de défragmentation... -- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 18/08/2017 à 17:03, Pierre www.zetrader.fr a écrit :
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 ?
Ni sous Linux, ni sous Windows (avec NTFS...) cela est nécessaire. C'était valable sous MS-DOS et Windows 9x, mais avec extx (sous
Linux) et NTFS (sous Windows), la défragmentation ne sert à rien. C'est une légende urbaine colportée par les vendeurs de programmes
de défragmentation...
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Le 18/08/2017 à 17:03, Pierre www.zetrader.fr a écrit :
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 ?
Ni sous Linux, ni sous Windows (avec NTFS...) cela est nécessaire. C'était valable sous MS-DOS et Windows 9x, mais avec extx (sous Linux) et NTFS (sous Windows), la défragmentation ne sert à rien. C'est une légende urbaine colportée par les vendeurs de programmes de défragmentation... -- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Th.A.C
Le 18/08/2017 à 17:53, Sergio a écrit :
Le 18/08/2017 à 17:03, Pierre www.zetrader.fr a écrit :
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 ?
Ni sous Linux, ni sous Windows (avec NTFS...) cela est nécessaire. C'était valable sous MS-DOS et Windows 9x, mais avec extx (sous Linux) et NTFS (sous Windows), la défragmentation ne sert à rien. C'est une légende urbaine colportée par les vendeurs de programmes de défragmentation...
Sous linux, sauf conditions particulières (en général une grosse occupation disque et beaucoup de fichiers dont des gros, ou une très grosse activité disque sur un disque bien occupé), ca ne sert pas à grand chose. Par contre sous windows, j'ai plein d'exemples persos et pros ou la défragmentation à largement amélioré le démarrage et la réactivité. (J'espère que ca ne va pas encore lancer un débat inutile...)
Le 18/08/2017 à 17:53, Sergio a écrit :
Le 18/08/2017 à 17:03, Pierre www.zetrader.fr a écrit :
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 ?
Ni sous Linux, ni sous Windows (avec NTFS...) cela est nécessaire.
C'était valable sous MS-DOS et Windows 9x, mais avec extx (sous Linux)
et NTFS (sous Windows), la défragmentation ne sert à rien. C'est une
légende urbaine colportée par les vendeurs de programmes de
défragmentation...
Sous linux, sauf conditions particulières (en général une grosse
occupation disque et beaucoup de fichiers dont des gros, ou une très
grosse activité disque sur un disque bien occupé), ca ne sert pas à
grand chose.
Par contre sous windows, j'ai plein d'exemples persos et pros ou la
défragmentation à largement amélioré le démarrage et la réactivité.
(J'espère que ca ne va pas encore lancer un débat inutile...)
Le 18/08/2017 à 17:03, Pierre www.zetrader.fr a écrit :
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 ?
Ni sous Linux, ni sous Windows (avec NTFS...) cela est nécessaire. C'était valable sous MS-DOS et Windows 9x, mais avec extx (sous Linux) et NTFS (sous Windows), la défragmentation ne sert à rien. C'est une légende urbaine colportée par les vendeurs de programmes de défragmentation...
Sous linux, sauf conditions particulières (en général une grosse occupation disque et beaucoup de fichiers dont des gros, ou une très grosse activité disque sur un disque bien occupé), ca ne sert pas à grand chose. Par contre sous windows, j'ai plein d'exemples persos et pros ou la défragmentation à largement amélioré le démarrage et la réactivité. (J'espère que ca ne va pas encore lancer un débat inutile...)
Pascal Hambourg
Le 18/08/2017 à 20:19, Th.A.C a écrit :
Sous linux, sauf conditions particulières (en général une grosse occupation disque et beaucoup de fichiers dont des gros, ou une très grosse activité disque sur un disque bien occupé), ca ne sert pas à grand chose.
En effet un espace libre faible (en dessous de ~10% à ce qu'on lit) favoriserait la fragmentation. Mais pourquoi "dont des gros" ?
Le 18/08/2017 à 20:19, Th.A.C a écrit :
Sous linux, sauf conditions particulières (en général une grosse
occupation disque et beaucoup de fichiers dont des gros, ou une très
grosse activité disque sur un disque bien occupé), ca ne sert pas à
grand chose.
En effet un espace libre faible (en dessous de ~10% à ce qu'on lit)
favoriserait la fragmentation.
Sous linux, sauf conditions particulières (en général une grosse occupation disque et beaucoup de fichiers dont des gros, ou une très grosse activité disque sur un disque bien occupé), ca ne sert pas à grand chose.
En effet un espace libre faible (en dessous de ~10% à ce qu'on lit) favoriserait la fragmentation. Mais pourquoi "dont des gros" ?
Th.A.C
Le 18/08/2017 à 20:30, Pascal Hambourg a écrit :
Le 18/08/2017 à 20:19, Th.A.C a écrit :
Sous linux, sauf conditions particulières (en général une grosse occupation disque et beaucoup de fichiers dont des gros, ou une très grosse activité disque sur un disque bien occupé), ca ne sert pas à grand chose.
En effet un espace libre faible (en dessous de ~10% à ce qu'on lit) favoriserait la fragmentation. Mais pourquoi "dont des gros" ?
Parce qu'ils vont occuper de grosses zones et donc laisser de petites zones. S'il n'y a que des petites zones, ca va favoriser la fragmentation.
Le 18/08/2017 à 20:30, Pascal Hambourg a écrit :
Le 18/08/2017 à 20:19, Th.A.C a écrit :
Sous linux, sauf conditions particulières (en général une grosse
occupation disque et beaucoup de fichiers dont des gros, ou une très
grosse activité disque sur un disque bien occupé), ca ne sert pas à
grand chose.
En effet un espace libre faible (en dessous de ~10% à ce qu'on lit)
favoriserait la fragmentation.
Mais pourquoi "dont des gros" ?
Parce qu'ils vont occuper de grosses zones et donc laisser de petites zones.
S'il n'y a que des petites zones, ca va favoriser la fragmentation.
Sous linux, sauf conditions particulières (en général une grosse occupation disque et beaucoup de fichiers dont des gros, ou une très grosse activité disque sur un disque bien occupé), ca ne sert pas à grand chose.
En effet un espace libre faible (en dessous de ~10% à ce qu'on lit) favoriserait la fragmentation. Mais pourquoi "dont des gros" ?
Parce qu'ils vont occuper de grosses zones et donc laisser de petites zones. S'il n'y a que des petites zones, ca va favoriser la fragmentation.
Nicolas George
"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.
"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.
"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.
Th.A.C
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. 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.
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.
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.
"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. 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.
Sergio
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.
"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.
Pour les petits fichiers, pas de souci : Dans NTFS (et je suppose que MS a copié sur les FS Linux...) ils sont stockés directement
dans les descripteurs.
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
"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.
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 ?
Non, et oui, mais jamais eu besoin quelque soit les types d'utilisation et sur des décennies. De mémoire: L'innovation principale de la famille des ext* sous Linux était la possibilité de prévoir l'expansion de fichiers par préallocation, ce qui diminue drastiquement la fragmentation (~1990). C'était l'atout principal de ext2 vs tous les fs à part les log-fs de BSD (des fs à ajout seul). A ma connaissance seul xfs (SGI IRIX, puis Linux) était meilleur à ce point de vue (linux ~1998). Toutefois, ext2 et les premières versions d'ext3 n'étaient pas journalisées, ce qui nécessitait de longs fsck (BSD seul supporte le fsck en production, et les logs-fs de BSD n'ont pas besoin de fsck). Notons que là, Microsoft et certains UNIX propriétaires avaient un avantage vu qu'ils supportaient déjà la journalisation, même si pas forcément ni configurable (structure seulement? structure et données? garanties que données justes ou zéro sans risque d'accès à des vieilles données d'un autre utilisateur?) ni très performante. Vers 1999 ext3 avec un support journalisation est sorti et a largement amélioré les performances de Linux en cas de panne de courant. Des bugs matériels bizarres comme des corruptions sur les disques ATA en cas de coupure de courant ont été découverts et work-aroundisés. La notion de `barrier' a été implémenté dans le kernel permettant des points de synchronisation garantis de bout en bout de manière performante. Enfin, début 2000 reiserfs a amené de nombreuses améliorations dans la gestion des inodes (plus de nécessité de les préallouer), des extents, la possibilité comme NTFSv5 (2007?) de stocker les petits fichiers directement dans l'inode, etc. Et la plupart de ces améliorations se sont retrouvées dans ext4 après le meurtre de la femme de l'auteur de reiserfs (la liaison de causalité est fausse, le meurtre est réel, Hans Reiser doit être encore en prison?). Et l'avantage de la plupart de ces améliorations est nullifié aujourd'hui par la généralisation du stockage de masse sans pénalité de lseek(2), soit les SSD. D'autres améliorations ont été implémentées pour tenir compte des caractéristiques de ces média (discard ou réutilisation des concepts des vieux log-fs p.ex.) Le block-device virtuel de Linux a aussi profité assez tôt des améliorations des contrôleurs comme le scatter-gather pour la performance CPU, des disques SATA comme le command-queuing (~1980 sur systèmes DEC et contrôleurs DILOG et SCSI, ~2000 sur SATA et Linux), appelé NCQ (la possibilité d'envoyer plusieurs commandes de suite à un disque-dur, charge à lui d'optimiser l'ordre en fonction des contraintes matérielles, permettant un gain de parallélisation notamment). D'ailleurs les premières années des bugs ont été trouvés dans certains firmwares de disque-dur et des tables d'incompatibilités étaient maintenus dans le kernel. La dernière (~2010?) innovation à ma connaissance est dans le domaine de l'intégrité[1]: Linux peut associer à des groupes de transfert de données des métadonnées d'intégrité qui sont contrôlées par exemple par le disque-dur, en plus des contrôles effectués par l'interface SATA et de la correction d'erreur intégrée dans chaque bloc. Cela permet à des filesystems orientés fiabilité comme ZFS de garantir l'ensemble du chemin et de pouvoir détecter le point de panne dans des scénarii complexes comme VFS -> block device -> RAID/LVM -> contrôleur SATA -> plusieurs disques-dur assemblés par un RAID matériel, un SAN, etc -> disque-dur individuel, lorsque supporté. [1] https://github.com/torvalds/linux/blob/master/Documentation/block/data-integrity.txt
Pierre www.zetrader.fr <www.zetrader.info> wrote:
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 ?
Non, et oui, mais jamais eu besoin quelque soit les types d'utilisation
et sur des décennies.
De mémoire:
L'innovation principale de la famille des ext* sous Linux était la
possibilité de prévoir l'expansion de fichiers par préallocation,
ce qui diminue drastiquement la fragmentation (~1990). C'était l'atout
principal de ext2 vs tous les fs à part les log-fs de BSD (des
fs à ajout seul). A ma connaissance seul xfs (SGI IRIX, puis
Linux) était meilleur à ce point de vue (linux ~1998).
Toutefois, ext2 et les premières versions d'ext3 n'étaient pas
journalisées, ce qui nécessitait de longs fsck (BSD seul supporte
le fsck en production, et les logs-fs de BSD n'ont pas besoin
de fsck). Notons que là, Microsoft et certains UNIX propriétaires
avaient un avantage vu qu'ils supportaient déjà la journalisation,
même si pas forcément ni configurable (structure seulement?
structure et données? garanties que données justes ou zéro sans
risque d'accès à des vieilles données d'un autre utilisateur?) ni
très performante.
Vers 1999 ext3 avec un support journalisation est sorti et a
largement amélioré les performances de Linux en cas de
panne de courant. Des bugs matériels bizarres comme des corruptions
sur les disques ATA en cas de coupure de courant ont été découverts
et work-aroundisés. La notion de `barrier' a été implémenté dans le
kernel permettant des points de synchronisation garantis de bout
en bout de manière performante.
Enfin, début 2000 reiserfs a amené de nombreuses améliorations dans
la gestion des inodes (plus de nécessité de les préallouer), des
extents, la possibilité comme NTFSv5 (2007?) de stocker les
petits fichiers directement dans l'inode, etc.
Et la plupart de ces améliorations se sont retrouvées dans ext4 après
le meurtre de la femme de l'auteur de reiserfs (la liaison de
causalité est fausse, le meurtre est réel, Hans Reiser
doit être encore en prison?).
Et l'avantage de la plupart de ces améliorations est nullifié aujourd'hui
par la généralisation du stockage de masse sans pénalité de lseek(2),
soit les SSD. D'autres améliorations ont été implémentées pour tenir
compte des caractéristiques de ces média (discard ou réutilisation
des concepts des vieux log-fs p.ex.)
Le block-device virtuel de Linux a aussi profité assez tôt
des améliorations des contrôleurs comme le scatter-gather
pour la performance CPU, des disques SATA comme le command-queuing
(~1980 sur systèmes DEC et contrôleurs DILOG et SCSI,
~2000 sur SATA et Linux), appelé NCQ (la possibilité d'envoyer
plusieurs commandes de suite à un disque-dur, charge à
lui d'optimiser l'ordre en fonction des contraintes
matérielles, permettant un gain de parallélisation notamment).
D'ailleurs les premières années des bugs ont été trouvés
dans certains firmwares de disque-dur et des tables d'incompatibilités
étaient maintenus dans le kernel.
La dernière (~2010?) innovation à ma connaissance est dans le domaine
de l'intégrité[1]: Linux peut associer à des groupes de
transfert de données des métadonnées d'intégrité qui sont
contrôlées par exemple par le disque-dur, en plus des contrôles
effectués par l'interface SATA et de la correction d'erreur
intégrée dans chaque bloc. Cela permet à des filesystems
orientés fiabilité comme ZFS de garantir l'ensemble du chemin
et de pouvoir détecter le point de panne dans des scénarii
complexes comme VFS -> block device -> RAID/LVM -> contrôleur
SATA -> plusieurs disques-dur assemblés par un RAID matériel,
un SAN, etc -> disque-dur individuel, lorsque supporté.
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 ?
Non, et oui, mais jamais eu besoin quelque soit les types d'utilisation et sur des décennies. De mémoire: L'innovation principale de la famille des ext* sous Linux était la possibilité de prévoir l'expansion de fichiers par préallocation, ce qui diminue drastiquement la fragmentation (~1990). C'était l'atout principal de ext2 vs tous les fs à part les log-fs de BSD (des fs à ajout seul). A ma connaissance seul xfs (SGI IRIX, puis Linux) était meilleur à ce point de vue (linux ~1998). Toutefois, ext2 et les premières versions d'ext3 n'étaient pas journalisées, ce qui nécessitait de longs fsck (BSD seul supporte le fsck en production, et les logs-fs de BSD n'ont pas besoin de fsck). Notons que là, Microsoft et certains UNIX propriétaires avaient un avantage vu qu'ils supportaient déjà la journalisation, même si pas forcément ni configurable (structure seulement? structure et données? garanties que données justes ou zéro sans risque d'accès à des vieilles données d'un autre utilisateur?) ni très performante. Vers 1999 ext3 avec un support journalisation est sorti et a largement amélioré les performances de Linux en cas de panne de courant. Des bugs matériels bizarres comme des corruptions sur les disques ATA en cas de coupure de courant ont été découverts et work-aroundisés. La notion de `barrier' a été implémenté dans le kernel permettant des points de synchronisation garantis de bout en bout de manière performante. Enfin, début 2000 reiserfs a amené de nombreuses améliorations dans la gestion des inodes (plus de nécessité de les préallouer), des extents, la possibilité comme NTFSv5 (2007?) de stocker les petits fichiers directement dans l'inode, etc. Et la plupart de ces améliorations se sont retrouvées dans ext4 après le meurtre de la femme de l'auteur de reiserfs (la liaison de causalité est fausse, le meurtre est réel, Hans Reiser doit être encore en prison?). Et l'avantage de la plupart de ces améliorations est nullifié aujourd'hui par la généralisation du stockage de masse sans pénalité de lseek(2), soit les SSD. D'autres améliorations ont été implémentées pour tenir compte des caractéristiques de ces média (discard ou réutilisation des concepts des vieux log-fs p.ex.) Le block-device virtuel de Linux a aussi profité assez tôt des améliorations des contrôleurs comme le scatter-gather pour la performance CPU, des disques SATA comme le command-queuing (~1980 sur systèmes DEC et contrôleurs DILOG et SCSI, ~2000 sur SATA et Linux), appelé NCQ (la possibilité d'envoyer plusieurs commandes de suite à un disque-dur, charge à lui d'optimiser l'ordre en fonction des contraintes matérielles, permettant un gain de parallélisation notamment). D'ailleurs les premières années des bugs ont été trouvés dans certains firmwares de disque-dur et des tables d'incompatibilités étaient maintenus dans le kernel. La dernière (~2010?) innovation à ma connaissance est dans le domaine de l'intégrité[1]: Linux peut associer à des groupes de transfert de données des métadonnées d'intégrité qui sont contrôlées par exemple par le disque-dur, en plus des contrôles effectués par l'interface SATA et de la correction d'erreur intégrée dans chaque bloc. Cela permet à des filesystems orientés fiabilité comme ZFS de garantir l'ensemble du chemin et de pouvoir détecter le point de panne dans des scénarii complexes comme VFS -> block device -> RAID/LVM -> contrôleur SATA -> plusieurs disques-dur assemblés par un RAID matériel, un SAN, etc -> disque-dur individuel, lorsque supporté. [1] https://github.com/torvalds/linux/blob/master/Documentation/block/data-integrity.txt
JKB
Le Sat, 19 Aug 2017 08:56:17 +0200 (CEST), Marc SCHAEFER écrivait :
Toutefois, ext2 et les premières versions d'ext3 n'étaient pas journalisées, ce qui nécessitait de longs fsck (BSD seul supporte le fsck en production, et les logs-fs de BSD n'ont pas besoin de fsck).
Faudra que j'en parle à mes BSD ;-) 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. 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 08:56:17 +0200 (CEST),
Marc SCHAEFER <schaefer@alphanet.ch> écrivait :
Toutefois, ext2 et les premières versions d'ext3 n'étaient pas
journalisées, ce qui nécessitait de longs fsck (BSD seul supporte
le fsck en production, et les logs-fs de BSD n'ont pas besoin
de fsck).
Faudra que j'en parle à mes BSD ;-)
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.
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 08:56:17 +0200 (CEST), Marc SCHAEFER écrivait :
Toutefois, ext2 et les premières versions d'ext3 n'étaient pas journalisées, ce qui nécessitait de longs fsck (BSD seul supporte le fsck en production, et les logs-fs de BSD n'ont pas besoin de fsck).
Faudra que j'en parle à mes BSD ;-) 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. 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
zeLittle
Le Fri, 18 Aug 2017 17:03:39 +0200, Pierre www.zetrader.fr <www.zetrader.info> a écrit:
il en est quoi sous Linux ? C'est nécessaire de défragmenter ou pas ?
Il n'y a pas besoin de défragmenter sous Linux, tout simplement par ce 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%.
Le Fri, 18 Aug 2017 17:03:39 +0200, Pierre www.zetrader.fr
<www.zetrader.info> a écrit:
il en est quoi sous Linux ? C'est nécessaire de défragmenter ou pas ?
Il n'y a pas besoin de défragmenter sous Linux, tout simplement par ce
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%.
Le Fri, 18 Aug 2017 17:03:39 +0200, Pierre www.zetrader.fr <www.zetrader.info> a écrit:
il en est quoi sous Linux ? C'est nécessaire de défragmenter ou pas ?
Il n'y a pas besoin de défragmenter sous Linux, tout simplement par ce 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%.
