Si ton hard foire, ton fsck a tout autant de chance de te faire perdre des données.
Sur que le manque de fsync qui va mettre les infos dans le disque immédiatement plutot que dans le tampon du dd va mettre a genoux ton fsck ....
Qu'est ce qu'il faut pas entendre des fois.
En l'occurence avec un fs copy on write tu ne t'âmuses pas à fscker les fichiers, tu reviens à l'étatn-1 du pool. zfs vérifie les checksums des blocks écrits et te permets de les rechecker à posteriori via la commande scrub (et selon les best practices, tu le fais une fois par semaine), donc en général si ton disque commence à merder :
En l'occurence: avec un fs cow en théorie tu ne t'amuse pas a fscker, en pratique c'est toujours mieux d'avoir ceinture ET bretelle que juste ceinture.
Ensuite si toi tu aimes prendre des risques, c'est ton choix, mais je dirais juste que btrfs, qui est un cow ... et ben ceux qui ont concu le fs (donc je pense qu'ils savent de quoi ils parlent, plus que toi et moi) ... oh ils ont pensé a faire un fsck.
A mais j'avais oublié, vu que pyschofox a dis qu'il fallait surtout pas, c'est que les gens derrière btrfs doivent être des idiots.
Tu mélange entreprise pour qui le MTTR est SUPER important mais qui décide d'utiliser des disques de merde, et qui ne mirrorerait même pas ses disques. J'appelle ça de l'enculage de mouche.
Cas qui est arrivé : sur une baie de disque en raid 6 :
premier disque tombe, le hot spare prend le relais.
Le disques est commandé.
Entre temps (un ou deux jours après) un autre disque tombe.... Et puis a nouveau un troisième.
Au final la baie a tourné un moment sans redondance a cause du délai de livraison des disque (raid 6).
Ben voui, murphy existe, et les délais, et les services des achats ca existe. Si tu es dans une superbe entreprise ou des que tu fais une demande elle est validé dans la minute et tout est toujours sur des contrat en h+4 , nickel chrome, tu as beaucoup de chance.
[^] # Re: Moi
Posté par briaeros007 . En réponse au journal Fini les fsck au boot !. Évalué à 3.
Sur que le manque de fsync qui va mettre les infos dans le disque immédiatement plutot que dans le tampon du dd va mettre a genoux ton fsck ....
Qu'est ce qu'il faut pas entendre des fois.
En l'occurence avec un fs copy on write tu ne t'âmuses pas à fscker les fichiers, tu reviens à l'étatn-1 du pool. zfs vérifie les checksums des blocks écrits et te permets de les rechecker à posteriori via la commande scrub (et selon les best practices, tu le fais une fois par semaine), donc en général si ton disque commence à merder :
En l'occurence: avec un fs cow en théorie tu ne t'amuse pas a fscker, en pratique c'est toujours mieux d'avoir ceinture ET bretelle que juste ceinture.
Ensuite si toi tu aimes prendre des risques, c'est ton choix, mais je dirais juste que btrfs, qui est un cow ... et ben ceux qui ont concu le fs (donc je pense qu'ils savent de quoi ils parlent, plus que toi et moi) ... oh ils ont pensé a faire un fsck.
A mais j'avais oublié, vu que pyschofox a dis qu'il fallait surtout pas, c'est que les gens derrière btrfs doivent être des idiots.
zsh 4 [1] % fsck.btrfs
usage: btrfsck dev
Btrfs Btrfs v0.19
Tu mélange entreprise pour qui le MTTR est SUPER important mais qui décide d'utiliser des disques de merde, et qui ne mirrorerait même pas ses disques. J'appelle ça de l'enculage de mouche.
Cas qui est arrivé : sur une baie de disque en raid 6 :
premier disque tombe, le hot spare prend le relais.
Le disques est commandé.
Entre temps (un ou deux jours après) un autre disque tombe.... Et puis a nouveau un troisième.
Au final la baie a tourné un moment sans redondance a cause du délai de livraison des disque (raid 6).
Ben voui, murphy existe, et les délais, et les services des achats ca existe. Si tu es dans une superbe entreprise ou des que tu fais une demande elle est validé dans la minute et tout est toujours sur des contrat en h+4 , nickel chrome, tu as beaucoup de chance.