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.
Aller plus loin
- Linux-Watch (2 clics)
- Est-il temps de travailler sur Ext4 ? (4 clics)
- Il est temps de travailler sur Ext4 ! (3 clics)
- Article sur KernelTrap (3 clics)
# La journalisation n'a rien à voir avec la récupération de données perdue
Posté par Christophe Merlet (site web personnel) . Évalué à 10.
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 (site web personnel) . Évalué à 1.
[^] # Re: La journalisation n'a rien à voir avec la récupération de données pe
Posté par iug . Évalué à 3.
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 phoenix (site web personnel) . Évalué à 6.
[^] # Re: La journalisation n'a rien à voir avec la récupération de données pe
Posté par nicodache . Évalué à 1.
parce qu'après tout, c'est ce qui bouge le plus (outre la swap)
bon, c'est vrai que ca perd directement de l'intérêt :D
[^] # Re: La journalisation n'a rien à voir avec la récupération de données pe
Posté par iug . Évalué à -3.
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 . Évalué à 2.
Ils journalisent quoi ?
Ext3 :
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 . Évalué à -2.
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 . Évalué à 2.
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
Posté par Jérôme Pinot (site web personnel) . Évalué à 8.
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 . Évalué à 8.
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 (site web personnel) . Évalué à 6.
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 . Évalué à 6.
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 . Évalué à 1.
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...
Posté par _alex . Évalué à 5.
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 . Évalué à 5.
Ce n'est pas la même chose que l'option de montage « reservation » pour l'ext3?
[^] # Re: Et moi...
Posté par IsNotGood . Évalué à 2.
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 . Évalué à 1.
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 ?
Posté par Gael Tessier . Évalué à 5.
--
http://www.tessier-net.org
[^] # Re: Performances ?
Posté par iug . Évalué à 8.
Dans de rare cas c'est moins bien que ext2, sinon c'est assez bourin.
# pardon ?
Posté par towanda . Évalué à 7.
/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 (site web personnel) . Évalué à 5.
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 . Évalué à 2.
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 (site web personnel) . Évalué à -2.
Ils sont gros tes backups ...
[^] # Re: pardon ?
Posté par towanda . Évalué à 4.
[^] # Re: pardon ?
Posté par theocrite (site web personnel) . Évalué à 8.
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
# Ca pour une nouvelle ...
Posté par dinomasque . Évalué à 8.
BeOS le faisait il y a 20 ans !
[^] # Re: Ca pour une nouvelle ...
Posté par Nÿco (site web personnel) . Évalué à 7.
[^] # Re: Ca pour une nouvelle ...
Posté par zx81 . Évalué à -1.
Même avec dar ?
[^] # Re: Ca pour une nouvelle ...
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ca pour une nouvelle ...
Posté par IsNotGood . Évalué à 1.
rsync support les attributs étendus.
Ça couvre aussi selinux.
# traduction
Posté par Laurent J (site web personnel, Mastodon) . Évalué à -8.
(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 (site web personnel) . Évalué à 9.
[^] # Re: traduction
Posté par Christophe Merlet (site web personnel) . Évalué à -6.
[^] # Re: traduction
Posté par Bayet Thierry . Évalué à 5.
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...
[^] # Re: traduction
Posté par Christophe Merlet (site web personnel) . Évalué à -4.
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 . Évalué à 9.
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
[^] # Re: traduction
Posté par towanda . Évalué à 10.
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
Posté par gaolinn . Évalué à 1.
[^] # Re: traduction
Posté par phentex . Évalué à -4.
[^] # Re: traduction
Posté par zerchauve . Évalué à -4.
allez zou.
# est pourquoi pas
Posté par thomas . Évalué à 1.
[^] # Re: est pourquoi pas
Posté par vrm (site web personnel) . Évalué à 4.
[^] # Re: est pourquoi pas
Posté par Vivi (site web personnel) . Évalué à 4.
[^] # Re: est pourquoi pas
Posté par Gabriel Linder . Évalué à 4.
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 . Évalué à 1.
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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: et pourquoi pas
Posté par Rémi Hérilier . Évalué à 4.
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 (site web personnel) . Évalué à 3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# Compatibilité
Posté par Amand Tihon (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 1.
[^] # Re: Compatibilité
Posté par Sylvain Briole (site web personnel) . Évalué à 4.
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 (site web personnel) . Évalué à 3.
[^] # Re: Compatibilité
Posté par Couderc Romain . Évalué à 6.
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 P . Évalué à 2.
[^] # Re: Compatibilité
Posté par Couderc Romain . Évalué à 2.
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 . Évalué à 1.
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 P . Évalué à 1.
[^] # Re: Compatibilité
Posté par rdem . Évalué à 1.
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 . Évalué à 1.
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
Posté par thomas . Évalué à -7.
[^] # Re: est pourquoi pas
Posté par plic . Évalué à 10.
Oui, par toi un peu plus haut :-)
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.