Une info croustillante passée inaperçue (sauf dans ce journal), est que RHEL7, la prochaine version du célèbre système d'exploitation de Red Hat, pourrait bien utiliser XFS comme système de fichiers par défaut pour le root et l'espace utilisateur, et non ext4. Btrfs est également suivi avec attention et devrait être proposé en option. Denise Dumas, directeur du secteur "Software Engineering" de Red Hat, affirme que cela correspond plus aux besoins des clients, sans apporter plus de précisions.
Personnellement je trouve cela surprenant, l'écrasante majorité des distributions Linux utilisent ext4 par défaut. D'ailleurs bien que XFS soit encore maintenu et patché pour apporter des évolutions, je l'ai toujours vu comme "l'avant ext4". La majorité des benchmark placent ext4 gagnant quelque soit le cas d'usage, alors que la légende raconte que XFS est meilleur pour gérer de très nombreux petits fichiers. De plus, ce dernier ne supporte pas le TRIM pour les SSD.
Bon j'ai fait quelques recherches sur le web, et certains sysadmin préfèrent xfs à ext4 pour les raisons suivantes :
- ext4 ne gère pas les fichiers plus gros que 16TB
- ext4 pose des problèmes de cohérence des données en raison de son cache
- certains citent des méchants bugs sur des espaces de stockage de plusieurs dizaines de TB
On pourra rétorquer que XFS a été patché il y a peu de temps pour implémenter un cache afin d'améliorer ses performances, et que l'on trouve également des retours de sysadmin qui ont perdu des plumes suite à des crashs du système.
Étant donné que le fs idéal n'existe pas, on peut se poser la question de savoir si Red Hat a pris une décision technique ou politique…
# je confirme
Posté par NeoX . Évalué à 2.
je me suis fais tres peur avec un NAS utilisant XFS dans des volumes LVM
pour une raison indeterminée, le NAS plante au demarrage avec l'OS du contructeur,
impossible de reinstaller, enfin si, mais en sortant les disques du raid
si y a les disques, l'OS ne boote pas et se vautre lamentablement sur la detection des volumes.
XFS de 2.5To et XFS de 7.5To
pourtant un linux livecd recent fonctionne parfaitement, et me permet d'acceder aux memes volumes.
[^] # Re: je confirme
Posté par MTux . Évalué à 10.
Pour le coup, pas sûr que tes ennuis soient dus à XFS :/ Ce serait plutôt le firmware constructeur du NAS.
[^] # Re: je confirme
Posté par NeoX . Évalué à 3.
scan des partitions avec un liveUSB, correction des erreurs,
reinstallation du firmware (linux) du constructeur
toujours le meme bug, et uniquement sur un des volumes.
j'ai pensé un instant à un probleme hardware vu que la machine date de 2005
mais comme ca marche nickel depuis un liveUSB
bah j'ai installé le linux du liveUSB à la place du firmware du constructeur.
[^] # Re: je confirme
Posté par Anonyme . Évalué à 5.
sinon ma vie :
chez moi XFS a toujours mal supporté les coupures de tension, mais etonnament avec les outils de recuperation XFS j'ai toujours reussi a recuperer et rendre la partition cohérente
mon resumé : plein d'emmerde, et toujours possible de tous recuperer assez facilement.
Pour ext4 lorsque j'ai des souci de dessus j'allume un cierge en me disant que j'aurais du mettre XFS.
ce n'est représentatif que de mon expérience personnelle
[^] # Re: je confirme
Posté par SauronDeMordor (site web personnel) . Évalué à 1.
j ai rencontré ce bug la avec grub en fait
le calcul de la taille de partition est buggé et si je me souvient bien en regardant les source on était a 2To et qq chose (pas 2048 Go) et cela faisant un message d erreur du genre grub error disque size to small
et donc tous les 2.X To (modulo) disksize = 0 => grub error
# Hein ?
Posté par Arthur Accroc . Évalué à 8.
Hein ?
J’étais très dubitatif là-dessus, faute d’avoir vu passer une annonce majeure concernant XFS.
À l’époque de la CentOS 5, j’ai monté un serveur de sauvegarde avec rsnapshot, pour plusieurs serveurs, dont un de fichiers, en tout entre 1 et 2 To de données sur quelques millions de fichiers (les systèmes comme les répertoires utilisateurs contenant beaucoup de petits fichiers).
Premier essai, XFS (censé être efficace sur de gros volumes et supporté officiellement dès le début de la RHEL 5, ce qui met plutôt en confiance).
Plusieurs jours pour faire une sauvegarde, y compris incrémentale. En fait, rien que la suppression de la sauvegarde périmée prenait des heures !
Deuxième essai, retour au classique Ext3.
Suppression de la sauvegarde périmée en moins de 20 minutes, sauvegarde incrémentale des serveurs en deux à trois heures (et pas des jours).
Là, j’ai tenté de faire une vérification du système de fichiers… et j’ai compris pourquoi RedHat la désactive complètement par défaut (mais pour ma part, je n’ai pas une telle confiance). La vérification s’est mise à consommer une quantité de plus en plus importante de mémoire, jusqu’à taper de plus en plus dans le swap au point de ne plus avancer. Le lendemain, je n’avais plus d’espoir qu’elle puisse aller au bout et je l’ai arrêtée.
Ext4 m’a sauvé ! Les mêmes performances en sauvegarde qu’ext3 et la vérification du système de fichiers en une vingtaine de minutes.
Cela dit, je viens de faire le test qui tuait XFS (création puis suppression d’un million de fichiers vides) sur un système récent et XFS semble maintenant s’en sortir à peu près aussi bien qu’Ext4.
Après, il faut voir en conditions réelles.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Hein ?
Posté par MTux . Évalué à 6.
Pour avoir testé une fois xfs je suis plutôt d'accord avec toi. Sans dire que les performances étaient mauvaises, elles étaient en tous cas bien inférieures à ext4. Mon test c'était le répertoire /var sur une archlinux, afin de tenter d'optimiser le cache de pacman. La réactivité de l'outil était de loin meilleure avec une partition ext4.
# Pourquoi tant de haine ?
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
XFS a toujours un système de fichier développé en parallèle des autres, il suffit de regarder le changelog du développement du noyau. Je dirais que face à l'évolution des EXT, c'est le seul qui a une évolution et un développement suivis au cours du temps (jamais eu confiance en JFS et autres…). Le système continue a être développé. A priori, le TRIM fonctionne dessus même si mes volumes ne l'utilisent pas personnellement.
http://xfs.org/index.php/FITRIM/discard
Pour moi, XFS permet de fixer des quotas par défaut sur les utilisateurs et aucun autre système de fichier ne le permet à ma connaissance (il y a même la notion de quota par projet). De plus, j'ai des volumes de plus de 20To très robuste malgré les pannes électriques récurrentes… Il a un inconvénient majeur pour moi, on ne peux pas rétrécir les partitions, ni à chaud, ni à froid.
[^] # Re: Pourquoi tant de haine ?
Posté par mornik . Évalué à 2.
Pendant longtemps, la préco de MySql était d'avoir ses fichiers de base sur une partition xfs.
[^] # Re: Pourquoi tant de haine ?
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
C'est aussi la préco de ceph.
# ZFS
Posté par David Demelier (site web personnel) . Évalué à 6.
Bien sûr que le FS idéal existe, il s'appelle ZFS.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: ZFS
Posté par WhiteCat . Évalué à 5.
Si c'était vraiment le fs idéal il fonctionnerait sur Linux ;-)
[^] # Re: ZFS
Posté par Psychofox (Mastodon) . Évalué à 5.
En l'occurence c'est le cas.
[^] # Re: ZFS
Posté par WhiteCat . Évalué à 1.
OK certes mais je me risquerais pas personnellement d'utiliser en prod un fs via fuse. Je préfèrerais encore utiliser btrfs malgré son non-support officiel dans RHEL.
[^] # Re: ZFS
Posté par Prosper . Évalué à 7.
Pas besoin de fuse avec http://zfsonlinux.org/
[^] # Re: ZFS
Posté par WhiteCat . Évalué à 1.
C'est intégré dans quelle distribution ?
[^] # Re: ZFS
Posté par MTux . Évalué à 4.
ZFS est trop gourmand et complètement surdimensionné pour une utilisation desktop. C'est uniquement conçu pour du stockage de données critiques en datacenter. Donc non ce n'est pas le système de fichiers idéal. J'aurais tendance à dire que le fs idéal du moment c'est ext4 sur Linux, et NTFS sur Windows.
[^] # Re: ZFS
Posté par xcomcmdr . Évalué à 4.
Y'a pas grand chose à part NTFS sur Windows, qui date essentiellement de 1994 (bon allez, on va dire qu'il date de 2001 depuis NTFS 3.1).
Windows 8 introduit à moitié ReFS, mais c'est une couche par dessus NTFS donc c'est pas très excitant…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: ZFS
Posté par MTux . Évalué à 6.
C'est pas tout à fait vrai. NTFS a été amélioré entre temps, et il est franchement pas mal. Redimensionnement à chaud, chiffrement, défragmentation à chaud, et les performances sont très correctes. C'est pas comparable à du FAT32 qui lui est vraiment dépassé depuis une bonne décennie, mais encore utilisé par défaut ou fainéantise.
[^] # Re: ZFS
Posté par claudex . Évalué à 8.
C'est aussi le seul système de fichier qui marche par défaut sans droit sur Windows, Mac et Linux. Ce qui est très intéressant sur tout support amovible. UDF pose des problèmes sur certaines versions de Windows ou Mac OS X.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ZFS
Posté par zebra3 . Évalué à 2.
Je ne sais pas ce qu'il en est des Mac, mais NTFS fonctionne parfaitement sous Linux, y compris pour communiquer avec Windows.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ZFS
Posté par claudex . Évalué à 4.
On n'a pas la même notion de parfaitement. Aux dernières nouvelles, les droits ne sont pas du tout gérer entre Linux et Windows (du coup, ça marche pour transférer les fichiers de Linux à Windows mais ça peut faire des surprises entre Windows et Windows).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ZFS
Posté par zebra3 . Évalué à 3. Dernière modification le 14 décembre 2013 à 14:55.
Ben plus haut tu as écrit :
Je te cite NTFS, et tu me dis que non à cause des droits. Faudrait savoir :-)
Bref je maintiens que NTFS est aussi fiable de FAT32 entre Linux et Windows voire même plus, je m'en sers très régulièrement. Je ne sais pas ce qu'il en est des Mac, je n'ai pas la possibilité de tester.
Et je t'avouerais que je ne vois pas bien l'intérêt des droits sur des clefs USB :-/
Je ne dis pas qu'il n'y en a pas, mais dans la majorité des cas ça me paraît inutile ou pire contraignant (une clef en Ext4 c'est juste chiant si tu ne fais pas gaffe aux UID).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ZFS
Posté par claudex . Évalué à 2.
Justement, je dit que NTFS est un problème entre Windows et Windows, pas entre Windows et Linux.
Par défaut, il n'écrit pas sur NTFS (du moins, les version d'il y a quelques années, je n'ai pas testé sur la dernière)
C'est justement pour ça que FAT est intéressant, parce qu'il n'y a pas de droit. C'est pour cela qu'UDF serait intéressant s'il était vraiment prix en charge. C'est pour ça que MS arrive à introduire exFAT.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ZFS
Posté par zebra3 . Évalué à 2. Dernière modification le 14 décembre 2013 à 17:51.
OK je n'avais pas bien compris. Je suis assez surpris car je n'ai jamais rencontré aucun problème de droits avec mes clefs USB en NTFS, et je n'en avais jamais entendu parler.
En fait, j'ai l'impression que la notion de droits est très différente entre les deux, il semble que que NTFS n'utilise que des ACL et ça lui permet d'être beaucoup plus souple avec un FS par défaut (tout est inscriptible par tout le monde).
D'un autre côté, si ça ne marche pas simplement avec Ext4 j'ai justement dû contourner le problème en ajoutant des ACL similaires : rwx pour le groupe users (ce qui n'est pas forcément l'idéal d'ailleurs puisque le gid n'est pas le même entre Debian et Fedora, par exemple). Reste que ça n'est pas forcément une manipulation triviale.
En l'état actuel, la seule solution que j'ai constatée fonctionnelle partout de manière simple et dans tous les sens (de Linux à Windows, de Windows à Linux, de Linux à Linux et de Windows à Windows), c'est NTFS.
Les problèmes que tu cites existent sans doute mais me semblent très théoriques ou
doivent être liés à des conditions très particulières. Est-ce que tu les as rencontrés personnellement ? De toute façon j'attends de tomber dessus en vrai avant de repasser à FAT32 ce qui serait un comble :-)
exFat, je ne sais pas s'il est utilisable sous Linux mais passer d'une techno Microsoft à une autre, je suis assez dubitatif. Je préfère encore rester à ce qui fonctionne.
Par ailleurs, il semble qu'Android ne le prenne pas systématiquement en charge, alors que NTFS si.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ZFS
Posté par zebra3 . Évalué à 2.
Rectification : après essai il semble bien fonctionner. Je n'ai pas de Windows sous la main donc je ne peux pas vérifier dans l'immédiat mais il n'y a pas de raison que ça merde.
Par contre, je n'arrive pas à le faire fonctionner avec Android 2.3 (je n'ai pas plus récent et je ne compte pas acquérir une tablette tous les deux ans, faut pas déconner). Dommage.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ZFS
Posté par flan (site web personnel) . Évalué à 1.
exFAT a l'avantage d'être fait pour les échanges, entre autres via clefs USB. En revanche, je n'ai pas essayé personnellement, du coup je ne sais pas trop ce que ça donne point de vue droits…
[^] # Re: ZFS
Posté par claudex . Évalué à 2.
Ce n'est pas lié à ext4 mais au mask par défaut. Si Linux gérait les permissions sous NTFS, ce serait le même problème.
Non, j'utilise du FAT pour mes clefs usb (aussi pour être compatible Mac OS).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ZFS
Posté par flan (site web personnel) . Évalué à 3.
Tiens, d'ailleurs, où pourrait-on trouver un comparatif récent de systèmes de fichiers, avec les performances ?
Ce n'est pas évident de tomber dessus…
[^] # Re: ZFS
Posté par claudex . Évalué à 9.
Sur Phoronix, un article sur deux est un bench de gpu, un article sur deux est un bench de cpu et un article sur deux est un bench de fs.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ZFS
Posté par tyoup . Évalué à 4.
Ya pas aussi un article sur les architectures 4 tiers de temps en temps ?
[^] # Re: ZFS
Posté par Zenitram (site web personnel) . Évalué à 1.
euh…
Juste pour être sûr, tu es conscient que contrairement à l'exemple de Xavier qui est volontairement conceptuellement faux, ton exemple est lui conceptuellement juste?
(tier = niveau, on peu avoir 4, 5… niveaux sans problèmes, d'ailleurs on dit "multi-tier", le 3-tier n'étant qu'une version du multi-tier).
Du coup, je ne comprend pas la blague (ou il n'y en pas?)
Je demande ça, car la blague que j'aurai comprise me fait un peu "plouf" faute d'erreur volontaire dedans, et me laisse penser que "tier" anglais est vu comme "1/3" par toi (ce qui est le cas de pas mal de monde, certes).
[^] # Re: ZFS
Posté par Maclag . Évalué à 4.
Moi je vois l'hypothèse que la blague repose sur l'insistance lourde sur le fait qu'on a 3 types d'articles qui sont publiés à la fréquence d'un article sur 2, et que s'il ne voit aucun souci là-dedans, il rappelle aussi l'existence d'un 4ème type article qui reviendrait (trop) souvent.
Puisque j'ai dû y réfléchir et me l'expliquer, c'est une blague qu'on explique, et une blague qu'on explique, c'est tout de suite… euh… pourri?
[^] # Re: ZFS
Posté par Laurent Cligny (site web personnel) . Évalué à 3.
Le jeu de mot fait partie de la blague à mon avis, et ça m'a fait marrer.
[^] # Re: ZFS
Posté par Psychofox (Mastodon) . Évalué à 4.
zfs c'est quand même pas mal sur desktop avec des snapshots automatiques. Trop gourmand…tant que tu n'utilises pas de dedup je dirais que non.
[^] # Re: ZFS
Posté par Dabowl_75 . Évalué à 1.
les gens sérieux utilisent gpfs
# XFS et panne hardware
Posté par Albert_ . Évalué à 2.
Cela a peut etre change mais il y a quelques annees un crash hardware pouvait te mettre en vraque le FS et ce n'est pas des on-dit cela m'est bien arrive. Depuis je fuis XFS mais bon les choses se sont peut etre ameliore avec les annees? Du coup, je tenterais plus facilement BTRFS que XFS…
[^] # Re: XFS et panne hardware
Posté par scullder . Évalué à 2.
De mon expérience récente, sous centos 5 et 6, si tu as un crash violent qui t'empêches de démonter proprement ton fs XFS, il faut absolument faire un xfs_repair avant de remettre en prod :)
Et pour faire un xfs_repair, il te faut une quantité de mémoire suffisante (je suis monté autour de 50Go de mémoire utilisé pour xfs_repair sur un volume de 170To) et ça prend plusieurs heures.
# Réduction
Posté par claudex . Évalué à 3.
Ce qui m'a toujours décourager d'utiliser XFS, c'est l'impossibilité de réduire un volume. Ce que je trouve très chiant quand on a pas une grappe de disque qui permettent de rapidement copier et récupérer les données.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# et le fsck
Posté par SauronDeMordor (site web personnel) . Évalué à 2.
sur un FS de 20 ou 30To essaye un peu d imaginer un fsck
tu reviens demain en ext4
en xfs cela se passe mieux, et en cas de gros soucis et bien tu passe en xfs_admin et au boulot.
depuis très longtemps j utilise xfs en prod pour ces raisons, mkfs rapide, fsck "inutile", mais pour l avenir il y a quand même plein d autre chose qui se pressentent.
[^] # Re: et le fsck
Posté par NeoX . Évalué à 2.
mais vivement recommandé
sur mon NAS, il conseille de faire un xfs_repair apres un reboot sauvage par exemple.
# pendant ce temps la, sur ftp.redhat.com
Posté par Misc (site web personnel) . Évalué à 5.
D'après mon client ftp et d'après le site de Red hat, RHEL 7 Beta est sorti. Donc si les gens veulent voir le choix par défaut, il y a une iso.
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par claudex . Évalué à 5.
Pas besoin de l'iso, il suffit de lire les notes de version de la bêta. On y apprend notamment que Btrfs est en technology preview. (par respect pour le suspense insoutenable d'XFS, je ne dirais pas ce que dit l'annonce à son sujet.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par Misc (site web personnel) . Évalué à 2.
Moi, je parlerais pas de systemd, qui n'est pas beaucoup mentionné dans les notes de versions, est ce que ça veut dire qu'il est la dans un mode de compatiblité, quel version est prise, tant de suspens !
je dirais pas un mot sur kde, y a rien à dire, ou peut être que si, enfin je sais pas.
Et parler de détails comme "est ce que ifconfig est la" ou "mariadb, mysql, vers lequel notre coeur balance…"
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par chaispaquichui . Évalué à 2.
Et pour répondre à ces insoutenables questions :)
Je n'ai pas regardé en profondeur mais j'ai l'impression qu'il y a beaucoup de services qui utilisent les .service de systemd et pas le mode de compatibilité. J'entends déjà les hurlements de joie de Kaane :)
Les nostalgiques peuvent néanmoins retrouver cette commande dans le package net-tools
J'avais quelques craintes au sujet de la nouvelle version d'anaconda qui avait fait parler d'elle (et pas en bien) mais au final, ça c'est bien passé. Je vais quand même voir ce que l'outil de partitionnement a dans le ventre.
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par Misc (site web personnel) . Évalué à 3.
Après un rapide coup de yum, je trouve 2 paquets avec un script d'init, iprutils et yum ( et le paquet initscripts, avec network, netconsole ). Ça fait 6 scripts d'init au total.
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par claudex . Évalué à 4.
yum a un script d'init ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par chaispaquichui . Évalué à 1.
Oui, le paquet yum dépose le script "yum-cron" dans l'init qui contrôle si le script "0yum-daily.cron" doit s'exécuter ou non
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par claudex . Évalué à 3.
Et on remarquera qu'il n'y a que mariadb de proposé, pas de mysql. J'aime aussi l'installateur qui ne s'interrompt pas 42 fois au milieu pour poser des questions avant de continuer (je crois qu'il ne reste plus que Debian qui fait ça dans les distributions répandue qui se veulent facile à installer).
Du côté des trucs polémiques, /bin, /lib, /lib64 et /sbin ne sont plus que des liens symboliques.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Des liens symboliques
Posté par Sylvain Blandel . Évalué à 1.
Cela semble se généraliser : sous Archlinux également, /bin, /sbin et /usr/sbin sont des liens symboliques vers /usr/bin. De même, /lib, /lib64 et /usr/lib64 sont des liens symboliques vers /usr/lib.
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par MTux . Évalué à 2.
Excellente nouvelle, par contre ils sont très chiants pour le téléchargement des produits, il faut s'inscrire et trouver la page qui va bien. Un peu comme si Microsoft reprenait l'espace client de OVH, un vrai foutoir.
Si quelqu'un a une URL je suis preneur.
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par WhiteCat . Évalué à 1.
https://access.redhat.com/downloads/content/226/ver=/rhel---7/x86_64/product-downloads
J'ai trouvé l'adresse en moins de 2 après m'être connecté sur leur site.
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par MTux . Évalué à 2.
Il faut disposer d'un compte client, j'en ai un (que j'ai utilisé pour la beta 6), mais cela ne me donne pas le droit de prendre la version 7.
The resource you requested requires account permissions you do not currently have. If you believe you should have permission to view this resource, please contact your organization administrator.
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par WhiteCat . Évalué à 2.
Bizarre, moi j'ai pas de compte client, juste un compte sur leur site. Un jour j'ai demandé une évaluation de RHEV c'est tout. Là je suis en train de dl l'iso de la 7beta.
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par Misc (site web personnel) . Évalué à 2.
Comme dit plus haut :
ftp://ftp.redhat.com/redhat/rhel/beta/7/
( certes en terme moins clair )
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par MTux . Évalué à 2.
Merci pour le lien.
On va me trouver pénible mais j'y arrive pas. Leur serveur est super lent et je n'ai pas pu aller jusqu'au bout du téléchargement. Si quelqu'un a un lien torrent, je suis preneur…
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par Ermaion (site web personnel) . Évalué à 1.
Je confirme après avoir testé la version beta que c'est bien XFS qui est sélectionné par défaut.
Voila.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.