Supporté ou pas ? Ben oui, il l'est, depuis les dernières présorties du 2.4.1.
Vous pouvez donc vous compiler le 2.4.1-pre7 (dernière version, 15-Jan-200) pour expérimenter tout celà.
Je me demande tout de même quels sont les avantages concrets de ce dernier. J'ai pu lire qu'il était plus que rapide en cas de redémarrage intenpestif de la machine mais plus lent en perf générale qu'ext2. Qu'en est-il ?
Si c'est le cas, quel intéret, pour une machine comme la mienne qui ne démarre qu'une fois par jour...?
Aller plus loin
- le patch (pre7) en bz2 (1 clic)
- le patch (pre7) en gz (1 clic)
- HOWTO patcher (ben quoi ?) (4 clics)
# tu le montes avec noatime option eh patate!
Posté par Anonyme . Évalué à 0.
zobi:~# uname -a
Linux zobi 2.4.1-pre2 #1 Fri Jan 12 16:47:29 CET 2001 i586 unknown
zobi:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/hda5 / ext2 defaults,errors=remount-ro,noatime 0 1
/dev/hda2 none swap sw 0 0
proc /proc proc defaults 0 0
/dev/cdrom /cdrom iso9660 defaults,noexec,ro,user,noauto 0 0
/dev/hda1 /dosc vfat rw,errors=remount-ro 0 0
/dev/hda6 /home1 reiserfs defaults,noatime 0 0
#memory stick
/dev/sda1 /msusb auto defaults,errors=remount-ro,user,noauto 0 0
#floppy
/dev/sdb /floppy auto defaults,errors=remount-ro,user,noauto 0 0
#/dev/fd0 /floppy auto defaults,errors=remount-ro,user,noauto 0 0
[^] # Re: tu le montes avec noatime option eh patate!
Posté par Ramón Perez (site web personnel) . Évalué à 0.
(PS : m'étonne pas que ta machine s'appelle zobi, tiens ;-)
[^] # Re: tu le montes avec noatime option eh patate!
Posté par Anonyme . Évalué à -1.
Linux chaos 2.4.1-pre2 #1 ven jan 12 14:57:49 CET 2001 i686 unknown
je t'ai grillé de deux heures, na !
oui bon ok...
[^] # Re: tu le montes avec noatime option eh patate!
Posté par Fabien Seisen . Évalué à 1.
petit joueur, ton / est meme pas en reiserfs ...
PS: tu nous diras quand tu auras paumé ton /home1 ?
# j'avais oublié de préciser
Posté par Anonyme . Évalué à 0.
les patchs sont contre le 2.4.0
les 2.4.1-pre ne sont distribué que sous forme de patch.
# Avantage
Posté par Ramón Perez (site web personnel) . Évalué à 1.
(PS : est-ce vous Messire, qui postoyez en langue françoyse dans la tribune ?)
[^] # Re: Avantage
Posté par Infernal Quack (site web personnel) . Évalué à 1.
Dans notre école, on a un serveur de fichier qui plante tout le temps (tous les 2 jours mini). Eh bien je serais super heureux si il était sur ReiserFS moi ;-)
Sinon, pour les perfs je peux pas trop dire vu que j'ai upgradé ma mémoire en passant de ext2 à ReiserFS :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Avantage
Posté par Anonyme . Évalué à 0.
[^] # Re: Avantage
Posté par Infernal Quack (site web personnel) . Évalué à 1.
Moi je teste pas mal de trucs (zapping, xawtv, aviplay, ...) qui font planter mon ordi.
Le dernier en date : "festival", maintenant il marche gràce à alien (.deb->.rpm)
A moi les fortunes lu automatiquement au démarrage ;-)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Avantage
Posté par Anonyme . Évalué à 0.
[^] # Re: Avantage
Posté par Anonyme . Évalué à 0.
[^] # Re: Avantage
Posté par bmc . Évalué à 1.
[^] # Re: Avantage
Posté par Infernal Quack (site web personnel) . Évalué à 1.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Avantage
Posté par j . Évalué à 1.
C'est aussi un bon moyen d'éviter les fsck en ext2 !
-Jedi.
[^] # Re: Avantage
Posté par bmc . Évalué à 1.
[^] # Re: Avantage
Posté par Infernal Quack (site web personnel) . Évalué à 1.
Sauf que ça marche pas si ton clavier freeze :(
PS : Quand on compile le kernel, c'est la dernière question :p
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Cf au dessus pour Sysrq
Posté par Anonyme . Évalué à 0.
[^] # Re: Avantage
Posté par _UMASS_ . Évalué à 1.
[^] # Re: Avantage
Posté par Anonyme . Évalué à 0.
Le truc mnémotechnique pour la séquence est
"Raising Skinny Elephants Is Utterly Boring"
plus de détail ici:
http://www.mandrakeuser.org/admin/arecov.html#top(...)
[^] # Re: Avantage
Posté par Anonyme . Évalué à 0.
- k (petit) kill tous les process
- i (moyen) kill ----------------
- l (gros) kill ----------------
- r reboot le systeme
Ce sont des racourcies noyaux. Le mieux quand meme est de demander a son voisin de donner un coup de main (/ de doigt). :)))
bobby
[^] # Re: Avantage
Posté par G. R. (site web personnel) . Évalué à 1.
>et les ctrl+alt+F<1-6> ne répondent pas, je me
>demande ce qu'il reste à faire ...
Et les magic keys ?
C'est très pratique justement dans ces cas là.
Ceci dit, tu le plantes souvent X11 ?
[^] # Re: Avantage
Posté par bmc . Évalué à 1.
>> Ceci dit, tu le plantes souvent X11 ?
Pas tous les jours, mais ça arrive suffisamment souvent pour que ça me mettes sur les nerfs. Pour les adeptes des chiffres, je dirais qu'en moyenne ça arrive 3 fois par mois.
[^] # Re: Avantage
Posté par Anonyme . Évalué à 0.
[^] # Re: Avantage
Posté par Croweye . Évalué à 1.
[^] # Re: Avantage
Posté par Infernal Quack (site web personnel) . Évalué à 1.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Avantage
Posté par MetalX . Évalué à 1.
Sur ma Woody, ben comme elle freeze assez souvent :( , ca fait perdre pas mal de temps ...
[^] # Re: Avantage
Posté par Anonyme . Évalué à 0.
[^] # Re: Avantage
Posté par bmc . Évalué à 1.
Si j'ai bien compris, l'architecture est novatrice en ce sens que les arbres du système de fichiers ne contiennent plus seulement les noms des fichiers mais également les fichiers eux-mêmes.
Quant à savoir l'impact que ça a sur les performances...
ReiserFS est séduisant à priori, mais en lisant la nouvelle sur slashdot, j'ai pu lire des commentaires faisant état de la puissance de XFS, le système de fichiers journalisés de SGI. Leur projet ne semble pas aussi mature, mais il a l'air beaucoup plus prometteur.
Pour plus de renseignements sur reiserfs : http://www.namesys.com(...)
[^] # Re: Avantage
Posté par Anonyme . Évalué à 0.
Bref.. mieux vaut attendre un bon support xfs a mon avis..
[^] # Re: Avantage
Posté par j . Évalué à 1.
Mais aujourd'hui, ReiserFS est beaucoup plus stable et avancé. Et demain, les objectifs de l'un et de l'autre ne sont pas les memes.
[^] # Re: Avantage - Désavantages...
Posté par Anonyme . Évalué à 0.
ext3 est pas mal en ce sens, et malgré son numéro de release inquiétant il est bien stable parait t'il.
Du côté des perf, il parait que le plus rapide est reiserfs, que xfs est pour le moment assez lent (mais avec des caractéristiques impréssionnantes au niveau de la taille du fs, des fichiers...)
[^] # Re: Avantage - Désavantages...
Posté par j . Évalué à 1.
-Jedi.
[^] # Re: Avantage - Désavantages...
Posté par Babou . Évalué à 1.
[^] # Re: Avantage - Désavantages...
Posté par j . Évalué à 1.
Ceci pour éviter un coup dans le dos qu'on lui a fait dans ses débuts.
[^] # Re: Avantage
Posté par Anonyme . Évalué à 0.
Les fichiers journalises n'empeche absolument pas de perdre des donnees. On juste la garantie de l'integrite du systeme de fichiers.
Enfin gros desavantages, j'ai entendu dire qu'il ne supportait pas les quotas. Et ca, en environnement de production, c'est assez problematique.
[^] # Re: Avantage
Posté par Anonyme . Évalué à 0.
Et effectivement, la journalisation de ReiserFS ne garantie que l'intégrité de la structure des données, pas des données elles-memes. C'est pareil pour XFS et la plupart des systèmes journalisés pour des raisons évidentes de performances.
Ext3 place dans son journal aussi bien les modifications effectuées sur les méta-données que celles effectuées sur les données. C'est ce qui explique sa lenteur (et c'est beaucoup plus simple de logger les deux plutot qu'uniquement les méta-données) .
Pour en perdre le moins possible, il faut effectuer toutes les écritures de façon synchrone. Désactiver tous les caches, y compris celui du disque dur.
D'une part les performances ainsi obtenues sont minables, d'autre part, il n'y a aucune intégrité au niveau des applications. Si ça plante lorsque l'on était en train d'écrire un fichier, qu'est-ce-qui prouve qu'au prochain reboot, le fichier est encore exploitable vu qu'il en manque un bout ? Quelque soit le filesystem, le problème est le meme : quand il n'y a plus de courant electrique (ou un plantage du noyau), difficile d'écrire quoi que ce soit sur le disque dur !
Actuellement, la seule solution est de gérer ça au niveau applicatif. Par exemple en utilisant une base de données munie de transactions (pitié, pas de trolls sur MySQL qui supporte maintenant très bien les transactions avec BerkeleyDB), ou en ne faisant que des opérations atomiques.
-Jedi.
# Ca marche
Posté par Yves BAILLY . Évalué à 1.
Personnellement j'utilise ReiserFS depuis la Mandrake 7.1, et je tourne actuellement sous Mandrake 7.2 également avec ReiserFS.
Constat (assez subjectif, je n'ai pas de chiffres) : au début, cela me paraissait un peu plus lent qu'ext2. Maintenant, honnêtement, je ne vois pas vraiment la différence, la compilation du kernel ne me prend pas plus de temps.
Par contre, il y a 1/2 heure, mon chat a éteint la prise multiple... Hé bien le reboot est en effet extrèmement rapide, et a priori aucun fichier n'a été perdu. Même pour une machine qui normalement ne démarre qu'une fois par jour, c'est appréciable, et surtout tranquilise l'esprit.
[^] # Re: Ca marche
Posté par Ramón Perez (site web personnel) . Évalué à 1.
http://www.bitboost.com/pawsense/index.html(...)
Bon c'est un logiciel payant sous windows, mais le concept est quand même génial !
[^] # Re: Ca marche
Posté par Infernal Quack (site web personnel) . Évalué à 1.
L'ordi il aboit pour faire fuire le chat ? ;)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Ca marche
Posté par Ramón Perez (site web personnel) . Évalué à 1.
[^] # Re: Ca marche
Posté par GuiJEmonT . Évalué à 1.
[^] # Re: Ca marche
Posté par Anonyme . Évalué à 0.
[^] # Re: Ca marche
Posté par j . Évalué à 1.
Eh oui... la relecture du journal ne peut être parfaite : si on était en train de réorganiser un bout de l'arbre au moment du crash, il se peut que des blocs attribués (d'après la liste des blocs libres -bitmap-) ne fassent pourtant plus partie de l'arbre... Voilà pourquoi ReiserFS n'a aucun intéret sous Zindoz !
-Jedi.
[^] # Re: Ca marche
Posté par jpph . Évalué à 1.
# Performances
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
C'est particulièrement efficace sur les répertoires dont le nombre de fichiers est très grand. Exemples: /usr/bin, usr/share/icons...
Le système de journalisation permet de ramener le laborieux fsck de ext2 à 1 à 2 secondes par user que que soit la taille du disque. C'est donc très utile sur les gros volumes, à mon avis, il faut être fou pour s'en priver.
Seul petit problème, LILO ne sait pas booter sur Reiserfs. Alors, pour contourner, prévoyez /root (10Mo) en ext2, et le reste en Reiserfs (sauf swap:).
J'ai déjà à mon actif plusieurs installations de Mandrake 7.2 utilisant cette technique. Sans problème. Je vais ce soir en refaire une autre, pour moi cette fois !
[^] # Re: Performances
Posté par Anonyme . Évalué à 0.
la copie de fichier ? la lecture ?
[^] # Re: Performances
Posté par Infernal Quack (site web personnel) . Évalué à 1.
???
Je doit être fou mais chez moi toute ma mandrake est sur du reiserfs, y compris /
Je suis pas chez moi donc je peux pas faire de "cat /etc/fstab" et "cat /etc/lilo.conf" pour vous le prouver :-)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Performances
Posté par PinG . Évalué à 1.
[^] # Re: Performances
Posté par Infernal Quack (site web personnel) . Évalué à 1.
sauf si on fait une install "expert" ou on peut mettre lilo (ce que j'ai fait)
Perso, lilo m'a l'air plus simple à configure que grub.
Comment on dit "linux s" ou "linux init=3" en grub ?
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Performances
Posté par Anonyme . Évalué à 0.
[^] # Re: Performances
Posté par PinG . Évalué à 1.
[^] # Re: Performances
Posté par Anonyme . Évalué à 0.
Dans le fichier qui contient le menu ( /boot/grub/menu.lst en général)
kernel /boot/vmlinuz-2.4.0 X root=/dev/sda1 ro
[^] # Re: Performances
Posté par Olivier CIRET . Évalué à 1.
[^] # Re: Performances
Posté par Infernal Quack (site web personnel) . Évalué à 1.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Performances
Posté par Anonyme . Évalué à 0.
Mais XOSL peut s'installer depuis un DOS quelconque (DrDOS, MSDOS ou...FreeDOS, donc j'vois pas l'pbm...
[^] # Re: Performances
Posté par Anonyme . Évalué à 0.
[^] # Re: Performances
Posté par Anonyme . Évalué à 0.
[^] # Re: Performances
Posté par Anonyme . Évalué à 0.
[^] # Re: Performances
Posté par Ramón Perez (site web personnel) . Évalué à 1.
[^] # Re: Performances
Posté par PinG . Évalué à 1.
[^] # Re: Performances
Posté par Pierric -=#' . Évalué à 1.
[^] # Re: Performances
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
[^] # Re: Performances
Posté par PinG . Évalué à 1.
[^] # Re: Performances
Posté par j . Évalué à 1.
[^] # Re: Performances
Posté par »-(¯`v´¯)-» . Évalué à 1.
ardass $ mount
/dev/hda5 on / type reiserfs (rw)
none on /proc type proc (rw)
/dev/hda2 on /boot type reiserfs (rw,notail)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hda8 on /home type reiserfs (rw)
/dev/hda6 on /tmp type reiserfs (rw)
/dev/hda9 on /usr/local type reiserfs (rw)
/dev/hda7 on /var type reiserfs (rw)
est lilo march super bien
[^] # Re: Performances
Posté par Anonyme . Évalué à 0.
[^] # Re: Performances
Posté par Christophe BAEGERT . Évalué à 1.
mkinitrd /boot/initrd-2.2.18-img 2.2.18
il faut evidemment compiler le kernel avec reiserfs en module, et le support de RAMdisque et de initrd.
[^] # Re: Performances
Posté par Sebastien . Évalué à 1.
Ah bon, moi je prefere / ou /boot mais bon...
# ben....
Posté par Anonyme . Évalué à 0.
D'aprés les benchs qu'ils ont réalisés, la différence apparait dans certains cas, mais elle est tellement faible, que je ne vois pas pourquoi on ne profiterait pas des bienfaits d'un JSF.
http://www.namesys.com/bens.html(...)
[^] # Re: ben....
Posté par Anonyme . Évalué à 0.
Pour les perfs je ne me suis pas amusé à faire des comparaisons chiffrées mais j'ai quand même l'impression que la copie et le déplacement de fichiers (de toutes tailles) est plus (voire même beaucoup plus) rapide, y compris depuis partition ext2 ou fat32.
[^] # Re: ben....
Posté par j . Évalué à 1.
[^] # Re: ben....
Posté par _UMASS_ . Évalué à 1.
# système de fichiers journalisés
Posté par Anonyme . Évalué à 0.
Honnêtement pour un particulier, où les redémarrages sauvages sont rares, je ne vois pas trop l'intérêt d'un tel système de fichiers (surtout s'il n'est pas stable et forcément moins performant en écriture).
C'est intéressant pour un serveur qui ne peut pas se permettre de rebooter en 15 min.
[^] # Re: système de fichiers journalisés
Posté par Anonyme . Évalué à 0.
[^] # Re: système de fichiers journalisés
Posté par j . Évalué à 1.
Pour convertir au nouveau format, montez vos partitions avec l'option "conv" . Dès ce moment, les NOUVEAUX fichiers seront au NOUVEAU format. Bref, pour tout convertir : backup et restauration totale....
L'intéret majeur du nouveau format est le support des fichiers dont la taille est sur 64 bits (hum, en fait 60 bits... c'est une limitation de la VFS pas de ReiserFS, mais c'est déjà gigantesque) .
-Jedi.
[^] # Re: système de fichiers journalisés
Posté par Anonyme . Évalué à 0.
[^] # Particulier == redemarrage sauvage RARE
Posté par reno . Évalué à 1.
Chez moi, je joue beaucoup plus avec des trucs "louches" qu'au boulot.
Et quand X freeze, comme la machine n'est pas en reseau --> reboot sauvage (quand les controles magiques ne fonctionnent plus).
# REISERFS - Premiere partie
Posté par j . Évalué à 5.
*** POURQUOI A ETE CREE REISERFS ? ***
Lorsque Monsieur Reiser, Hans de son prénom, étudiait à Berkeley, il a eu
comme tous ses petits camarades, une thèse de fin d'étude à rendre. Et en
guise de sujet, il a choisi les filesystems. Après avoir étudié un peu tout
ce qui avait été fait dans le domaine, il s'est appercu qu'ils reposaient
tous sur les memes concepts archaiques :
- Les données sont organisées dans des fichiers, situés dans une
arborescence de répertoires. Ces données se présentent sous la forme d'un
triste ensemble linéaire.
- On peut ajouter des données à la fin d'un fichier, écrire par dessus
celles qui sont déjà présentes ou tronquer la fin d'un fichier. C'est tout,
aucune autre opération.
A cause de ces deux points, programmer des applications est souvent un
casse-tête. Les applications manipulent des données. Des données
structurées. Des données qui ont des liens entre elles. Des données que l'on
peut trafiquer dans tous les sens en mémoire. Mais dès l'instant où il faut
les sauvegarder, les charger, les indexer sur disque, bref... les placer
dans un système de fichiers, c'est la galère. Il faut trouver un moyen de
linéariser toutes ces structures, définir une nouvelle représentation qui
n'a aucun rapport avec celle en mémoire et qui est à des années lumière
d'une idéale représentation théorique. Prenons un exemple simple : une liste
chaînée. En mémoire, c'est simple, hop, hop, hop, chaque élément est composé
d'un champs qui pointe vers un autre élément. Maintenant effectuons la même
chose dans un fichier... oh-oh... ça engendre déjà quelques complications,
surtout si toutes ces données sont dynamiques... Il va falloir commencer à
se creuser la tête pour imaginer un "format de données", cette chose qui
représente la principale source d'incompatibilités et de soucis entre les
logiciels...
Pour limiter la casse, on peut passer par des moteurs de bases de données,
qui nous présentent une interface un peu moins limitée que
open/fseek/read/write/ftruncate ... Ces moteurs vont trafiquer des données
présentées sous une certaine forme pour finalement les recoder autrement sur
disque dur, au prix d'une charge processeur et disque incroyables pour lire
quelques malheureux octets. Il existe aussi maintenant des langages tels que
XML qui prouvent bien le manque qui existe pour la représentation de données
structurées sur un disque dur.
Plutot que d'employer des artifices ou de demander aux programmeurs
d'adapter leurs applications aux limitations d'un filesystem... pourquoi ne
pas voir les choses autrement ?
Par exemple, au lieu d'accéder à des données à l'aide d'un chemin, pourquoi
n'y accederait-on pas par mots-clefs ? Si notre application représente
facilement des arbres en mémoire, pourquoi ne serait-il pas possible d'avoir
un système de fichiers adapté à la structure que l'on utilise ?
L'idée serait par exemple d'avoir un système de plug-ins, pour que le
filesystem s'adapte aux applications. La programmation devient beaucoup plus
simple, et les performances sont optimales. Cela permet au passage de mettre
les traditionnelles bases de données à la poubelle dans bien des cas.
Hans Reiser a continué sa reflexion sur l'organisation des fichiers dans les
principaux filesystems. Bizarre... une division en 'blocs', un index et une
liste de blocs libres, tout ça localisé dans un coin (tout au début du
disque pour la plupart, en plein milieu pour HPFS) ... les données
elles-memes réparties un peu n'importe comment sur le disque, là où il y a
de la place...)
C'est bizarre... Pourquoi ne pas mettre les méta-données à coté des données
concernées ? Ce serait plus simple et plus rapide. Pourquoi cette notion de
blocs ? Ne pourrait-on pas placer données et métadonnées dans un seul bloc,
voir plusieurs petits fichiers dans un meme bloc ? On gagnerait du coup de
l'espace disque et des performances (un seul secteur à lire pour plusieurs
fichiers, méta-données et contenu) . Apparemment, tous les filesystems
traditionnels ont négligé les petits fichiers.
Un disque dur est principalement mécanique. Sa pauvre petite tete n'a pas
une vitesse infinie. Pourquoi n'essayerait-on pas de placer les données au
mieux pour en limiter les déplacements ? Quitte à déplacer et à réorganiser
ces données sur le disque pour que, dès qu'un meilleur emplacement pour des
données soit disponible, il soit utilisé ?
Autre reflexion... Se balader dans de gros fichiers prend du temps. Car un
gros fichier n'est que très rarement linéaire sur le disque... il est en
plusieurs morceaux... Mais... Pourquoi ne pas organiser les données (et pas
seulement les indexes) sous forme d'un B-tree ? Il serait alors toujours
aussi rapide d'accéder à n'importe quel point d'un fichier. Ah oui il faut
rééquilibrer l'arbre régulierement pour que ça reste un b-tree... C'est pas
si évident que ça à coder...
En fait toutes ces idées sont excellentes. Repartir sur de nouvelles bases
(après tout très logiques) pour un filesystem est une aventure passionnante.
Mais c'est un travail énorme. Le pauvre petit Hans ne pouvait pas faire ça
tout seul. Alors, une fois son diplôme en poche, il a fondé Namesys Venture,
convaincu quelques investisseurs de lui donner du pognon pour commencer...
Et embaucher des programmeurs pour travailler sur le projet.
Le moteur de recherche Ecila a été assez rapidement intéressé pour
sponsoriser le projet, en particulier pour une indexation par mots-clefs. La
société Namesys est née. Elle a ensuite changé de nom pour passer à ReiserFS
à cause de quelques escrocs qui ont quitté la barque en cours de route.
Bon, dans le prochain épisode, je tenterai de répondre aux questions
suivantes : quel intéret aujourd'hui, face à Ext2, Ext3, Tux2, XFS et JFS.
Et dans le dernier épisode : le futur.
-Jedi.
[^] # Re: REISERFS - Premiere partie
Posté par bmc . Évalué à 1.
Très bon commentaire, merci.
[^] # Re: REISERFS - Premiere partie
Posté par Anonyme . Évalué à 0.
Super !
La suite ! La suite !
[^] # Re: REISERFS - Premiere partie
Posté par Ramón Perez (site web personnel) . Évalué à 1.
Merci.
[^] # Re: REISERFS - Premiere partie
Posté par Anonyme . Évalué à 0.
[^] # Re: REISERFS - Premiere partie
Posté par gabuzo . Évalué à 1.
[^] # Re: REISERFS - Premiere partie
Posté par jp martin . Évalué à 1.
# utilitaire
Posté par Damien Sandras (site web personnel) . Évalué à 1.
Donc comment fait-on pour installer sa Debian entièrement sur ReiserFS ?
(Sans trop de chipotage)
[^] # Re: utilitaire
Posté par bmc . Évalué à 1.
Tu installes Debian avec le minimum de paquets sur une partition de 200 Mo disons. Puis tu te fais des partitions ReiserFS, tu recompiles un noyau 2.4.0-pre7 (ou tu patches un autre noyau avec le patch de namesys), tu changes quelques paramètres (fstab, lilo, etc...) puis tu rebootes et formates la partition de 200 Mo. J'ai bon ?
[^] # Re: utilitaire
Posté par j . Évalué à 1.
[^] # Re: utilitaire
Posté par bmc . Évalué à 1.
;-)
[^] # Re: utilitaire
Posté par Damien Sandras (site web personnel) . Évalué à 1.
mais bon, je vais devoir faire ainsi alors, je sauverai tout mon système actuel ailleurs...
Pas envie de reinstaller, <TROLL> debian, c'est pas fait pour ca </TROLL>
[^] # Re: utilitaire
Posté par bmc . Évalué à 1.
[^] # Re: utilitaire
Posté par Pierric -=#' . Évalué à 1.
est-ce qu'il tiens dans la main ?
[^] # Re: utilitaire
Posté par j . Évalué à 1.
-Jedi.
[^] # Re: utilitaire
Posté par alex boissy . Évalué à 1.
# REISERFS : Episode 2
Posté par j . Évalué à 5.
*** REISERFS AUJOURD'HUI ***
Les performances des versions actuelles de ReiserFS dépendent énormément de
ce que l'on en fait. Pour les accès en lecture, c'est en général beaucoup
plus rapide qu'Ext2, surtout si l'on s'amuse à faire des déplacement un peu
partout dans les fichiers. En écriture... ça dépend. C'est souvent comparable
à Ext2, mais la journalisation ajoute quelques limitations. Tout d'abord,
les appels à fsync() ou fsyncdata() sont lents. Car actuellement, appeler
ces fonctions conduit à une synchronisation complete du journal. Toutes les
transactions sont réalisées, y compris celles concernant d'autres fichiers
que celui sur lequel on appelle fsync(). Pour cette raison, des logiciels
comme les serveurs de mail et les bases de donées sont plus lents en mise à
jour avec ReiserFS que Ext2. Solution radicale pour accélérer tout ça :
enlever la journalisation.
ReiserFS est aussi très rapide pour accéder à des répertoires contenant des
millions de fichiers. En effet, tous les noms sont indexés dans une table de
hash pour les repérer rapidement (c'est ça, le R5 hash, TEA hash, etc...) .
C'est très intéressant, car pour une application genre 'forum' par exemple,
il n'y a aucune honte à coller tous les messages dans un répertoire, un
fichier par message. Ca ne pose aucun problème, c'est simple à coder et
c'est très rapide. L'Ext2 tire très vite la langue dans des conditions
similaires.
Et pour encore plus de performances dans une telle situation, on peut
désormais accéder aux fichiers directement à partir de leur numéro d'inode.
Aucune recherche n'est donc effectuée, l'accès est immédiat. Ce sont des
travaux qui ont été réalisés pour l'optimisation de Squid, mais d'autres
applications peuvent en tirer partie.
ReiserFS a un autre intéret : il peut vous faire gagner de l'espace disque
(voir l'épisode 1 - plusieurs choses dans un même bloc) . Ce sont les
'tails'. Prenez une partition ext2, convertissez-là en ReiserFS et ... oh
miracle, vous avez environ 5% de place en plus qu'avant. Tout dépend de la
taille des fichiers, mais tous les petits fichiers de config y gagnent.
D'un autre coté, l'écriture (et surtout le fait d'y ajouter des données)
dans ces fichiers 'compactés' est plus lente qu'en temps normal. Vous pouvez
accélérer les choses en montant vos filesystems ReiserFS avec l'option
'-notail'.
Sinon, puisque quelqu'un parlait d'un problème avec Lilo... Le problème
venait justement de l'histoire des tails. Lilo a du mal à charger des données
qui débutent en plein milieu d'un secteur. Un appel système a donc été rajouté
sur les versions récentes de ReiserFS pour 'décompacter' un fichier. Cet
appel est utilisé sur les versions récentes de Lilo. Votre partition /boot
(ou /) peut donc utiliser les tails sans problème, pensez juste à mettre à
jour votre Lilo.
Quid des autres filesystems....
Ext3 : malgré son numéro de version faiblard, il est assez stable. Mais très
lent. Trop lent même. Intéret : on peut migrer de ext3 vers ext2 et
inversement facilement.
Tux2 : instable, encore beaucoup de travail à y apporter, mais le concept
est intéressant et l'auteur bosse bien dessus.
XFS et JFS : quelqu'un qui a testé longuement les derniers snapshots peut
nous en parler ?
Quoi qu'il en soit, le meilleur filesystem "traditionnel" (organisation
linéaire pour les applications, pas de plug-ins) est à mon avis celui de
Netapp. Il a d'ailleurs été programmé par l'équipe qui avait pondu le XFS à
l'époque. Mais je doute qu'il soit un jour porté sur nos linuxettes.
-Jedi.
[^] # Re: REISERFS : Episode 2
Posté par bmc . Évalué à 1.
[^] # Re: REISERFS : Episode 2
Posté par j . Évalué à 1.
http://www.innominate.org/~phillips/tux2(...)
[^] # Re: REISERFS : Episode 2
Posté par Anonyme . Évalué à 0.
Nan je déconne
[^] # "Merger" Tux2 et ReiserFS?
Posté par reno . Évalué à 1.
Maintenant, c'est un de ses points (mais pas le seul comme tes super-articles l'expliquent tres bien).
A ton avis est-ce qu'on a une chance un jour d'avoir le systeme Tux2 "ajoute" a ReiserFS?
Autant combiner les points forts..
# REISERFS - Dernier épisode (snif)
Posté par j . Évalué à 5.
*** REISERFS DEMAIN ***
La version actuelle de ReiserFS (au niveau de l'organisation physique des
données) est la 3. D'une version majeure a l'autre, beaucoup de choses sont
remises en question. En bref : n'esperez pas relire vos partitions ReiserFS
4 sous un kernel avec ReiserFS 3. Dans l'autre sens, il est possible que ça
fonctionne, Hans Reiser s'étant engagé auprès d'Alan Cox à supporter ce
format ad vitam eternam. En pratique.... on verra. Mais pas de panique
cependant : ReiserFS 4 n'est prévu que pour Linux 2.6 (ce qui veut dire
qu'en pratique ce sera encore plus tard) .
A court terme, ReiserFS 3 (TROIS) va implémenter les wandering logs. Pour
l'instant, le journal est situé à un endroit fixe du disque, choisi lors du
formattage du dur. En dehors des problèmes de déplacement de la tete de
lecture, ce n'est pas très fiable d'écrire sans arret dans la meme zone du
disque dur. On augmente considérablement ses chances d'obtenir des
badblocks. Et des badblocks dans le journal, ce n'est pas bon du tout.
Les wandering logs consistent à avoir un journal qui se déplace dans
différentes zones du disque (si possible près des données les plus accédées) .
Toujours à court terme, il y a des chances pour que les disques durs à
problème (badblocks) soient un peu mieux gérés que maintenant. Actuellement,
en cas de badblock, ReiserFS espere que le disque va faire un remapping
transparent des secteurs. Certains disques SCSI le font. Mais si ce n'est
pas le cas... hum... pour l'instant vous risquez de paumer des données.
Toutes les données de ReiserFS sont stockées sous la forme d'un arbre : si
on coupe une branche, il devient difficile de retrouver tout ce qui se
trouvait en dessous. En fait, Hans Reiser dit souvent "si on commence à
avoir des badblocks, le disque dur ne va pas tarder à lacher de toutes
façons, donc il faut changer de dur". Mais bon, tout le monde le saoule pour
qu'un traitement des badblocs soit tout de meme implémenté. A mon avis, ce
sera fait rapidement, dès que Chris et Vladimir auront un peu de temps, et
après les wandering logs.
Bon sinon pour la v4 ... Quelques idées ont été évoquées et validées. Mais
rien n'est sur, et aucune implémentation n'a débuté :
- Les snapshots à la Netapp.
- Un filesystem distribué en réseau, pour remplacer les croulants NFS et
Coda (projet mort, les développeurs planchent sur Intermezzo qui est
actuellement inutilisable, ils testent juste des concepts avec une premiere
approche en Perl) . L'idée serait éventuellement d'envisager un partenariat
avec GFS (Global Filesystem, excellent projet, mais pas hyper rapide au
niveau de l'écriture physique. ReiserFS serait un bon complément) .
- Plus de limitation pour les collisions avec les valeurs de hachage. Je
n'ai pas envie de m'étaler là-dessus, mais en gros, à chaque nom de fichier
est associé une clef. Si un répertoire contient 127 fois la même clef, on ne
peut plus créer de nouveau fichier avec cette clef. Xuan a proposé une
solution pour y remédier (en gros, on crée un nouveau tableau de 127 clefs) .
- Les plug-ins !!! Enfin !!!
Voilà... je vais m'arreter là... fatigué....
Babouilles à tous, j'espere que ces quelques lignes vous auront éclairé
sur les objectifs de ReiserFS !
-Jedi.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par PinG . Évalué à 1.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par Anonyme . Évalué à 0.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par Anonyme . Évalué à 0.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par PinG . Évalué à 1.
un T-Shirt pour Franck!
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par bmc . Évalué à 1.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par j . Évalué à 1.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par bmc . Évalué à 1.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par Anonyme . Évalué à 0.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par bmc . Évalué à 1.
Non sérieux, je crois qu'il mérite amplement son TShirt et pourquoi pas un abonnement Linux+
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par Ramón Perez (site web personnel) . Évalué à 1.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par jp martin . Évalué à 1.
Néanmoins, est ce qu'il y a une différence si on 64Mo ou 128Mo de Ram avec ReiserFS ?
Je suis sous ReiserFS/Mandrake7.2 et je mets beaucoup plus de temps actuellementpour compiler mon cvs de kde2.1 que lorsque j'étais sous ext2 !
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par PinG . Évalué à 1.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par j . Évalué à 1.
D'autre part les performances dépendent aussi... de l'occupation des partitions. Eh oui, quand une partition est pleine à craquer, quelque soit le filesystem, il faut commencer à jongler pour organiser correctement ses données. Ca vient peut-etre de ça, le fait que la compilation soit plus lente désormais chez toi.
Moralité : si vous avez un gros disque dur, avec de l'espace à gogo : faites plusieurs partitions (ne serait-ce-que pour des raisons de fiabilité : un /tmp qui merdouille ne va pas corrompre /home) .
Si vous etes plutot juste en place, faites une seule grosse partition !
-Jedi.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par Anonyme . Évalué à 0.
J'ai passé quelques heures à lire la page de reiserfs de suse, j'ai pas trouvé ce genre d'infos
Cheers
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par PinG . Évalué à 1.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par Anonyme . Évalué à 0.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par j . Évalué à 1.
-Jedi.
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par bmc . Évalué à 1.
m'est avis qu'avec les compétences que tu as l'air de posséder, ton attente ne devrait pas être trop longue...
[^] # Re: REISERFS - Dernier épisode (snif)
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
Je crois beaucoup en l'avenir de reiserfs.
Si le fs est aussi solide que Hans Reiser, on peut avoir confiance.
Voici une anecdote sur Hans :
Aux Rencontres Mondiales du Logiciel Libre 2000, le 5 juillet, pendant la scéance d'ouverture, François Pellegrini parlait du thème "Securité" et Hans descendait sans faire de bruit les marches du grand amphi de l'ENSEIRB.
Soudain, un grand bruit de chute : c'était Hans qui était tombé en avant ! Comme il est un habitué des salles de musculation, il avait amorti la chute, puis s'est relevé et enfin a présenté ses excuses.
Il y a vraiment beaucoup de ressemblance entre Reiserfs et son père :)
# Et avec le RAID logiciel?
Posté par Matthias Saou . Évalué à 1.
D'où la question suivante : Comment se comprte-t-il sur du RAID logiciel? (striping et raid 0)
Si quelqu'un a des infos, ça m'interesse car j'ai plusieurs disques "concaténés" (oui, je veux un gros point de montage; non, je veux pas tout séparer) et j'aimerais pas que ça pose des problèmes si j'ai envie de tester du ReiserFS dessus :-)
Matthias
[^] # Re: Et avec le RAID logiciel?
Posté par j . Évalué à 1.
Si tu veux concaténer plusieurs disques durs, passe par LVM (http://www.sistina.com(...)) . LVM a de toutes façons plein d'avantages.
Il y a par contre une grosse limitation actuellement : on peut étendre une partition ReiserFS, mais pas la réduire. La réduction nécessite d'implémenter de quoi compacter l'arbre, ce qui n'a pas encore été réalisé.
-Jedi. ( pub: http://www.rtchat.com(...) )
# ReiserFS et RAID
Posté par Stderr . Évalué à 1.
Peut-on faire du RAID logiciel avec des partitions ReiserFS ?
Si oui, est-ce intéressant ? RAID 1 ? RAID 0+1 ?
Si non, pourquoi ? Est-ce prévu ?
[^] # Re: ReiserFS et RAID
Posté par Stderr . Évalué à 1.
# vitesse d'un find?
Posté par niclone (site web personnel) . Évalué à 1.
Question:
Puisque ReiserFS utilise des tables de hash, trouvé un fichier dans un dossier est tres rapide, je suppose que c'est la meme chose pour un répertoire: trouver un répertoire parmis plein d'autres dans un répertoire doit aussi aller tres vite. Par contre, je ne sais pas trop ce que ca donne si on fait une recherche d'un fichier a partir de / par exemple, parceque a priori, le disque dur devra lire plusieurs tables de hashage a plusieurs endroit differents du disque, non?
Bref, ma question est: a la racine d'une partition pleine de petits fichier, combien de temps ca prends de faire une recherche d'un fichier par son nom ? (find /partition -name toto.titi)
[^] # Re: vitesse d'un find?
Posté par j . Évalué à 1.
[^] # Re: vitesse d'un find?
Posté par jpph . Évalué à 1.
[^] # Re: vitesse d'un find?
Posté par j . Évalué à 1.
# Notebooks
Posté par j . Évalué à 1.
*** N'UTILISEZ PAS REISERFS SUR LES ORDINATEURS PORTABLES ***
Pourquoi donc ? Ce serait bien pratique pour éviter les fsck lorsque les batteries ont lâché un peu tôt !
Oui mais voilà : lorsque les applications ne font plus aucun accès au disque, ReiserFS en profite pour rééquilibrer l'arbre, synchroniser le journal, et plus tard le déplacer.
Conséquence positive : pendant les périodes d'inactivité, le filesystem s'optimise.
Conséquence négative : le disque dur "gratte" davantage qu'avec Ext2. L'autonomie des notebooks sur batteries est donc réduite.
Bref sur un portable, utilisez Ext2 et noflushd ( http://noflushd.sourceforge.net(...) ) . N'hésitez pas non plus à compiler vos applis dans un ramdisk (le filesystem swapfs est pratique pour ça) : c'est plus rapide et le disque dur peut rester en veille. Et sur un portable, montez absolument vos partitions en noatime,nodiratime.
-Jedi.
[^] # Re: Notebooks
Posté par Anonyme . Évalué à 0.
[^] # Re: Notebooks
Posté par j . Évalué à 1.
[^] # Re: Notebooks
Posté par anux . Évalué à 1.
# Stabilité de Reiserfs pour un serveur de fichier de production
Posté par Julien Leroy . Évalué à 1.
Sur un tel volume je m'inquiète pour le temps de fsck en cas de crash.
D'ailleurs, je suis preneur pour une estimation (à la louche) du temps de ext2fsck au Go (même si cela dépends du nombre d'erreurs, je pense que c'est linéaire vis à vis du volume).
Mon autre inquiétude porte sur la stabilité. D'après ce que j'ai vu, lu, entendu et partiellement testé, Reiserfs semble le système de fichier journalisé libre le plus avancé et le plus stable.
- Apparemment Sourceforge utilise reiserfs sur des filesystems de 400Go, mais peut-on le considérer suffisamment stable pour l'utiliser en production?
- Est-il possible de patcher un noyau 2.2.14 pour supporter reiserfs (obscures raisons de support de driver de carte Fibre Channel)?
- Quelqu'un a-t-il déjà utilisé LVM avec reiserfs?
- Dernière question (ouf!) : si je suis obligé de rester en ext2 et que le temps est pénalisant , comment puis-je (proprement) faire pour ne pas vérifier tous les systèmes de fichier au boot, mais les vérifier 1 par 1 et les monter et partager au fur à mesure (évacuons la pression au fur et à mesure).
Bon ben là, je crois que je me suis lâché ;-)
Julien.
PS : si ça marche, je vous en dirais un peu plus sur l'archi de fou que l'on a mis en place grâce aux gigantesques possibilités du logiciel libre.
[^] # Re: Stabilité de Reiserfs pour un serveur de fichier de production
Posté par Anonyme . Évalué à 0.
Linux 2.2.14 ? Mon dieu, c'est vieux ça... Il y a une version de ReiserFS pour ce noyau, je ne me souviens plus si elle comprend des bugs majeurs ou pas. Au pire on peut toujours envisager un backport (ou voir si ton driver de carte fibre channel ne peut pas fonctionner avec un kernel plus récent, ou faire le nécessaire pour) .
Oui j'utilise LVM avec ReiserFS, ça fonctionne. Tu peux aussi installer une SuSE 7 qui comprend une interface d'administration pour LVM et ReiserFS (3.5) en standard.
Pour ta derniere question il suffit de revoir les scripts de boot ... Au lieu d'un seul fsck, tu les fais un par un...
-Jedi.
# Zut ! et ext3 ?
Posté par Anonyme . Évalué à 0.
Ext3 est-il réellement beacuoup + lent ? Je n'arrive pas à voir, j'ai changé pour un hd + rapide en même temps, et globalement j'y ai pas mal gagné.
Et le *GROS* avantage d'ext3, c'est qu'on peut migrer à/depuis ext2 sans problème. D'un point de vue maintenance/outils (genre si tout est planté, que je veux repasser au ext2) c'est incomparable.
Xav
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.