C’est franchement intéressant ta remontée de test.
Et, je t’avoue que c’est ce que je suspecte depuis le début.
N’ayant pas de disque de cette taille, je ne peux tester !
Je plussoie le propos de @clochette du fait d’avoir de vieilles versions de Linux, qui ne peuvent pas monter normalement même du type 44bsd, et ce quand bien même c’est indiqué supporté par le manpage. (Vichu vieux rescuecd, pfff…) 
Salut,
Oui, c’est un peu curieux que le support soit clairement indiqué comme présent dans le man, et qu’il ne fonctionne pas. Cela dit, je n’ai pas eu tant de problèmes que ça : si j’ai à chaque nouveau type de fs j’ai galéré pour trouver comment faire, j’ai jusque là toujours réussi à lire les disques *BSD jusqu’à 1To. Voilà l’historique des premières tentatives pour chaque type de fs que j’ai pu reconstituer :
Février 2010, probablement sur un Linux Mint de l’époque, montage du disque 250Go de mon FreeNAS. fs : 5xbsd
Mars 2010, probablement toujours sur la même Mint, montage d’un disque 10Go de mon FreeNAS. fs : ufs2, lecture seule.
Février 2018, probablement sur Debian Jessie, montage d’un disque 250Go OpenBSD. fs=44bsd, lecture seule
Je réalise en refaisant ce petit historique que mon premier disque était 5xbsd et le second ufs2, donc même fs d’après le man. Pourtant, j’avais noté pour le premier que 5xbsd n’était pas mentionné dans le man, et donc j’avais bien dû tenter ufs2… Les deux disques n’étaient pas formatés exactement de la même manière : la partition du premier était de type GPT et celles du second de type FreeBSD. Mais, je répète, à part un peu de galère pour trouver le bon type, ça fonctionnait sans problème.
Pour ce disque 2To, je n’ai rien su trouver sur le net qui en parle, alors que, même si j’avais eu un peu de mal pour les autres disques, j’avais toujours fini par trouver (mais bon, j’ai la nette impression que les moteurs de recherche fonctionnaient beaucoup mieux en 2010 que maintenant, avec leur manie de vouloir nous indiquer d’abord ce qui sert leur pub ciblée 
)
Et donc mon expérience en matière de 44bsd est relativement récente, mais hormis ce disque 2To (qui, d’après solène dans un post sur OBSD4, serait en ufs2), je n’ai jamais eu de problème de montage (sauf le read only obligatoire et non mentionné dans le man). Je ne sais plus si j’ai aussi tenté une fois ou l’autre avec SystemRescueCD, mais mon CD est si ancien que si ça n’a pas fonctionné, ça ne m’a pas surpris.
Voilà donc pour ce complément de REX. Donc, en ce qui me concerne, il n’y a que ce problème avec disques de 2To, dont la limite devrait au moins être mentionnée dans le man si elle est incontournable, à moins que ce soit un bug (mais c’est vrai que 2To, c’est gros !)
Juste pour info, j’ai trouvé ça sur page NetBSD :
Write support
Write support is available given several conditions are satisfied: - ufs write support option compiled in Linux kernel (
CONFIG_UFS_FS_WRITE=y): it is disabled by default. - FFSv1 filesystem (FFSv2 not yet supported)Please note that as I do not really need write support on NetBSD partitions from GNU/Linux, I did not bother to rebuild my Linux kernel and hence have not tested this feature.
Non, là tu confonds la table de partition avec un format de système de fichier.
À moins que je ne me trompe, mais à ma connaissance, je n’en connais que deux relativement aux architectures PC et assimilées (i386, amd64,…) : MBR et GPT.
Quant aux formats de système de fichiers, il en existe des dizaines qui sont “physiques” et d’autres qui sont “virtuels”
Comme le montre @clochette, étant donné que tu es le seul dans le coin à avoir de si grosses capacités, et à utiliser aussi OpenBSD, tentes donc la recompilation d’un noyau Linux, en veillant à ce que lesdites options nécessaires soient activées… (qu’elles soient en module, ou pas, c’est un faux problème… tu seras faire pour les monter si tu choisis en option).
Sans doute l’histoire des disks labels (dans mes souvenirs) :
Mais à mon avis le support doit-être surement ajouté par compilation pour ce type faut le dire exotique; comme précisé dans ma citation …
Salut,
@Clochette (write support)
Oui, j’ai aussi vu passer cette info quelque part. C’est probablement la raison pour laquelle le man signale plusieurs fs comme n’étant supportés qu’en lecture seule, et rien pour d’autres (44bsd, sun*). Pour ces derniers, ça doit effectivement dépendre de cette option de compilation.
Bon, peut-être que ma terminologie est imprécise, voire inexacte. Mais voilà ce que me donnait fdisk -l dans les deux cas :
/dev/sdc1 1 30283 244198583+ ee GPT
/dev/sdc1 * 1 65 32728+ a5 FreeBSD
/dev/sdc2 66 20928 10514920+ a5 FreeBSD
Je veux bien faire profiter la communauté de mes expériences sur disque de 2To, mais disposant de peu de temps, je voudrais être bien sûr que ce soit utile. Or, ce dont parle Clochette est une option pour autoriser l’écriture et tout semble clair de ce côté là. Elle ne parle pas de grosses capacités, et comme je le disais je n’ai absolument rien trouvé sur le sujet… donc, ça voudrait dire aussi rechercher si une option non documentée est à activer explicitement pour obtenir ce support.
Pour moi, soit cette option n’existe pas, et le support ufs-v2 est limité sous Linux aux disques <2To, soit je n’ai pas été assez malin pour trouver l’info concernant cette option. Peut-être suis-je passé 50 fois devant sans la voir, mais le fait est que j’ai pas mal cherché et rien trouvé…
Heu, non. J’ai 2 disques de 3 To chez moi, ce n’est plus exceptionnel.
A mon avis c’est cette option: il doit y avoir un truc à faire, mais quoi ?
Sinon il doit y avoir moyen de monter le disque dans une VM BSD et le partager avec l’hote, ce qui te donnerait toutes les fonctionnalités de lecture/ecriture que tu veux.
Mais ça ne résoudra pas le problème linux.
Salut,
Non, pas exceptionnel effectivement : les disques de haute capacité sont relativement courants maintenant, mais ce qui l’est moins c’est les utilisateurs d’OpenBSD, et encore moins donc ceux qui ont un disque de haute capacité en ufs-v2 ! D’où la demande de PengouinPdt et mon obstination bornée à trouver une solution Linux.
Effectivement, les moyens de récupérer mes données sont multiples et, vu les difficultés de trouver une solution ou au moins une explication du problème sous Linux, beaucoup plus rapides. Mais comme je n’ai pas (encore) un besoin urgent de récupérer ces données, que je suis un peu curieux et que ça pourrait servir à d’autres (OpenBSD est quand même un peu différent de Linux, et un habitué de Linux n’installera pas très facilement un OpenBSD si c’est la première fois qu’il le fait et pourrait préférer ne pas se lancer dans cette aventure !), je reste un peu en attente/recherche de solution sous Linux ou au moins d’une confirmation que les disques haute capacité ne sont pas gérés pour le moment.
Oui, ces capacités deviennent courantes ; mais je persiste à dire que le fait de posséder de telles capacités ne sont pas courantes, ne serait-ce que par le prix ; d’autant si tu prends des gammes sérieuses.
Bref, ce n’est pas le sujet… désolé pour la digression.
Comme je l’ai dit plus haut, ce que je suspecte est que le noyau Linux ne gère pas est la taille des “fragments” (pfff, je ne sais plus comment on dit en FR) !
gression
ok, je =>
Unité d’allocation ? Le français est souvent beaucoup plus verbeux que l’anglais, alors on va souvent au plus rapide
Oui, je pense que le problème est là : 4096 semble passer sans problème, mais pas 8192… Mais bon, là je ne vais guère pouvoir aller plus loin : il faudrait faire l’essai avec des disques intermédiaires entre 1To et 2To, et voir si on bute bien au passage de “fragments” de 4096 à 8192… En tous cas, je n’ai jamais eu ce problème avec des disques de 1To et moins, tous ayant des “fragments” de 4096…
À moins d’essayer de forcer la fragmentation à 8192 sur un disque de 1To ? C’est possible ? Ça peut valoir le coup ?
Oui, et puis il y a aussi un problème de sécurité : lorsqu’un disque de plusieurs To casse, ça fait un paquet de données perdues ! Bon, facilement récupérables si on a de bonnes sauvegardes, mais c’est quand même plus problématique, ne serait-ce que par le temps de restauration ! Donc, on a tendance à n’utiliser de gros disques que pour des données qui bougent très peu et qu’on peut se permettre d’avoir indisponibles pendant un certain temps. Ou alors, il faut faire du raid, mais ce n’est pas non plus la panacée, et du raid avec des disques de plusieurs To, bonjour le prix !
Pour la data “en masse” j’ai un backup/clone sur usb amovible (d’où les 2*3To), ce qui permet de basculer sur le backup le temps de remonter un original en cas de besoin.
C’est pas parfait, il y a une période ou je tourne juste sur le backup en cas de casse ce qui est un risque, mais c’est suffisant pour mes besoins.
< en mode passage rapide, voyant la cata se profiler à l’horizon >
Tu veux dire que l’anglais est plus direct et moins verbeux ?
C’est possible puisque le système t’explique qu’il ne faut surtout pas faire des choses que le système te dit de ne pas faire, sinon la conséquence est connue à l’avance, le pifométrage étant rarement la bonne option.
mount: mauvais type de système de fichiers, option erronée, superbloc erroné sur /dev/sdc4, page de code ou programme auxiliaire manquant, ou autre erreur
WARNING<<< Wrong ufstype may corrupt your filesystem
ufs: ufs_fill_super(): bad magic number
ufs: ufs_fill_super(): bad magic number
ufs: ufs_fill_super(): fragment size 8192 is too large
ufs: ufs_fill_super(): fragment size 8192 is too large
error (device sdc4): ufs_check_page: bad entry in directory #2: rec_len is too small for name_len - offset=0, rec_len=12, name_len=260
ufs: ufs_fill_super(): bad magic number
ufs: ufs_fill_super(): fragment size 8192 is too large
Inutile de t’obstiner à vouloir “monter” une partition dont le filesystem est probalement (pour ne pas dire sûrement) corrompu suite à tes différents essais aléatoires.
La première chose à faire est de vérifier l’intégrité du filesystem avec les outils openBSD correspondants.
Si un filesystem est corrompu, la première chose à faire est de le réparer, ce que ‘mount’ ne sait absolument pas faire puisque ce n’est pas sa fonction.
Ah mais c’est bon, tu va arrêter de déballer ton mépris, @verner, c’est vraiment PENIBLE.
@jibe-74 est surement aussi compètent que toi voire plus et il sait ce qu’il fait, et c’est le cas d’une bonne part des intervenants, c’est vraiment lourd que tu commences tous tes messages par “vous faites n’importe quoi, attendez, j’ai la réponse”, avant de pontifier en disant en plus deux fois sur trois n’importe quoi qui n’a rien à voir avec le sujet.
Je te promet, c’est lourd de chez lourd.
C’est vrai que je vois mal le rapport entre ma réflexion sur la verbosité, qui concernait la traduction de “fragment” évoquée par @PengouinPdt, et le montage de ce disque 2To…
Cela dit, effectivement, il faut éviter de s’obstiner quand le système prévient qu’il y a des risques. Mais, dans le cas présent :
La dernière fois que j’ai monté ce disque sur OpenBSD, après plusieurs essais infructueux sous Linux aboutissant à ces “bad magic number”, je l’ai vérifié et il était parfaitement correct (et, à fortiori, lisible), me confortant dans l’idée que le problème était un FS pas ou mal reconnu par Debian et non un FS cassé
Je vois mal comment un disque monté systématiquement et explicitement en lecture seule pourrait être corrompu, puisqu’on interdit au système d’écrire dessus. S’il y a quelque chose que j’ignore et qui le permet, ce serait sympa de me l’indiquer ou de me renvoyer à la doc qui l’explique.
Je doute que ni @mattotop, ni @Clochette, ni @PengouinPdt n’aient évoqué cette possibilité si c’en était réellement une.
Merci quand même pour l’info et pour te rassurer, @verner, j’ai cessé de faire des essais “pifométriques” et “aléatoires” à partir du moment où j’ai eu la quasi certitude qu’il s’agissait d’une taille de “fragment” non supportée par Debian, et que si j’en fais d’autres comme demandé par @PengouinPdt, ce sera après avoir récupéré mes données sous OpenBSD, donc sur un(des) disque(s) sur le(s)quel(s) je pourrai prendre le risque de “casser” le FS sans conséquences.
@jibe-74 : je te rassure, comme tu l’as compris, ton FS n’est pas KC !
D’autant si tu le plug sur du OpenBSD, et qu’il te restitue le fameux message “clean”.
Tu connais aussi bien que moi la commande fsck_ffs au besoin, dont tu ne devrais pas avoir besoin parce que ton FS n’est pas cassé.
Rien à voir, avec le fait que le noyau Linux ne gère pas correctement ton FS ufs2 !
Et, non, tu ne vas pas cassé si facilement ton FS, et bien heureusement.
@Verner: MERCI DE N’INTERVENIR qu’en connaissance de cause ! Tout le monde appréciera !!!
Parfait ! Merci de cette précision qui me semble-t-il, si elle n’avait pas été faite par toi 4 jours plus tôt, aurait du être précisée avant de te demander de faire des choses que le système disait explicitement de ne pas faire.
On pouvait toujours “supposer” que tu as pris toutes les précautions pour sauver tes données, “supposer” que tu as vérifié l’intégrité du filesystem, “supposer” que tu n’oublieras jamais de faire un “rô” en montant la partition et “supposer” plein de choses.
Je ne supposais justement rien, je voulais “m’assurer que”, dans ton intérêt, considérant qu’au moins une précaution vaut mieux que zéro précaution.
Ceci étant dit, quelques remarques pour poursuivre les investigations.
La commande ‘mount’ de linux n’a besoin d’aucune option pour reconnaître une partition ext2/3/4 ou fat32, puisque ‘mount’ saura autodétecter les bons paramètres par défaut. Il suffit de lui donner un point de montage, si pas déjà identifié dans le fstab.
Dans ton cas, le bloc /dev/sdc4 est bien vu, c’est déjà un bon début…
Où ça se complique, c’est si sans préciser d’options, ‘mount’ ne sait pas où se trouve la table de partition, ne connait pas le nombre de blocs par secteurs s’il s’agit d’un disque dur, ou ne comprend pas la structure, et ne trouve pas non plus sur quel secteur commence la première partition.
Dans ce cas, il va falloir tout lui dire, et ça va être à toi d’aller chercher ces paramètres dans le filesystem et/ou table de partition, puisque tu es sûr qu’il n’y a aucune erreur à ce bas niveau.
As-tu regardé avec fdisk ou parted ou ‘tune2fs -l’ si tu pouvais extraire quelques infos utiles ?
Il est probable que ‘mount’ soit très gourmand en demande d’info, jusqu’à devoir renseigner l’option ‘offset’ pour qu’il comprenne où commence exactement la partie utile de la partition.
Le module ufs est-il chargé ?
lsmod | grep ufs
Voilà juste des pistes de réflexion, en m’excusant de ce “Red Flag” incompris par certains, pour protéger tes données dans ton intérêt, préférant les faits aux hypothèses et approximations.
Maintenant que les précautions sont prises, tout est permis, même si le système dit qu’il refuse ou prévient du danger.
Bon courage, conscient que le sujet n’est pas simple, et que de la méthologie stricte doit s’imposer dans ce cas précis (comme souvent d’ailleurs… / j’aurais dit comme toujours, mais ça va en irriter certains que ça ferait bouillir, on se contentera donc d’un “souvent” et non pas d’un sous-vent.)
Plus qu’à espérer que des spécialistes openBSD visitent un forum Debian en français, mais c’est pas gagné.
I leave the floor.
Good luck man.
Merci de tes propos rassurants, mais @Verner n’avait pas réussi à me provoquer un infarctus Si je fais des essais en écriture, il y a bien quelques risques. Qu’ils soient grands ou petits importe peu : c’est la règle élémentaire de prudence et je ne ferai ce genre d’essais qu’après avoir récupéré mes données (que j’ai ailleurs, mais pas forcément tout à fait à jour). Par contre, tant que je reste en lecture seule, je sais bien que le seul risque que je prends est de laisser tomber mon disque en le manipulant. D’après mon expérience, c’est fatal quand on n’a aucune sauvegarde, mais si on a mis de côté une bonne partie de ses données, le disque arrive à supporter sans dommage les quelques G d’une petite chute !
Après, assez nouveau sur ce forum, je ne connais pas @Verner qui me semble ici effectivement un peu alarmiste et bien trop peu confiant dans votre capacité, à toi et aux autres intervenants, de me prévenir si vous avez le moindre doute sur le fait que j’aurais pu oublier une de ces règles élémentaires de prudence. Après, il me semble dire (aussi) des choses sensées et je lui accorde le bénéfice du doute en admettant que son intention était bien de me prévenir et non d’être arrogant. L’avenir me dira si j’ai raison ou pas !
Je crois bien l’avoir fait (et même mentionné !), mais comme de toutes manières j’arrive à monter des disques ufs v1 et ufs v2 de plus faible capacité, lsmod ne peut que confirmer que le support est bien là !
Pour reprendre et résumer l’histoire certes un peu disséminée dans plusieurs posts (j’aurais tout à fait compris un “désolé si ça a déjà été dit, je n’ai pas eu le temps de tout lire, mais…” ), je me suis basé sur les dires de gens qui connaissent parfaitement OpenBSD et qui m’ont informé que les disques de 2To sont formatés en ufs v2. Comme je monte sans difficultés d’autres disques formatés exactement de la même manière en utilisant ufs v1 (44bsd) et que tous donnent exactement les mêmes infos avec fdisk (aux secteurs de début/fin et nombre de blocs près, bien sûr !), j’ai donc essayé les deux versions d’ufs. Voici le résultat de fdisk pour un disque exemple formaté sur OpenBSD :
/dev/sdc4 * 64 488392064 488392001 232,9G a6 OpenBSD
Je répète, c’est pareil pour tous, de 250 Go à 2To, aux données de secteurs et de blocs près bien sûr.
Je sais par ailleurs que les blocs sont de 4096 pour les disques <2To et 8192 ensuite.
Donc, pas essayé de voir avec tune2fs, c’est peut-être effectivement à essayer. Ce qui me semble plus probable quant à l’obtention d’un résultat positif est de tenter d’ajouter l’option bloc=8192 à la commande mount. Effectivement, j’aurais dû penser aux options additionnelles, merci de me le rappeler. Je n’ai plus le disque sous la main, mais je testerai ASAP.
Je reste quand même un peu sceptique quant au succès de l’ajout d’options, compte tenu du fait qu’ufs v1 et ufs v2 soient reconnus sans aucun problème, quelque soit la provenance des disques et le type de partition, tant qu’on est en-dessous de 2To, et qu’au-delà elles deviennent indispensables. Je crois plus à un support incomplet ou mal débuggé à cause de la rareté des disques de grande capacité, soulignée par @PengouinPdt. Mais bon, ça, seuls d’autres tests nous l’apprendront.
Non, car ça ne concerne que l’ext, comme toutes les commandes en “e2fs” ( dumpe2fs, e2fsck,…)
Rien à voir avec ufs.
Salut,
Oui, effectivement ! Bon, je m’en serais aperçu bien vite en l’essayant sur ufs, mais merci pour l’info. C’est vrai qu’habitué à Linux et ext* et très peu à OpenBSD et ufs, ça ne m’est pas venu à l’esprit qu’il pouvait y avoir cette spécialisation.
Bon, je suis un peu pris jusqu’à Samedi, voire Samedi après-midi, et là je récupérerai mon disque (monté sur une bécane OpenBSD pour récupérer mes données) et testerai un mount avec bloc=8192. Même si j’y crois à moitié (encore moins après ce coup du tune2fs !), c’est bien vite essayé et si ça peut lever le mystère, c’est toujours intéressant !