Il n'y a pas de "doublon" :
forcefsck / était une commande à usage unique et ne s'appliquant qu'à la racine ;
tune2fs permet un réglage permanent et différencié selon les partitions.
- -
arnoxz a écritComment remettre les valeur par défaut
sudo tune2fs /dev/disk/by-id/ata-WDC_WDS500G2B0B_2013EM471901-part2 -c 0 -i 0
- -
est-elle utile pour un ssd ? (j'ai lu que forcefsck n'avait plus raison d'être pour les nouvelles versions/ssd, il me semble),
Source ? Arguments ?
- -
cela va t'il résoudre le soucis de la session "guest/invité" ?
J'en doute (cf. #4).
Cependant :
1) : Toi-même as obtenu, faute de fsck :
d????????? ? ? ? ? ? gvfs
ce qui illustre bien le
risque ;
2) Anciennement,
man tune2fs [ de 14.04 ?] disait :
Il est vivement recommandé d'activer soit -c (limite en nombre
de montages) soit -i (limite en temps) pour que e2fsck(8) véri‐
fie régulièrement et complètement le système de fichiers. Dans
le cas contraire vous risquez d'aboutir à des corruptions silen‐
cieuses du système de fichiers en cas de défauts dans les
disques, câbles, mémoires ou dans la conception du noyau et vous
ne vous en apercevrez que lorsqu'il sera trop tard, après la
perte des données.
Ce qui reste vrai.
Dans 18.04 et dans 20.04, c'est devenu :
Mount-count-dependent checking is disabled by default to avoid unanticipated long
reboots while e2fsck does its work. However, you may wish to consider the
consequences of disabling mount-count-dependent checking entirely. Bad disk
drives, cables, memory, and kernel bugs could all corrupt a filesystem without
marking the filesystem dirty or in error. If you are using journaling on your
filesystem, your filesystem will never be marked dirty, so it will not normally be
checked. A filesystem error detected by the kernel will still force an fsck on the
next reboot, but it may already be too late to prevent data loss at that point.
Mais en fait, si, le système détecte parfois le besoin impératif d'un fsck... Et n'est plus capable de le traiter !
À preuve, tu trouveras de nombreuses demandes d'aide disant en substance
mon système ne démarre plus et m'affiche
run fsck manually
Du coup, il faut :
- démarrer en live,
- identifier la partition à traiter
- et lancer à la main
sudo fsck -yfv /dev/(partition)
pour obtenir ce qui se faisait automatiquement et
sans redémarrage en live jusqu'en février 2011.
- -
pourquoi n'est elle pas incluse par défaut par le système
C'est la question de fond !
Quand j'ai découvert cette
aberration, j(ai ouvert un fil :
./viewtopic.php?id=1989648 dans lequel maxire et tamarou m'ont signalé
la source https://patchwork.ozlabs.org/project/linux-ext4/patch/4D5D9943.70901@redhat.com/ de février 2011.
En gros, elle affirmait que la vérification (à l'époque plus lente, sur de l'ext3)
a) prenait trop de temps ;
b) survenait à des moments "inopportuns" pour une entreprise commerciale.
Je ne m'explique pas que depuis neuf ans et demi, aucun développeur ne soit revenu sur un choix aussi con
tre-productif.
- -
En résumé, le choix est - selon moi - entre
- risquer des pertes de données ;
- et investir quelques dizaines de secondes tous les x (dix ou autre choix) jours.
- -
Après, tu gères librement un S.E. libre, donc tu feras comme tu veux.
