Btrfs est il stable sur Debian Squeeze ?

Support Debian
#1

Bonjour !

Ayant abandonné Windows, je me suis tourné vers Debian.

Pendant l’installation j’ai eu plusieurs choix de System de fichiers… j’ai hésité entre ext3, ext4 et le tout nouveau btrfs.
D’après plusieurs post que j’ai lu, btrfs est mieux que ext3 et 4; mais j’ai aussi lu plusieurs post (de 2009-2010) comme quoi
btrfs n’es pas stable.

J’en ai aussi lu d’autre comme quoi il est stable avec un linux 2.6.31…

Du coup je sais plus trop quoi faire (actuellement j’ai installé mon system sur btrfs.

J’ai encore 3 disque de 1 To formaté en NTFS que je voudrais mettre en system de fichier propre a linux (btrfs).

Mais vous allez surment me demander pourquoi ne pas avoir mis en ext4 ? Et bien par le passé, j’ai souvent eu des pertes de données. (d’après que c’est parce qu’il garde ce qu’on copie en cache pour les copier définitivement sur le disque “un temps qui peut aller jusqu’a 1 minute” …

Donc… Pouvez vous m’éclairer ? Est ce que btrfs est stable ? (si il est pas stable) est ce qu’il y a de gros risque ? (si oui) Fréquent ?

En espérant que vous m’ayez compris et que vous pourrez m’aider… Merci.

#2

Personne ne connait Btrfs ? :017

#3

Si on connait le système de fichier btrfs mais surement que personne ne répond car personne ne l’utilise en production ou suffisament pour en faire un retour fiable.

En parlant de fiabilité, où as-tu lu qu’il était stable ? quelle source ?

#4

J’ai n’avais pas gardé le lien pour la source. Mais visiblement je me suis trop haté car j’ai du mal comprendre (en même temps moi et l’anglais, ça fait deux ! :laughing: )

En tapant certain mot clé je suis tombé sur ça, ça ressemble a ce que j’avais lu (mais cette fois j’ai traduit avec google) et en effet, ils ne disent pas qu’il est stable…

Source: http://www.h-online.com/open/features/The-Btrfs-file-system-746597.html

Mais bon, ce sujet date de pas mal de temps ! depuis le temps, je pense qu’ils ont fait beaucoup de progrès.

Sinon j’avais vu autre chose (mais qui n’était pas très clair) :

Stable : 23 mars 2009 Instable : 12 juin 2007 (Linux)

Source : http://fr.wikipedia.org/wiki/Btrf (Ecris a droite de la page en dessous de la première zone verte)

J’ai le sur le forum de debian-fr.org que l’administrateur a éssayé btrfs sur une de ces machines, mais je ne sais pas si il l’a gardé ou autre… j’aurais bien aimé avoir son avis sur le sujet.

#5

En toute honnêteté il ne me semble pas si stable que ça, surtout pas sur Squeeze…

scalability.org/?p=2711

[quote]BTRFS is effectively stable (lisez la suite avant d’en tirer des conclusions :smiley:)
Posted on October 29, 2010 by Joe

Yeah, I know, the web page says its under heavy development. And its on disk format can change. And its mailing list is chock full of patches.
[…]
This is a 2.6.36 kernel.
[…]
there are real issues remaining with it. You can use it for storing data and retrieving it. But be aware of the fill issues, the current lack of a repair tool.
[…]
Do I suggest wide spread use? Not until we have those repair tools, and some of the major issues with the fill crash are solved.[/quote]
Même avec un titre d’article comme “BTRFS is effectively stable”, le contenu dudit article est très clair : au niveau du kernel 2.6.36, il reste encore des soucis, l’organisation des données sur le disque peut encore changer, il n’y a pas d’outils de réparation, et il est déconseillé de l’utiliser en production.

#6

Ok. Tu m’a convaincu. Il va falloir que je réinstalle… Heureusement que je suis passer par la :mrgreen:

Bon… Quelqu’un pourrait me dire quoi mettre pour mes partition s’il vous plait ? (quand je travail, je ne peux pas me permettre de perdre des données)

J’avais lu quelque part (je ne sais vraiment plus ou) qu’il existait un moyen de retirer le “temps d’attente avant l’écriture final”
pour ext4. Savez vous comment faire ? et est ce qu’il y a un risque ?

C’est pas grave que ça soit un peu plus lent.

[EDIT]

Je vien de trouver un nouvel article qui me met encore le doute…

Pourquoi si btrfs était pas stable, beaucoup de devlopeur linux le mette par defaut dans leurs distribution ?
http://www.linuxbsdos.com/2011/08/02/install-mandriva-desktop-2011-on-a-btrfs-file-system/

Si ça se trouve c’est juste une histoire de kernel et de mise a jour (mais qu’a ce jour, la version actuel est réelement stable)
Parce que bon, l’article que tu a cité a quand même 1 an…

#7

Je serais curieux de savoir dans quelles conditions tu as perdu des données… Ça fait un sacré moment que j’utilise ext4, et ça ne m’est jamais arrivé malgré de nombreuses coupures de courant intempestives pendant que je bossais.

Sinon concernant le “temps d’attente avant écriture”, c’est l’option de montage commit.
Cela dit, comme indiqué ici mjmwired.net/kernel/Document … s/ext4.txt (*) par défaut ce temps est de 5 secondes (la même chose que pour ext3) donc pas de raison particulière de changer ça. Si vraiment tu n’as pas confiance dans la doc du kernel (!!), tu peux toujours forcer cette valeur à 5 secondes ou moins.

commit=nrsec Ext4 can be told to sync all its data and metadata every 'nrsec' seconds. The default value is 5 seconds. This means that if you lose your power, you will lose as much as the latest 5 seconds of work (your filesystem will not be damaged though, thanks to the journaling). This default value (or any low value) will hurt performance, but it's good for data-safety. Setting it to 0 will have the same effect as leaving it at the default (5 seconds). Setting it to very large values will improve performance.

(*) Ce document est censé être disponible sur kernel.org, mais vu qu’en ce moment leurs serveurs sont coupés, faudra se contenter d’un miroir moins officiel…

#8

Donc si je comprend bien, le “temps qui peut aller jusqu’à 1 minutes” c’était il y a longtemps…

En fait mon “problème de perte de donnée” c’est quand je faisais une copie de fichier d’un disque a un autre et que je supprimais “l’original; donc la source a partir de laquelle j’ai fais la copie” (je faisais souvent ça pour réinstaller linux) et bien une fois linux installé j’avais la grosse surprise que tout ce que j’avais copié, faisait 0Ko. Et je parle de ça il y a 6 mois.

Donc ça serait du a quoi ?

#9

Et cet article parle du kernel 2.6.36, sachant que Squeeze n’en est qu’au 2.6.32. :wink:
D’autre part, la stabilité d’un filesystem ne s’évalue pas sur une année, mais sur bien plus longtemps…

Quand ext4 était encore jeune même si officiellement stable, certaines distributions Linux l’ont proposé comme filesystem par défaut, ce qui a entraîné nombre de problèmes (hein, Ubuntu ? :smiley:), donc je ne crois pas que ça soit vraiment un critère.

#10

J’avoue pour le coup de Ubuntu (quelle galère quand je repense a tout le bug que j’ai eu sur cette distrib :mrgreen: )

ps: oublie pas le message juste au dessus du tien :wink:

#11

[quote=“zyef”]En fait mon “problème de perte de donnée” c’est quand je faisais une copie de fichier d’un disque a un autre et que je supprimais “l’original; donc la source a partir de laquelle j’ai fais la copie” (je faisais souvent ça pour réinstaller linux) et bien une fois linux installé j’avais la grosse surprise que tout ce que j’avais copié, faisait 0Ko. Et je parle de ça il y a 6 mois.

Donc ça serait du a quoi ?[/quote]
J’en ai pas la moindre idée… La seule chose que je puisse dire avec certitude, c’est qu’à moins d’un arrêt intempestif et brutal (un arrêt/reboot propre ne compte pas), ce genre de choses ne devrait jamais arriver, même si tu supprimes l’original et que ton délai de commit est de 10 minutes. À partir du moment où l’OS indique que la copie est finie, seul un défaut d’alimentation ou un plantage complet (kernel panic) peuvent l’empêcher de finir d’écrire les différents cache, même si cette écriture doit prendre encore un moment.
Pour te dire, on ne peut même pas démonter un disque s’il reste des choses en cache à écrire, umount renvoie un message du genre “le périphérique est toujours occupé, réessayez plus tard”.

Bref, il y a certainement un bug caché derrière ton histoire, mais je doute que ça ait à voir avec le délai de commit.

#12

Bon bah je vais mettre mon system en ext4. Je verrais bien ce que ça donne.

Merci pour ton aide/temps que tu ma accordé. :wink:

#13

Salut,

l’ext4 je l’utilise et j’ai pas de souci, par contre brtfs…une personne ici à planter dur il y a quelque temps avec

un indice Son pseudo et écrit en jaune doré :slightly_smiling:

#14

Hello,
pour ma part, j’utilise ext4 sur mes machines depuis plus d’un an et je n’ai pas encore souffert de perte de données.
Cela dit, j’ai récemment rencontré le syndrome de la copie “0Ko”… mais c’était sur une clé USB formatée en FAT !!! Comme quoi :slightly_smiling:

Sinon, je n’ai pas encore testé BtrFS. D’après ce que j’ai lu ces derniers temps, il est notamment qualifié d’instable car il n’est pas encore supporté par fsck.

#15

[quote=“pbollard”]Hello,
pour ma part, j’utilise ext4 sur mes machines depuis plus d’un an et je n’ai pas encore souffert de perte de données.
Cela dit, j’ai récemment rencontré le syndrome de la copie “0Ko”… mais c’était sur une clé USB formatée en FAT !!! Comme quoi :slightly_smiling:

Sinon, je n’ai pas encore testé BtrFS. D’après ce que j’ai lu ces derniers temps, il est notamment qualifié d’instable car il n’est pas encore supporté par fsck.[/quote]

Maintenant que tu me le dis, je commence a me poser la question… j’ai comme le pré-sentiment que c’était sur une de mes clé USB et non le disque dur :unamused:

A tu trouvé une solution a ce propos ?

#16

Et bien entendu, tu ne retires JAMAIS une clé ou un disque USB sans l’avoir démonté proprement auparavant, n’est-ce pas ? :033

#17

En fait… non, je n’ai pas vraiment cherché. Ça s’est produit avec la Fedora 14 du boulot avant l’été. Je ne sais plus si je rencontrais le même souci en branchant la clé sur une de mes Debian :think:

Pour moi, c’est une règle d’or :slightly_smiling: Je démonte toujours avant de débrancher…