# [Files Systems] trollons gaiement ...

## Enlight

Plop à tous,

Je sais que pas mal de personnes ici considèrent reiser4 comme _la_ grande avancée en matière de FS, un truc qui ravage tout, etc... Perso ça me fait penser un peu à ces bugs reports conclus ar un "Oh F*** I'm going so fast".

Je me permets donc de poster un petit bench que fallow avait laché sur OTW (tous les FS sont stock, au plus un noatime)

```
                                       ext2     ext3      jfs     xfs     reiser3  reiser4 

  1   Create 10.000 files into a dir  14,950   21,473   12,144   12,756   11,278   11,642 

  2   Run find on that dir            00,013   00,069   00,054   00,050   00,061   00,101 

  3   Remove that dir                 00,078   00,231   00,905   01,750   00,407   00,741 

  4   Create 10.000 dirs              26,667   24,928   12,001   12,863   11,098   11,870 

  5   Run find on that dir            00,171   00,191   00,291   00,165   00,365   00,260 

  6   Remove the whole dir            00,403   01,188   01,652   01,447   11,230   30,898 

  7   Copy kernel tar from other disk 01,965   02,018   01,999   01,974   01,982   01,968 

  8   Copy kernel tar to other disk   00,983   00,928   00,922   00,785   00,969   00,944 

  9   Untar kernel                    34,229   36,182   36,251   37,182   36,946   38,743 

 10   Tar kernel                      26,639   25,859   26,824   25,806   25,942   26,569 

 11   Remove kerlnel source dir       00,270   00,544   04,377   01,771   01,170   02,351 

 12   Copy kernel tarball 10 times    19,772   20,311   18,882   19,094   20,710   17,703 

 13   Create 1gb from /dev/zero       23,572   25,038   26,052   22,615   25,038   23,650 

 14   Copy the 1gb file same disk     50,427   53,003   88,937   48,297   59,869   48,254 

 15   Split 10mb file 1000 byte pcs   05,769   07,939   03,477   04,262   01,390   01,140 

 16   Split 10mb file 1024 byte pcs   04,992   09,878   03,367   03,750   01,240   00,836 

 17   Split 10mb file 2048 byte pcs   01,482   02,096   01,360   01,942   00,752   00,546 

 18   Split 10mb file 4096 byte pcs   00,494   00,624   00,548   00,995   00,357   00,414 

 19   Split 10mb file 8192 byte pcs   00,229   00,278   00,347   00,510   00,257   00,310 

 20   Copy kernel tree same disk      08,233   19,462   23,082   19,657   27,548   14,530 

 21   Cat 1gb to /dev/null            22,315   22,321   22,170   22,227   24,886   22,834 

 

```

Bref, voilà, sachant en plus que seuls XFS et ext2/3 sont considérés vraiment stables par les devs, j'aurais bien ai mé avoir vos réactions... Moi perso je suis pas près de lacher mon XFS.

----------

## zdra

Je suis étonné que le reizerfs4 n'est pas si bon que ça finalement...

Fin bon moi d'abitude je me dis: gros fichier=ext3 et petit fichiers=resizerfs3 (ou 4 qd ce sera dans la kernel vanilla). Donc sur mon pc de bureau je fais une / resizerfs, une home reiszefs (tt les ptits fichier de config) et j'ai un 2eme disque de stoque gros fichier en FAT32 ( :Embarassed: ) qui va migrer en ext3 un jour...

----------

## Enlight

Perso je trouve le kernel assez gros comme ça et j'aime bien n'avoir de support que pour un fs. De plus j'ai prévu de tester un truc qui à l'air violent avec xfs, à savoir mettre les métadonnées et le journal ailleurs que sur le Disque dur où sont les données (le temps d'acheter une clé usb).

D'ailleurs pour ceux qui ont testé, une chose que je n'apprécie pas du tout avec les reiser* c'est qu'ils rendent les DD beaucoup plus bruyants (et moi ça me donne pas trop confiance).

----------

## arlequin

Pour la Reiser4, je reste perplexe. J'ai tenté une install avec, pour ma partition /... install qui n'a jamais finie, puisque le système freezait perpetuellement lors de grosse compil' (genre glic, avec flag nptl). Ceci dit, j'ai mon arbre portage sur une partoche à part, formattée en reiser4 et qui fonctionne très bien. Mais du côté perf, je ne suis pas encore décoiffé  :Rolling Eyes: 

Par contre, ayant investit (par nécessité) dans un disque de 160Go pour le stockage, je n'ai pas vraiment hésité à le formatter en ext3, dans la mesure où ce FS ne m'a jamais posé de problème.

Ceci dit, concernant la remarque d'Enlight concernant la taille du noyau, je ne vois pas ce qu'il y a de choquant à inclure qu'un seul support de FS et de mettre les autres en modules......... et pour XFS, j'ai lu dans l'aide du noyau qu'elle n'avais d'intéret que pour des disque de (très) grosse capacité.

Voilà.

----------

## sireyessire

ce qu'il y a ce que le reiser4 demande beaucoup de proc, alors c'est sûr que si ton proc est pas super puissant, l'intérêt est limité. Je l'avais testé sur un P3 650, c'est bon, tu oublies... 

si tu as un gros processeur (et oui où ça commence et où ça finit?) ça peut valoir le coup, peut-être.

Personnellement, j'ai que de la reiserfs (3.6) pour mes partitions classiques, et de l'ext2 pour les /boot, et ça me convient.(Oui c'est vrai je dois avoir quelques NTFS et VFAT qui trainent encore...)

Si j'avais un serveur de prod, c'est sûr que je regarderais un peu plus quel fs choisir mais celui là me convient parfaitement pour mon usage.

----------

## arlequin

 *sireyessire wrote:*   

> ce qu'il y a ce que le reiser4 demande beaucoup de proc, alors c'est sûr que si ton proc est pas super puissant, l'intérêt est limité.

 

Heu, un Barton 2500, ça devrait suffir  :Wink: 

Ceci dit, ça n'explique pas l'instabilité que j'ai eu en l'utilisant en partition /, snif !

----------

## yoyo

 *arlequin wrote:*   

> Ceci dit, ça n'explique pas l'instabilité que j'ai eu en l'utilisant en partition /, snif !

  :Shocked: 

Je tourne en reiser4 depuis un bon bout de temps déja et je n'ai jamais eu de problème ...

Quand aux perfs, je ne peux rien affirmer; j'ai changé de babasse en même temps que de fs. Du coup, les perfs ont été largement améliorées (P3@866 => P4@2660).

Enfin perso, je le trouve efficace et plutôt stable : il a pris plusieurs hard-reboot sans jamais se plaindre (sws2+fbsplash powa !!!) ...   :Mr. Green: 

Maintenant les "magic sys key" permettent de limiter la casse (synchro des hdd, démontage, reboote). Merci bassman_fr pour le tip.

Mes 2 cents.

----------

## anigel

Les stats 15 à 19 de ce bench me laissent à penser que les fonctionnalités avancées d'ext3 n'ont pas été activées. Dommage, elles sont considérées comme stables maintenant, et auraient probablement remis les pendules à l'heure sur certains points.

Néanmoins c'est agréable de voir que finalement, mis à part quelques cas extrêmes, ext s'en sort très bien. Les autres valent-ils le coup de se priver d'outils de recovery / backup dignes de ce nom ? Personnellement, je ne crois pas.

----------

## Enlight

 *anigel wrote:*   

> Les stats 15 à 19 de ce bench me laissent à penser que les fonctionnalités avancées d'ext3 n'ont pas été activées. Dommage, elles sont considérées comme stables maintenant, et auraient probablement remis les pendules à l'heure sur certains points.
> 
> Néanmoins c'est agréable de voir que finalement, mis à part quelques cas extrêmes, ext s'en sort très bien. Les autres valent-ils le coup de se priver d'outils de recovery / backup dignes de ce nom ? Personnellement, je ne crois pas.

 

Oui c'est ce que j'entendais pas tous les file systems sont "stock", pas d'option au mkfs, ni au mount, ni acl je crois (quoique je n'ai toujours pas bien compris à quoi ça sert...).

 *Quote:*   

> Ceci dit, concernant la remarque d'Enlight concernant la taille du noyau, je ne vois pas ce qu'il y a de choquant à inclure qu'un seul support de FS et de mettre les autres en modules......... et pour XFS, j'ai lu dans l'aide du noyau qu'elle n'avais d'intéret que pour des disque de (très) grosse capacité.
> 
> Voilà.

 

bah disons que faire un modprobe -r après avoir lu/écrit sur une partoche, bof, bof.... Deplus il me semble qu'écrire d'une partoche avec un fs à une partoche avec un fs différent dégrade sérieusements les perfs.

----------

## arlequin

 *Enlight wrote:*   

> bah disons que faire un modprobe -r après avoir lu/écrit sur une partoche, bof, bof.... Deplus il me semble qu'écrire d'une partoche avec un fs à une partoche avec un fs différent dégrade sérieusements les perfs.

 

Je vois pas trop l'intérêt de retirer un module du noyau, a posteriori.

Pour la copie entres partoches de FS différents, ce n'est pas aussi évident qu'il y ait une perte de performance : tout au plus, les perfs d'accés seront limités par le FS le moins performant des deux.

De plus, entre performance et stabilité/robustesse, je ne réfléchis pas trop pour mes données persos.

----------

## El_Goretto

->enlight:

Pour les ACLs des FS, il faut les voir comme des droits en durs dans le disque: si tu mets ton dur sur un autre système, les droits (liés aux UIDs etc) ne seront pas ceux du nouveau système, mais ceux d'origine. (sous réserve de compréhension gamelle-free de ma part, mais je suis confiant  :Smile: )

----------

## Enlight

 *arlequin wrote:*   

>  *Enlight wrote:*   bah disons que faire un modprobe -r après avoir lu/écrit sur une partoche, bof, bof.... Deplus il me semble qu'écrire d'une partoche avec un fs à une partoche avec un fs différent dégrade sérieusements les perfs. 
> 
> Je vois pas trop l'intérêt de retirer un module du noyau, a posteriori.
> 
> Pour la copie entres partoches de FS différents, ce n'est pas aussi évident qu'il y ait une perte de performance : tout au plus, les perfs d'accés seront limités par le FS le moins performant des deux.
> ...

 

As tu déjà compilé un kernel avec le support pour un seul fs, un seul scheduler etc...? Moi ça m'a parru plus probant que tous les patchs de performances testés.

Et justement le but de mon topic est de dire qu'il existe (depuis un moment) un FS aussi performant que reiser4 et aussi (si ce n'est plus) stable qu'ext3.

----------

## arlequin

 *Enlight wrote:*   

> As tu déjà compilé un kernel avec le support pour un seul fs, un seul scheduler etc...? Moi ça m'a parru plus probant que tous les patchs de performances testés.

 

Moui, et donc, quand tu as besoin d'une fonctionnalité, tu reboot sur un autre noyau ? Tu as d'un côté la performance, de l'autre le confort d'utilisation. Après c'est un choix. Moi je veux bien prôner la performance du système, mais si de l'autre je dois m'emmerder à recompiler mon noyau à chaque fois que j'ai à brancher un nouveau périphérique... bof.

En ce qui concerne les performances, je pense que quasiment tous les tests ne sont pas objectif, dans la mesure où ces tests ce concentrent sur une certaine utilisation (bureautique, jeu, graphisme, multimedia...). On peut prendre l'exemple d'un serveur : tu ne cherches pas forcément les performances, mais plutôt la stabilité et la disponibilité des services. Alors tu peux facilement casser en disant que ta machine de bureau à de meilleures performances, mais elle n'a (sûrement) pas la même stabilité pour certaines tâches (services). De ce fait, je pense qu'il faut avoir un certains recul sur un benchmark, si ce n'est que pour voir dans quelles conditions il s'applique.

----------

## Enlight

ben non ce dont je risque d avoir besoin, mais surement pas au quotidien c'est en module. Mais si je peux rester avec un fs, je le fais c'est tout.

----------

## Tony Clifton

J'compte repasser au gentoo-sources, je vais donc devoir abandonner le reiser4. J'voulais donc avoir votre avis sur le fs, pour le système c'est sûr, ce sera de l'xfs mais pour home j'hésite entre de l'ext3 ou de l'xfs, car ce qui est écrit dans la doc d'install de gentoo ne me met pas en confiance :

 *handbook wrote:*   

> XFS est un système de fichiers avec des métadonnées journalisées qui possède un ensemble de fonctionnalités robustes et qui est optimisé pour la mise à l'échelle. Nous ne recommandons ce système de fichiers que pour des systèmes équipés d'unités de stockage SCSI haut de gamme ou connectés à des serveurs de stockage « Fibre Channel », et munis d'un onduleur. Puisque XFS utilise énormément le cache pour des données transitoires en mémoire vive, les programmes mal conçus (ceux qui ne prennent pas les précautions suffisantes quand ils écrivent les fichiers sur disque, et il y en a quelques uns) peuvent perdre beaucoup de données si le système s'interrompt de manière inattendue.

 

----------

## Enlight

 *Quote:*   

>  like ReiserFS, XFS only journals metadata, and does not take any special precautions to ensure that the data makes it to disk before metadata is written. This means that with XFS (just like with ReiserFS), it's possible for recently modified data to be lost in the event of an unexpected reboot. However, a couple of properties of XFS' journal make this issue less common than it is with ReiserFS. 
> 
> With ReiserFS, an unexpected reboot can result in recently modified files containing portions of previously deleted files. Besides the obvious data loss, this could also theoretically pose a security threat. In contrast, XFS ensures that any unwritten data blocks are zeroed on reboot, when XFS journal is replayed. Thus, missing blocks are filled with null bytes, eliminating the security hole -- a much better approach.

 

extrait de cette page : ttp://www-106.ibm.com/developerworks/linux/library/l-fs9.html

----------

## Faust_

 *Enlight wrote:*   

> D'ailleurs pour ceux qui ont testé, une chose que je n'apprécie pas du tout avec les reiser* c'est qu'ils rendent les DD beaucoup plus bruyants (et moi ça me donne pas trop confiance).

 

ben perso j'ai tout en reiser 3.6 sauf le boot qui est en ext2 et une vieille parto pas encore migree qui est en fat32 et je n'entend pas mes disques durs

bref content du reiser 3 et pas presse de changer, peut-etre un jour si le 4 fait ses preuves ou si un fs revolutionnaire venait a sortir

 :Smile: 

----------

## Tony Clifton

Ok, merci Enlight, c'est partit pour du XFS partout.

 *Faust_ wrote:*   

> ben perso j'ai tout en reiser 3.6 sauf le boot qui est en ext2 et une vieille parto pas encore migree qui est en fat32 et je n'entend pas mes disques durs
> 
> bref content du reiser 3 et pas presse de changer, peut-etre un jour si le 4 fait ses preuves ou si un fs revolutionnaire venait a sortir
> 
> 

 

Sur du S-ATA le reiserfs est vraiment bruyant, mais par contre le reiser4 est très silencieux.

----------

## lmarcini

Et le JFS dans tout ça ?

----------

## Tony Clifton

 *lmarcini wrote:*   

> Et le JFS dans tout ça ?

 

lol, c'est vrai tiens, j'me demande si quelqu'un l'utilise ?

----------

## Enlight

 *lmarcini wrote:*   

> Et le JFS dans tout ça ?

 

En progrès énormes, pas encore considéré super stable par les devs gentoo, mais bon il doit ressembler pas mal à xfs.

----------

## TTK

Evidemment tout ceci est une affaire de gouts et de choix perso. M'enfin j'avais jamais eu une telle perte de données sous ext2 ou 3 que celle que j'ai eue en XFS. Un hard reboot (plus de batterie, acpid mal configuré ..) et j'ai perdu une 100aine de Mo. Et des fichiers qui n'étaient pas ouverts, ni en lecture ni en écriture !

(La quasi totalité de mon mirroir local de mon site web, et pas mal de photos numériques archivées. Que des fichiers "inertes" vraiment pas utilisés au moment de la panne.)

Je suis repassé en ext3. Et je fais gaffe à ma batterie  :Wink: 

----------

## Enlight

T'as utilisé xfsrecovery??? c'était des données qui changeaient souvent (fréquement modifiées)??? Moi j'ai vu un gars faire une grosse boulette en install windows et formater en NTFS la mauvaise partoche (celle en XFS où il avait ses données), ben il a reformaté en XFS à lancé xfsrecovery et à récupéré plus de 85% de ses données.

----------

## TTK

Ben en fait après j'ai paniqué. J'avais plus de libc non plus, j'ai patouillé pas mal et j'ai fini pas faire des tars de sauvegarde et une réinstall. En détarrant mes sauvegardes il manquait des trucs, mais j'en ai retrouvé pas mal à la main dans les lost+found, et sur mes autres sauvegardes.

Au final j'ai rien perdu en fait. A part pas mal de temps.

Pour en revenir au benchmark: le jour ou je crée 10000 fichiers dans un rep, ça me dérangera pas d'attendre 3 pouillièmes de secondes de plus. Au pire, ce jour là, je couperai mon xmms  :Wink: 

----------

## cylgalad

ext3 pour moi, c'est stable et ça va toujours plus vite que NTF$ et FAT (qui ne sont pas dans ton bench c'est bizarre ça  :Very Happy: ) et on peut le manipuler "facilement" sous windaube...

PS : on dit "file systems" (pas de S à "file") mais le mieux c'est encore "système de fichiers" en bon français...

----------

## Starch

 *cylgalad wrote:*   

> PS : on dit "file systems" (pas de S à "file") mais le mieux c'est encore "système de fichiers" en bon français...

 

Le problème c'est pour acronymiser... SF et SDF sont déjà pris...

----------

## Jerem

Je vais juste faire une remarque intéressante :

si on est assez balèze pour installer gentoo, choisir XFS en connaissance de cause, on est également assez intelligent pour sauvegarder ses données avant de faire quelque chose d'expérimental.

Bien entendu, il y a toujours les impondérables, comme xorg qui crashe et même Magig Sys Request ne marche plus...

Sinon, pour revenir plus précisément au sujet, j'ai toujours été un fan absolu de reiserfs, notamment sa version 3(la 4 n'étant pas encore assez testée à mon goût). J'ai subi plusieurs hard reboot, et jamais je n'ai noté de pertes de données (rien dont je ne me suis rendu compte en tout cas).

En ce qui concerne mon /home, je le mets toujours en ext3, pour que explore2fs puisse me l'ouvrir sous Windows.

En y pensant, quand je fais un mk2fs -j sur une partoche, j'ai une erreur de dma_timer_expiry(quand il crée plein d'inodes sur 3 gigas). Pourtant, le fs semble correctement installé... D'autres ont ce problème ?

----------

## Enlight

Parceque reiser 3.6 martyrise les disques en les sync-ant (mais plus grosse frag du coup) plus souvent, celà dit ça peut se paramétrer quelque soit le FS via /proc ou /sys je sais plus.

Celà dit si une coupure intervient pendant un sync du disque y'a pas que les données que tu risque de perdre... Et pour les hards reboot activer le truc dans le bios qui fait attendre 4 secondes quand tu appuyes sur le bouton power me semble une bonne idée également.

----------

## Trevoke

Ceci dit, XFS est un FS tres dangereux parce qu'il buffer enormement  :Smile: 

je suis en reiserfs ou reiser4, parce que je n'ai pas vraiment de gros fichiers, plutot des petits, donc reiser est, il parait, le bon choix.

----------

## scout

 *Quote:*   

> trollons gaiement ...

 

Le test est pas complet, il manque la fat !  :Mr. Green: 

----------

## shad_

Perso j'ai ma / et mon /home en ext2 sur mon laptop (j'aime pas les nombreux acces disque de la journalisation). Niveau sécurité des données, c'est vrai que c'est un peu juste mais pour un laptop je pense que c'est suffisant.

----------

## Ey

 *scout wrote:*   

>  *Quote:*   trollons gaiement ... 
> 
> Le test est pas complet, il manque la fat ! 

 

Mince je l'avais raté ce thread là... sinon je suis d'accord, il manque des choses dans ce test, les performances ne sont pas tout dans la vie, moi perso ça me gave d'avoir des partitions ext surtout parce que l'on perd pas mal de place quand on stoque beaucoup de fichiers (pleins d'images, code, et surtout le /var/tmp/portage qui doit être surdimensionné...)

Sinon avant de taper sur reiser4 il faut aussi prendre en compte que ce fs ne se corrompt jammais (enfin sauf erreur d'implémentation mais en gros une coupure de courrant ne *peut* pas casser le fs), ça pourra probablement jouer quand le fs aurra un peu plus de bouteille. Sinon je ne vais pas non plus faire une appologie de reiserfs vu que je n'ai que ext pour comparer, mais je voulais juste faire remarquer que réduire la comparaison entre des fs à des comparaisons de performances est assez réducteur...

----------

## El_Goretto

 *Ey wrote:*   

> 
> 
> Sinon avant de taper sur reiser4 il faut aussi prendre en compte que ce fs ne se corrompt jammais (enfin sauf erreur d'implémentation mais en gros une coupure de courrant ne *peut* pas casser le fs), ça pourra probablement jouer quand le fs aurra un peu plus de bouteille. 

 

Yep, l'atomicité des opérations de reiser4 me fait rêver aussi... Mais je résiste, et j'attends cette "maturité"  :Smile: 

----------

## Trevoke

C'est clair que si vous faites reference a mon probleme de baselayout, qui est arrive parce que mon ordi a subi une panne de courant.. Enfin.. Deux en moins d'une seconde... Enfin... 3 en 3 minutes... reiser4 etait quasiment impec, et j'ai juste du reparer la partition ext3 que j'ai pour vmware.

----------

## boozo

[HS] @ El_Goretto : t'entends quoi exactement par  *Quote:*   

> l'atomicité des opérations de reiser4 me fait rêver aussi...

 

c'est un nouveau sens du mots ?  :Laughing:   parceque pour moi il a un sens chimique très clair et je ne vois pas vraiment le lien avec la choucroute  :Mr. Green: 

[/HS]

PS: ok je  :Arrow:   []  (mais bon vu le titre du thread... j'y ai droit là non ? ) 

----------

## Enlight

[quote="Ey"] *scout wrote:*   

>  *Quote:*   trollons gaiement ... 
> 
> Le test est pas complet, il manque la fat ! 

 

Mince je l'avais raté ce thread là... sinon je suis d'accord, il manque des choses dans ce test, les performances ne sont pas tout dans la vie[|/quote]

 :Shocked:  M'enfin on est sous gentoo là, tu t'es fait virer du club honda civic local ou quoi???   :Mr. Green:  lol patapé

 *Quote:*   

> 
> 
> , moi perso ça me gave d'avoir des partitions ext surtout parce que l'on perd pas mal de place quand on stoque beaucoup de fichiers (pleins d'images, code, et surtout le /var/tmp/portage qui doit être surdimensionné...)
> 
> Sinon avant de taper sur reiser4 il faut aussi prendre en compte que ce fs ne se corrompt jammais (enfin sauf erreur d'implémentation mais en gros une coupure de courrant ne *peut* pas casser le fs),

 

Tu saurais m'expliquer le pourquoi du comment en vulgarisant stp?

 *Quote:*   

> 
> 
>  ça pourra probablement jouer quand le fs aurra un peu plus de bouteille. Sinon je ne vais pas non plus faire une appologie de reiserfs vu que je n'ai que ext pour comparer, mais je voulais juste faire remarquer que réduire la comparaison entre des fs à des comparaisons de performances est assez réducteur...

 

En tout cas dans la mesure ou comme xfs et jfs et contrairement à ext3 et reiser 3.6 J'imagine qu'il doit buffeuriser pas mal également.

----------

## Ey

 *Enlight wrote:*   

>  M'enfin on est sous gentoo là, tu t'es fait virer du club honda civic local ou quoi???   lol patapé

 

LOL

 *Quote:*   

>  *Quote:*   
> 
> moi perso ça me gave d'avoir des partitions ext surtout parce que l'on perd pas mal de place quand on stoque beaucoup de fichiers (pleins d'images, code, et surtout le /var/tmp/portage qui doit être surdimensionné...)
> 
> Sinon avant de taper sur reiser4 il faut aussi prendre en compte que ce fs ne se corrompt jammais (enfin sauf erreur d'implémentation mais en gros une coupure de courrant ne *peut* pas casser le fs), 
> ...

 

En fait il suffit d'aller voir sur le site officiel ils expliquent pas mal de choses.

"When there is a set of operations which we will ensure will all take effect, or none take effect, we call the set as a whole an atom. Reiser4 implements all of its filesystem system calls (requests to the kernel to do something are called system calls ) as fully atomic operations, and allows one to define new atomic operations using its plugin infrastructure. Why don't all filesystems do this? Performance."

"Aligning files to 4k boundaries does have advantages for large files though. When a program wants to operate directly on file data without going through system calls to do it, it can use mmap() to make the file data part of the process's directly accessible address space. Due to some implementation details mmap() needs file data to be 4k aligned, and if the data is already 4k aligned, it makes mmap() much more efficient. In Reiser4 the current default is that files that are larger than 16k are 4k aligned. We don't yet have enough empirical data and experience to know whether 16k is the precise optimal default value for this cutoff point, but so far it seems to at least be a decent choice."

entre autres...

les idées principales sont :

- opérations atomiques => fs très résistant aux crashs

- partage des blocs => gain de place

et un truc que je retrouves plus mais qui porte aussi sur le fait que lorsqu'on a plein de fichiers dans un répertoire, la reiserfs permet de consommer moins de place pour conserver cette liste.

 *Quote:*   

>  *Quote:*   
> 
>  ça pourra probablement jouer quand le fs aurra un peu plus de bouteille. Sinon je ne vais pas non plus faire une appologie de reiserfs vu que je n'ai que ext pour comparer, mais je voulais juste faire remarquer que réduire la comparaison entre des fs à des comparaisons de performances est assez réducteur... 
> 
> En tout cas dans la mesure ou comme xfs et jfs et contrairement à ext3 et reiser 3.6 J'imagine qu'il doit buffeuriser pas mal également.

 

Je n'ai jammais dis que tu ne pouvais pas perdre de données, ça je vois pas comment l'éviter de toute façon. Par contre tu ne perdras pas ta partition ou d'autres fichiers en domages colatéraux.

EDIT : le lien vers la doc (en anglais comme les citations dsl)

----------

## Enlight

 *Ey wrote:*   

> 
> 
> EDIT : le lien vers la doc (en anglais comme les citations dsl)

 

No problème, en général ces concepts là je les comprends mieux quand c'est expliqué en anglais (va comprendre...). Par contre j'ai fait l'amalgamme entre perte de données et corruption de FS. Sur ce point, XFS est également extrèmement corriace.

Par contre comme il me le semblait, reiser 4 implémente de nouveaux syscalls, à tout hasard tu saurais où dans les sources du noyau se trouve la table des appels?

----------

## Ey

 *Enlight wrote:*   

> Par contre comme il me le semblait, reiser 4 implémente de nouveaux syscalls, à tout hasard tu saurais où dans les sources du noyau se trouve la table des appels?

 

Non je t'avouerais que je n'ai même jammais cherché. Je me suis surtout intéressé aux parties driver et net (et un peu le boot aussi) du noyau, pour le reste...

----------

## Enlight

Je réponds à ma propre question (pour ceux que ça intéresse) /usr/src/linux/arch/i386/kernel/entry.S

----------

