Articles précédents : Articles
- [19] Parlement européen : la résolution de soutien à l’EPLA tourne au vote de défiance envers l’OEB
- [6] Eudora s'offre une cure de jouvence et passe à l'OpenSource
- [21] Les brevets et l'innovation en danger au Parlement europeen
- [5] Concours de template/clipart pour OpenOffice.org
- [30] MPD, un lecteur audio pas comme les autres..
- [50] Le retour des brevets logiciels en Europe via l’EPLA
- [4] Divergence Numérique ce soir sur Divergence-FM
- [45] Où en est le projet One Laptop per Child ?
- [2] Publication du premier brouillon de deux licences pour la documentation
- [43] Controverses autour de la version 3 de la licence GPL
Liens connexes
- Linux-Watch (482 hits)
- Est-il temps de travailler sur Ext4 ? (795 hits)
- Il est temps de travailler sur Ext4 ! (569 hits)
- Article sur KernelTrap (314 hits)
Dépêche modérée par
Dépêche éditée par
Il faut dire que Andrew Morton, un développeur bien connu (pour son kernel -mm), a déjà ajouté le nouveau système de fichier expérimental depuis le 10 octobre 2006.
Les possibilités de ce nouveau système de fichiers sont le support pour un stockage de 1024 péta-octets par volume. Un péta-octet est égal à 250 (deux à la puissance cinquante) octets. Il ne faut pas se tracasser, il y a bien des établissements qui utilisent le péta-octet comme unité normale de stockage (un exemple est la machine à remonter le temps de l'archive internet...).
Ext4 intègre également des nouveautés contenues dans les nouveaux systèmes de fichiers tels que Reiser4, JFS, etc. C'est également un système de fichier journalisé, ce qui permet de récupérer des données « perdues » bien plus facilement. Dans la lignée des ext, ext4 est rétro-compatible avec ext3. Il est donc possible de monter une partition ext4 en tant que ext3, on ne perd que la puissance des nouvelles possibilités.
Le nouveau système de fichiers est dans le noyau 2.6.19rc1-mm1. Si tout fonctionne comme prévu, il est espéré que ext4 soit pleinement opérationnel d'ici 6 à 9 mois. Comme toujours, si vous souhaitez tester ce filesystem, il est recommandé de sauvegarder vos données au préalable.
![[en]](../../../images/en.png)
Linux-Watch (482 hits)-
Est-il temps de travailler sur Ext4 ? (795 hits)
-
Il est temps de travailler sur Ext4 ! (569 hits)
-
Article sur KernelTrap (314 hits)
> Lire la dépêche (63 commentaires, moyenne: 3).
La journalisation n'a rien à voir avec la récupération de données perdue
> C'est également un système de fichier journalisé, ce qui permet de récupérer des données « perdues » bien plus facilement.
Un système de fichiers journalisé est tout au plus un système de fichiers qui autorise une vérification d'intégrité rapide après un arrêt innopiné. Cela n'a rien à voir avec la possibilité de récupérer des données perdues. Si un cluster est défectueux au milieu du disque dur, le fait que le système de fichiers soit journalisé ou non ne m'aidera pas à récupérer les données perdues sur ce cluster.
-
[^]Re: La journalisation n'a rien à voir avec la récupération de données pe
Posté par Nÿco (Jabber id, page perso, ) le 18/10/2006 à 08:12. (lien). Évalué à 1.Dans ce cas, comment appelle-t-on la journalisation des transactions elles-mêmes, comme les redo logs d'Oracle ?
--
Jabber ID : xmpp:Nyco@jabber.fr-
[^]Re: La journalisation n'a rien à voir avec la récupération de données pe
Posté par iug () le 18/10/2006 à 10:14. (lien). Évalué à 3.La journalisation que j'ai appris pendant mes études consistait à stocker de manière incrémentale les modifications du fs, pour pouvoir revenir dans un état précédent cohérent au besoin.
Peut-être que les ext3 et autres mettent ça en oeuvre mais c'est en tout cas très minimaliste, il ne sait défaire que la dernière transaction ratée si j'ai bien compris. Au final ça ne garantit pas de pouvoir retrouver l'état du disque 10 minutes plus tôt en cas de crach.
Ca serait cool un fs qui garde toutes les modifs depuis le boot précédent.-
[^]Re: La journalisation n'a rien à voir avec la récupération de données pe
Posté par Diplodocus (Jabber id, page perso, ) le 18/10/2006 à 12:45. (lien). Évalué à 6.Au bout de deux ans d'uptime sur un serveur, je ne veux pas imaginé la taille du journal ....
-
[^]Re: La journalisation n'a rien à voir avec la récupération de données pe
-
[+] [^]Re: La journalisation n'a rien à voir avec la récupération de données pe
Posté par iug () le 19/10/2006 à 07:08. (lien). Évalué à -3.Je trouve que c'est un gros manque dans les FS habituels.
Les utilisateurs qui ont l'habitude de patcher leur noyau, d'utiliser des drivers graphiques buggy... seraient bien contents de pouvoir ne pas perdre des données après un crash.
Cela arrive quand même très souvent avec les FS qui se disent journalisés actuels, en particulier perdre ses préférences sous Gnome...-
[^]Re: La journalisation n'a rien à voir avec la récupération de données pe
Posté par IsNotGood () le 19/10/2006 à 07:29. (lien). Évalué à 2.> Cela arrive quand même très souvent avec les FS qui se disent journalisés actuels,
Ils journalisent quoi ?
Ext3 :Data Mode
---------
There are 3 different data modes:
* writeback mode
In data=writeback mode, ext3 does not journal data at all. This mode provides
a similar level of journaling as that of XFS, JFS, and ReiserFS in its default
mode - metadata journaling. A crash+recovery can cause incorrect data to
appear in files which were written shortly before the crash. This mode will
typically provide the best ext3 performance.
* ordered mode
In data=ordered mode, ext3 only officially journals metadata, but it logically
groups metadata and data blocks into a single unit called a transaction. When
it's time to write the new metadata out to disk, the associated data blocks
are written first. In general, this mode performs slightly slower than
writeback but significantly faster than journal mode.
* journal mode
data=journal mode provides full data and metadata journaling. All new data is
written to the journal first, and then to its final location.
In the event of a crash, the journal can be replayed, bringing both data and
metadata into a consistent state. This mode is the slowest except when data
needs to be read from and written to disk at the same time where it
outperforms all others modes.
La majorité des fs journalisé font "data=writeback".
Par défaut ext3 fait "data=ordered".
> Les utilisateurs qui ont l'habitude de patcher leur noyau, d'utiliser des drivers graphiques buggy...
Pour ça il n'y a que les backups.-
[+] [^]Re: La journalisation n'a rien à voir avec la récupération de données pe
Posté par iug () le 20/10/2006 à 12:05. (lien). Évalué à -2.> Pour ça il n'y a que les backups.
Non justement. Toutes les pertes de données dues au soft que j'ai subies auraient été évitées.-
[^]Re: La journalisation n'a rien à voir avec la récupération de données pe
Posté par IsNotGood () le 20/10/2006 à 16:08. (lien). Évalué à 2.N'importe quel driver dans le noyau peut corompre un système de fichier.
C'est aussi valabre pour les drivers graphiques.
Idem pour un patch sur le noyau, même quand le noyau n'est pas buggé.
Fais ce que tu veux, ce sont tes données, pas les miennes.
-
-
-
-
-
-
Déjà dans la branche stable
Le nouveau système de fichiers est dans le noyau 2.6.19rc1-mm1
En fait, c'est plus que ça, le système de fichier Ext4 est déjà dans le 2.6.19-rc2-git-patatère.
Autrement dit, le prochain noyau 2.6.19 proposera Ext4 (si l'option "experimental" est sélectionnée).
-
[^]Re: Déjà dans la branche stable
Posté par IsNotGood () le 18/10/2006 à 17:23. (lien). Évalué à 8.> Autrement dit, le prochain noyau 2.6.19 proposera Ext4
Rires :-)
J'ai lu un peu la lkml est y a 1 semaine, deux patch pour ext4 et été soumis :
1- une copie exacte de ext3 dans le répertoire ext4
2- sed -e "s/ext3/ext4-devel/g"
C'est tout pour l'instant :-)
9 mois de boulot sont actuellement estimé pour avoir ext4. Patience.-
[^]Re: Déjà dans la branche stable
Posté par Jérôme Pinot (page perso, ) le 19/10/2006 à 01:03. (lien). Évalué à 6.J'ai lu un peu la lkml est y a 1 semaine, deux patch pour ext4 et été soumis :
1- une copie exacte de ext3 dans le répertoire ext4
2- sed -e "s/ext3/ext4-devel/g"
C'est tout pour l'instant :-)
Regarde les sources. [1]
Moi j'ai regardé les sources du 2.6.19-rc2-g73ed9a86 (mais en fait le code d'Ext4 n'a pas changé depuis une semaine), et j'ai vu :
Premièrement, il y a le support pour "extent" (voir http://www.linux-watch.com/news/NS3183866977.html ). Un petit fichier de 2 152 lignes, une paille.
Deuxièment, il y a encore d'autres modifications dans le code qui n'ont rien à voir avec un simple changement de nom ou un nettoyage.
Bien sûr que les 2 arbres sont très similaires, le fork vient juste de se produire. Mais c'est faux de dire que ce n'est qu'une copie de Ext3 avec un nom différent. D'ailleurs, je vois mal quel aurait été l'intérêt, dans ce cas, de faire ceci dans la branche stable.
[1] Pour les fainéants : http://kernel.org/git/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Fl(...)-
[^]Re: Déjà dans la branche stable
Posté par IsNotGood () le 19/10/2006 à 04:36. (lien). Évalué à 6.> Mais c'est faux de dire que ce n'est qu'une copie de Ext3 avec un nom différent.
C'était le cas quand j'ai regardé la lkml.
http://marc.theaimsgroup.com/?l=git-commits-head&m=11605(...) Le 11/10/2006 ; donc il y a une semaine ; donc je n'ai pas dit de connerie.
Les travaux viennent de débuté, je, on, tout le monde s'y attendait. Tu ne me surprends en rien. Oui les développeurs ont très probablement une belle pile de patch en attende...
Par contre la news dit en titre "Ext4 bientôt sur votre bureau".
La news dit aussi : Le nouveau système de fichiers est dans le noyau 2.6.19rc1-mm1.
Là je trouve que c'est s'emballer bien fort !
C'est une banche de développement qui vient juste de débuter.
NB : Il me semble que le "il est espéré que ext4 soit pleinement opérationnel d'ici 6 à 9 mois" n'y était pas lorsque j'ai lu la news.
En rien je ne voulais dénigrer ext[34]. J'utiliser quasi exclusivement ext2/3 depuis presque 9 ans !
J'ai une quasi confiance absolue en ext3 (rock solid le bousin). Ces performances sont plus que respectables contrairement à ce qu'on lit ici et là (elles se sont significativement améliorées durant 2.6.x et le 2.6.18 apporte encore un petit coup de boost).
J'ai aussi une grande confiance dans la façon dont sont menés les développements.
> Mais c'est faux de dire que ce n'est qu'une copie de Ext3 avec un nom différent.
C'était vrai le 10/11/2006. Il a été décidé de débuter avec une copie de ext3. A un moment la question c'est posé d'ajouter à ext3 (les sources) les fonctionnalité d'ext4. En effet, ext4 devra savoir utiliser le FS ext3 (donc ext3 (les sources) vont disparaite lorsqu'ext4 _final_ sortira). Mais ça a été jugé trop dangereux.
> D'ailleurs, je vois mal quel aurait été l'intérêt, dans ce cas, de faire ceci dans la branche stable.
T'as raté un épisode.
Le dépôt de développement est/sera le linux 2.6 officiel. Donc oui, ça va exploser dans tout les sens au début et manger les jambes des enfants même si c'est fait dans une branche Linux dite stable.
C'est pour ça que ext4 a été au début une copie de ext3. Il n'a pas été initialement ajouté ext4 (ou une version de développement) au noyau Linux mais seulement une copie de ext3.
En fait, le développement a débuté mi-aout si j'ai bonne mémoire. Donc 2 mois seulement à "empiler" des patchs. Maintenant ils sont envoyés dans Linux (via Andrew) pour que tout le monde audite le code. Et le premier des patches est une copie d'ext3.-
[^]Re: Déjà dans la branche stable
Posté par IsNotGood () le 19/10/2006 à 07:24. (lien). Évalué à 1.> Oui les développeurs ont très probablement une belle pile de patch en attende...
J'ai regardé, ils ont une belle pile de patch et beaucoup ont déjà été "bouffé" par la branche -mm.
Je n'imaginait pas que ça puisse aller aussi vite :-)
23 files changed, 5264 insertions(+), 2994 deletions(-)
-
-
-
Et moi...
...en temps que particuliers avec mon Ubuntu, qu'est-ce que ca change ?
C'est vrai on commence à trouver des disques 750Go
Sinon, d'après le 1er lien, ext4 supportera l'option Extent : cela permet de reserver à l'avance une place contigue sur le disque, même si le fichier est plus petit. Lorsque que de nouvelles données seront écrites, elles le seront sur la place réservée, donc les accès seront plus rapide.
D'après http://kerneltrap.org/node/7224 pour l'utiliser, il faut monter le FS avec une option particulière.
-
[^]Re: Et moi...
Posté par Donk (Jabber id, ) le 18/10/2006 à 08:33. (lien). Évalué à 5.Sinon, d'après le 1er lien, ext4 supportera l'option Extent : cela permet de reserver à l'avance une place contigue sur le disque, même si le fichier est plus petit. Lorsque que de nouvelles données seront écrites, elles le seront sur la place réservée, donc les accès seront plus rapide.
Ce n'est pas la même chose que l'option de montage « reservation » pour l'ext3?--
JabberID: donk@jabber.fr-
[^]Re: Et moi...
Posté par IsNotGood () le 18/10/2006 à 17:31. (lien). Évalué à 2.> Ce n'est pas la même chose que l'option de montage « reservation » pour l'ext3?
Non. Reservation est une technique qui ne touche pas le système de fichier écrit sur le disque. Reservation fait des réservations mais c'est uniquement tracé en mémoire vive. Par exemple tu écris 1ko sur un fichier, reservation va réserver de la place comme si tu écrivais par exemple 16ko. C'est-à-dire que ces 16ko sont réservés à ce fichier uniquement. Avantages : ça diminue la fragmentation du système de fichier, ça améliore la tenue en charge.
C'est une description dans les grandes lignes !
Le noyau 2.6.18 a un patch pour faire des lectures de donnée en avance (à ne pas confondre avec readahead des disques). Améliore la tenu en charge, diminue la consommation de cpu.
-
[^]Re: Et moi...
Posté par IsNotGood () le 18/10/2006 à 17:33. (lien). Évalué à 1.> Ce n'est pas la même chose que l'option de montage « reservation » pour l'ext3?
Je ne suis pas convaincu que l'option "reservation" soit nécessaire aujourd'hui. reservation doit être activé par défaut (la dernier fois que j'ai vérifié, c'était le cas).
-
Performances ?
Et au niveau des performances, qu'est-ce qui est annoncé ? A-t-on déjà quelques retours ?
--
http://www.tessier-net.org
-
[^]Re: Performances ?
Posté par iug () le 18/10/2006 à 12:17. (lien). Évalué à 8.http://www.bullopensource.org/ext4/
Dans de rare cas c'est moins bien que ext2, sinon c'est assez bourin.
pardon ?
bon je suis peut être mal réveillé, mais où l'auteur a trouvé que ext3 ne gérait pas au dessus de 1Tera ?? J'ai ici des partoches de plus de 3Tera, alors si on parle de 1Tera = 1000Go, enfin bref un truc comme ça :
/dev/sdd1 3,6T 2,3T 1,4T 63% /serveurs-backup
ou encore comme ça :
/dev/sdd1 on /serveurs-backup type ext3 (rw)
bin je confirme, ça marche !
-
[^]Re: pardon ?
Posté par Sylvain Briole (page perso, ) le 18/10/2006 à 07:37. (lien). Évalué à 5.C'est clair, le système de fichiers ext3 peut supporter plus d'un tera-octets:
D'après :
http://fedoraproject.org/wiki/ext3-devel
The current limits for ext2/ext3 filesystem are 2 terabytes with 1KB blocks, and 8 terabytes with 4KB blocks.-
[^]Re: pardon ?
Posté par IsNotGood () le 18/10/2006 à 17:40. (lien). Évalué à 2.Ça a un peu changé.
FC6 a un patch pour supporter 2^32 bloques (il est aussi dans la banche -mm). Donc avec block size à 4 ko, ça fait 16 To. C'est principalement un passage de signed int à unsigned int.
Des patchs ont circulé pour avoir block size de 8 ko voire 16 ko.
Notons que ext3 ne peut faire mieux sur architecture 32 bits. C'est la limite du VFS quelque soit le FS.
-
-
[+] [^]Re: pardon ?
Posté par inico (Jabber id, page perso, ) le 18/10/2006 à 07:52. (lien). Évalué à -2.2.3 To utilisé ?
Ils sont gros tes backups ...--
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..-
[^]Re: pardon ?
-
-
[^]Re: pardon ?
Posté par theocrite (Jabber id, page perso, ) le 18/10/2006 à 08:18. (lien). Évalué à 8.où l'auteur a trouvé que ext3 ne gérait pas au dessus de 1Tera ??
D'après wikipedia[1][2], de 16Go à 2To pour un fichier et de 2 à 32To pour une partition.
Pour ext4, wikipedia confirme[1][3] les 1024 Po annoncés dans la dépèche.
Par ailleurs
[1 ]http://en.wikipedia.org/wiki/Comparison_of_file_systems
[2] http://en.wikipedia.org/wiki/Ext3
[3] http://en.wikipedia.org/wiki/Ext4--
Le libre vaincra, tout est déjà joué.
Ca pour une nouvelle ...
<mode="BeOS le faisait il y a dix ans">BeOS le faisait déjà il y a dix ans, avec les attributs étendus en prime !</mode>
-
[^]Re: Ca pour une nouvelle ...
Posté par Nÿco (Jabber id, page perso, ) le 18/10/2006 à 08:14. (lien). Évalué à 7.Les attributs étendus existent dans ext3, comme les ACL (stockés dans les attribus étendus), mais c'est super-chiant à sauvegarder et restorer...
--
Jabber ID : xmpp:Nyco@jabber.fr-
[^]Re: Ca pour une nouvelle ...
Posté par Krunch (Jabber id, page perso, ) le 20/10/2006 à 10:04. (lien). Évalué à 2.star(1) (même interface que tar(1)) et pax(1) (POSIX) sont tes amis.
--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: Ca pour une nouvelle ...
-
-
[+] traduction
C'est quoi ce délire de (mal) traduire des articles anglais et d'en faire des news sur DLFP ?
(avant même d'aller voir l'article de linux watch, ça se voit grosse comme une maison cette traduction bancale à deux sous)
-
[^]Re: traduction
Posté par Nÿco (Jabber id, page perso, ) le 18/10/2006 à 08:16. (lien). Évalué à 9.Moi j'aurais plutôt dit comme ça : "Merci d'avoir porposé la dépêche ! (même si la trad est pas top à certains endroits)"
--
Jabber ID : xmpp:Nyco@jabber.fr-
[+] [^]Re: traduction
Posté par Christophe Merlet (page perso, ) le 18/10/2006 à 08:27. (lien). Évalué à -6.Moi je ne dis pas merci a quelqu'un qui ne respecte pas les droits d'auteurs élémentaires.
-
[^]Re: traduction
Posté par Bayet Thierry () le 18/10/2006 à 08:37. (lien). Évalué à 5.Hum hum...
Désolé, mais j'ai commencer la trad correctement, puis, me suis dis qu'il n'y avais pas besoin de tout mettre...
Juste un point pour les personnes qui n'avaient pas le temps/envie de traduire.
Pour ce qui est des droits d'auteurs, j'ai mis le lien de linux watch... et j'avais commencer un texte (qui fut effacé par un admin je suppose).
Alors, au lieu de tirer sur le pianiste, écoutez la musique.
De toutes façons, c'est bien là une jolie manière de remercier le pianiste qui ne demandais que de jouer...--
snspy
-
-
-
[+] [^]Re: traduction
Posté par Christophe Merlet (page perso, ) le 18/10/2006 à 08:24. (lien). Évalué à -4.Effectivement, encore une fois, le respect des droits d'auteurs est bafoué. Sans autorisation de linux-watch et du rédacteur original, ce repompage est interdit.
Sans compter la tromperie d'une traduction approximative sans citer explicitement que l'on a affaire a une traduction.
Décidément, ya des mentalités que rien ne pourra changer :(-
[^]Re: traduction
Posté par Bayet Thierry () le 18/10/2006 à 08:40. (lien). Évalué à 9.Encore une fois, j'avais placé un texte au début...
Oui, j'ai mis le lien de linux-watch... Mais j'aurais apparement pas dû.
En tout cas, qu'on ne s'étonne pas que dlfp n'aie plus que des trolls pour vivre... pour ma part, c'est l'unique contribution qu'une bande de piaf de votre genre aura droit de ma part.
Salutations--
snspy-
[^]Re: traduction
Posté par towanda () le 18/10/2006 à 08:56. (lien). Évalué à 10.Bonjour,
je suis d'accord, l'accueil est un peu rude (j'y ai participé moi même, donc mea-culpa). Cependant, pour une news qui passe en "Une" de linuxfr, et qui va donc être beaucoup vue, je trouve "léger" de mettre des choses comme ext3 qui ne passe pas le tera, et la journalisation qui permet de récupérer des données.
Maintenant pour moi la responsabilité (enfin c pas si grave hein !) est plutôt du côté de linuxfr : cette news n'aurait pas dû passer dans l'état en "Une". Donc, merci d'avoir présenté cette news, et dommage qu'elle soit passée sans être corrigée.-
[^]Re: traduction
-
-
-
[+] [^]Re: traduction
Posté par zerchauve () le 19/10/2006 à 14:14. (lien). Évalué à -4.encore une fois, ca se pignole comme des gros inactifs petits bourgeois, ca se tire dans les pattes, ca se tripote la nouille, ca gueule, mais ca pisse pas loin.
allez zou.--
-- Le voilà qui s'en va, un des prototypes personnels de Dieu... Trop bizarre pour vivre, trop unique pour mourir
-
est pourquoi pas
utiliser ZFS (de SUN) ? ce FS semble très puissant. J'imagine que la question a déjà été posé...
-
[^]Re: est pourquoi pas
Posté par vrm (page perso, ) le 18/10/2006 à 09:39. (lien). Évalué à 4.doit surement y avoir des incompatibilité de licence etre OpenSolaris et ZFS et surement un ou deux brevet dans le coin
-
[^]Re: est pourquoi pas
Posté par Vivi (page perso, ) le 18/10/2006 à 10:04. (lien). Évalué à 4.selon Wikipedia http://en.wikipedia.org/wiki/Zfs#Platforms :
Porting ZFS to Linux is complicated by incompatibilities between CDDL, the license its source is released under, and GPL, the license which governs the Linux kernel. To work around this problem the Google Summer of Code program is sponsoring a port of ZFS to Linux's FUSE system so the filesystem will run in userspace instead. However, running a file system outside the kernel has significant perfomance impact.
-
[^]Re: est pourquoi pas
Posté par Gabriel Linder () le 18/10/2006 à 10:43. (lien). Évalué à 4.C'est sûr que les devs du kernel Linux sont moins habitués à ce genre de problèmes que les devs BSD ;)
Plus sérieusement ZFS semble en bonne voie d'incorporation dans DragonFly BSD, et à partir de lui probablement dans les autres BSD également : http://leaf.dragonflybsd.org/mailarchive/kernel/2005-12/msg0(...)-
[^]Re: et pourquoi pas
Posté par pipotron () le 18/10/2006 à 12:22. (lien). Évalué à 1.utiliser XFS
Il me semble que la limite est de l'ordre de l'HexaOctet vu que c'est un système de fichier 64 bit (2^64).
XFS ayant l'avantage d'être déjà intégré dans le noyau depuis le 2.4.24-
[^]Re: et pourquoi pas
Posté par Nicolas () le 18/10/2006 à 13:27. (lien). Évalué à 5.sauf que un des buts de ext4 c'est de tenir compte du fait que avec l'augmentation de la taille des DD et tout simplement de la technologie que les DD seront moins fiables physiquement. Et il faut un moyen de recuperer les donnees avec un fsck dans un temps moins important que l'age de l'univers et sur le point crash matos XFS est, comment dire..., une bouse? En tout cas c'est (etait?) bien ecrit dans la doc XFS de ne pas lui faire confiance si le matos est pas nickel. La derniere fois que j'ai essaye ce systeme (il y a 1 an et demi) j'ai vite dechante justement a cause de ce genre de probleme.
-
[^]Re: et pourquoi pas
Posté par Rémi Hérilier (page perso, ) le 18/10/2006 à 16:40. (lien). Évalué à 4.Selon http://fr.wikipedia.org/wiki/Pr%C3%A9fixe_du_syst%C3%A8me_in(...) , le terme est exaoctet (altération du préfixe de grandeur héxa : héxa → 6 et 1000^6 = 10^18 → exa).
Et si on suit le cheminement Ko = 2^10, Mo = 2^20... on a Eo = 2^60 et non 2^64 (qui correspond à 16 Eo).
Qui veut ouvrir les paris pour la date de sortis des FS qui gèrent le Yo ? 0:-)
--
Pourquoi compter sur ses doigts jusqu'à 10 alors qu'on peut aller jusqu'à 1023 ?-
[^]Re: et pourquoi pas
Posté par Frédéric Massot (page perso, ) le 18/10/2006 à 17:03. (lien). Évalué à 3.D'après http://en.wikipedia.org/wiki/Comparison_of_file_systems#Limi(...) UFS2 peut aller jusqu'a 1YiB, soit 2^80 octets.
-
-
-
-
-
[^]Re: est pourquoi pas
Posté par Nicolas () le 18/10/2006 à 13:30. (lien). Évalué à 3.There is no way in hell that ZFS proper would make it into the Linux kernel. As Andrew put it, it is a rampant layering violation. But ZFS features? That's another story, altogether.
Of course, to get all those features would take a lot more than an ext3/ext4 fork. VFS would need some fairly radical changes, as well.
Ca repond a ta question?
Compatibilité
À propos de la compatibilité, j'aurais deux questions :
1. Est-ce que la compatibilité ext3 va jusqu'à l'ext2 ? En d'autres mots, est-ce qu'il sera possible de monter un FS ext4 avec un noyau qui ne supporte que l'ext2 ? Je sais qu'il n'y en a plus beaucoup, mais je ne serais pas plus surpris que ça que certaines personnes soient un jour confrontées à la situation.
2. Est-ce que je pourrai convertir mes partitions ext3 en ext4, comme j'avais converti mes vieilles partitions ext2 en ext3 avec une simple commande ? Ou bien une copie/sauvegarde sera-t-elle nécessaire ? Quand on voit que ce nouveau FS se destine aux stockages de grande capacité, tout copier peut prendre de nombreuses heures...
-
[^]Re: Compatibilité
Posté par case42 (page perso, ) le 18/10/2006 à 12:04. (lien). Évalué à 1.Pour le 1/ , y a interet, dans la mesure ou si mes souvenirs sont bon, Grub ne sait gerer que l'ext2 (normal et logique en fait), ce serait balot d'avoir a creer un /boot ou carrement un / en ext2 ou ext3 a cause de ca...
-
[^]Re: Compatibilité
Posté par Sylvain Briole (page perso, ) le 18/10/2006 à 12:23. (lien). Évalué à 4.D'un autre côté, quel est l'intérêt d'un /boot en ext3 ou ext4?
Je ne connais pas toutes les distributions, mais sous Gentoo en tout cas, le manuel d'installation préconise un /boot en ext2, ce dernier n'étant pas monté par défaut (noauto dans /etc/fstab) par le système.
La journalisation et autres finesses d'ext3 ou ext4 (par rapport à ext2) ne sont-elles pas superflues pour ce type de partition/système de fichiers?-
[^]Re: Compatibilité
Posté par case42 (page perso, ) le 18/10/2006 à 12:45. (lien). Évalué à 3.Pas vraiment d'interet effectivement a faire un /boot en ext3 ou ext4, mais il faut aussi reconnaitre que depuis la disparition du probleme du boot au dela du 1024ieme cylindre, l'interet d'une partition /boot dediee s'est aussi quelque peu amoindrie... J'ai a l'esprit l'install par defaut de la Ubuntu qui ne cree qu'une partition / , et pas de /boot...
-
[^]Re: Compatibilité
Posté par Couderc Romain (page perso, ) le 18/10/2006 à 14:10. (lien). Évalué à 6.Il est vrai que l'intéret de /boot sur une partoch à part semble faible aujourd'hui... Mais cela pourrait revenir...
En effet pusique l'on parle ici de compatibilité, j'ai du mal à comprendre comment un module ext3 peut exploiter une partition ext4 si celle ci dépasse la taille limite de 32To... Le module fera t'il des coupes... et si l'envie lui prenait de couper /boot/vmlinuz*...
La vrai question c'est comment est-il réellement possible d'assurer une compatibilitée dans ce sens si la partition dépasse la taille limite ext3. Il est hors de question d'avoir une gestion partielle (on garde que les inodes qui pointent sur des secteurs dans la zone des 32 To et on zappent les autres...) car un filesystem incohérent, c'est inadmissible.
-
[^]Re: Compatibilité
Posté par Loic Pefferkorn (page perso, ) le 21/10/2006 à 23:45. (lien). Évalué à 2.je suis toujours obligé de conserver une partition /boot à cause de LVM, en effet ni grub ni lilo ne savent comment aller y chercher le noyau. La flexibilité à un prix, celle d'une partition primaire :/
-
[^]Re: Compatibilité
Posté par Couderc Romain (page perso, ) le 23/10/2006 à 07:12. (lien). Évalué à 2.Hummm, je regrette mais lilo est capable de lire sur du LVM. Et même si celui ci est sur du RAID logicielle.
Preuve sur un de mes serveurs:
monserveur:~$
monserveur:~$df -Th
Sys. de fich. Type Tail. Occ. Disp. %Occ. Monté sur
/dev/mapper/volume0-rac
reiserfs 5,0G 571M 4,5G 12% /
tmpfs tmpfs 1015M 0 1015M 0% /dev/shm
/dev/mapper/volume0-home
reiserfs 30G 19G 12G 61% /home
/dev/mapper/volume0-mnt
reiserfs 60M 33M 28M 54% /mnt
/dev/mapper/volume0-var
reiserfs 30G 12G 19G 39% /var
monserveur:~$pvdisplay
--- Physical volume ---
PV Name /dev/md0
VG Name volume0
PV Size 148,08 GB / not usable 0
Allocatable yes
PE Size (KByte) 4096
Total PE 37909
Free PE 21126
Allocated PE 16783
PV UUID hvOg9r-IsK3-INfj-6LvE-RKrr-LBjT-L6neqf
monserveur:~$cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hda1[0] hdc1[1]
155276160 blocks [2/2] [UU]
unused devices:
monserveur:~$
Comme tu peux le voir ici "/boot" est sur "/dev/mapper/volume0-rac" qui est une partoch du volume group "volume0" qui est composé seulement par le physical volume "/dev/md0". Ce dernier étant composé de "/dev/hda1" et "/dev/hdc1" en RAID1.
Par contre pour installer cela j'ai fait une debian bootstrappée il y a longtemps tu dois surement faire cela de manière plus sympa aujourd'hui...
Cordialement.-
[^]Re: Compatibilité
Posté par rdem (page perso, ) le 23/10/2006 à 15:35. (lien). Évalué à 1.Je confirme qu'au moins un boot loader fonctionne avec du raid.
Dans mon cas il me semble que c'est le grub (plus sur à 100% mais 90%, c'est celui que je préfère), le serveur as été installé par la net install de debian il y as un an et depuis je n'y touche plus (serveur de données).
Il y as un an on avait donc plus besoin de passer par du bootstrap pour installer un système raid ;)
Cordialement,-
[^]Re: Compatibilité
Posté par Loic Pefferkorn (page perso, ) le 30/10/2006 à 08:16. (lien). Évalué à 1.J'ai dû louper quelque chose alors. Serait-il possible de connaitre les version de grub et de lilo que vous utilisez ?
-
[^]Re: Compatibilité
Posté par rdem (page perso, ) le 31/10/2006 à 16:02. (lien). Évalué à 1.grub --version
grub (GNU GRUB 0.95) (debian SARGE)
./TestHDD.sh
/dev/md0:
Version : 00.90.01
Creation Time : Wed Jun 1 16:44:44 2005
Raid Level : raid1
Array Size : 96256 (94.02 MiB 98.57 MB)
Device Size : 96256 (94.02 MiB 98.57 MB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Tue Oct 31 06:26:15 2006
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : ad7be4b8:7ded47c3:92a0265e:a79fa7f2
Events : 0.2374
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
/dev/md1:
Version : 00.90.01
Creation Time : Wed Jun 1 16:44:50 2005
Raid Level : raid1
Array Size : 4883648 (4.66 GiB 5.00 GB)
Device Size : 4883648 (4.66 GiB 5.00 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Tue Oct 31 16:59:57 2006
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : cae0db74:740c4b48:64ca4ba8:6d683c73
Events : 0.19169346
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 18 1 active sync /dev/sdb2
/dev/md2:
Version : 00.90.01
Creation Time : Wed Jun 1 16:45:01 2005
Raid Level : raid1
Array Size : 73240192 (69.85 GiB 75.00 GB)
Device Size : 73240192 (69.85 GiB 75.00 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 2
Persistence : Superblock is persistent
Update Time : Tue Oct 31 16:59:56 2006
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : 0332a1b7:3842237d:5f9cc22a:273ff06e
Events : 0.12020739
Number Major Minor RaidDevice State
0 8 5 0 active sync /dev/sda5
1 8 21 1 active sync /dev/sdb5
/dev/md3:
Version : 00.90.01
Creation Time : Wed Jun 1 16:45:05 2005
Raid Level : raid0
Array Size : 2264960 (2.16 GiB 2.32 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 3
Persistence : Superblock is persistent
Update Time : Wed Jun 1 16:45:05 2005
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Chunk Size : 64K
UUID : e1067148:5833aa5d:88e4db8c:0fedba5d
Events : 0.1
Number Major Minor RaidDevice State
0 8 6 0 active sync /dev/sda6
1 8 22 1 active sync /dev/sdb6
df -h
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/md1 4,6G 631M 3,8G 15% /
tmpfs 253M 4,0K 253M 1% /dev/shm
/dev/md0 89M 6,4M 77M 8% /boot
/dev/md3 2,2G 38M 2,2G 2% /tmp
/dev/md2 70G 55G 16G 78% /var
cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>
proc /proc proc defaults 0 0
/dev/md1 / ext3 defaults,errors=remount-ro 0 1
/dev/md0 /boot ext2 defaults 0 2
/dev/md3 /tmp reiserfs defaults 0 2
/dev/md2 /var reiserfs defaults 0 2
/dev/sda3 none swap sw 0 0
/dev/sdb3 none swap sw 0 0
/dev/hdb /media/cdrom0 iso9660 ro,user,noauto 0 0
#usb
/dev/sdc1 /mnt/usb vfat rw,user,users,noauto,umask=000 0 0
-
[^]Re: Compatibilité
Posté par Couderc Romain (page perso, ) le 03/11/2006 à 09:35. (lien). Évalué à 1.Bien sur. Voici ma version de lilo:
monserver:~#lilo -V
LILO version 22.6.1 (Debian GNU/Linux)
monserver:~#
et ma config de lilo est:
#
boot=/dev/hda
#
root=/dev/mapper/volume0-rac
#
#
default=Linux
#
image=/vmlinuz
label=Linux
read-only
initrd=/initrd.img
#
image=/vmlinuz.old
label=LinuxOLD
read-only
optional
initrd=/initrd.img.old
-
-
-
-
-
-
-
[+] est pourquoi pas
utiliser ZFS (de SUN) ? ce FS semble très puissant. J'imagine que la question a déjà été posé...
-
[^]Re: est pourquoi pas
Cette page a été générée par Templeet en 0.2277s (dont 0.0375 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.