[Filesystems] Welke is beter? + hdparm

[Verwijderd]

Ik moest vandaag ff een image van een hdd maken. De hdd in kwestie van 6GB. ik dus vrolijk met het dd commando aan het spelen geslagen.....krijg ik opeens de melding 'filesize limit exceeded' (oid.) Ik weet dat ext2 per file maar 2GB kan hebben. Aangezien ext3 maar een dirty hack is zal dit waarschijnlijk bij ext3 ook zo zijn, dat zou ook de foutmelding verklaren. Of vindt samba het niet goed als je files van meer dan 2GB wilt transferen? De file was precies 2GB geworden. Als ik op die schijf reiserfs had gebruikt was het dan wel gelukt? en als ik xfs had gebruikt?

Waarom zit xfs support nog niet standaard in de kernel? Zijn er naast ext{2,3}, xfs en reiserfs nog meer filesystems die het proberen waard zijn? Met welke fs'en hebben jullie goede of slechte ervaring?

En als we dan toch met hdd's bezig zijn....post hier je 'hdparm -tT /dev/<schijf>' (met beschrijving hdd en controller)

[Ronald]

smbfs support geen files groter dan 2G
ook al draait de server op Reiser, XFS, JFS Ext2/3 of windows met Ntfs welke allen files van ettelijke tientallen Gigs aan kunnen.

Xfs is nog niet volledig uitgestabiliseerd, gentoo heeft dat ondervonden en het uit de gentoo-kernel gehaald.

Ik heb wat bonnie++ benches gemaakt onder linux-2.4.18?-jp8? een hele tijd terug.
http://hummelink.xs4all.nl/download/FS-bench.html
JFS was hierbij echt niet stabiel, een van de kernel procesjes overleed tijdens de eerste poging.

[ Voor 0% gewijzigd door Ronald op 15-10-2002 22:04 . Reden: Link tiepvaut ]

[odysseus]

Ext2 kan in ieder geval *wel* grote bestanden aan, zolang je kernel en je libs dat ook maar kunnen (en dat gaat tegenwoordig wel goed). Je probleem zit waarschijnlijk bij samba, wat betekent dat het niet had uitgemaakt of je XFS of iets anders had gebruikt.

XFS zit nog niet in de 2.4-kernel omdat het veel ingrijpender wijzigingen nodig heeft dan andere filesystems die al wel standaard worden meegeleverd.

Andere interessante filesystems zijn onder andere Coda, NFS, JFS en InterMezzo. Keus genoeg dus . Sommige van deze filesystems zijn netwerk-based.

[Verwijderd]

6GB ATA33 Seagate:

code:

ST36424A, ATA DISK drive
12594960 sectors (6449 MB) w/512KiB Cache, CHS=784/255/63
 Timing buffer-cache reads:   128 MB in  1.03 seconds =124.27 MB/sec
 Timing buffered disk reads:  64 MB in  6.52 seconds =  9.82 MB/sec

40GB ATA33 IBM 7200rpm:

code:

IC35L040AVER07-0, ATA DISK drive
80418240 sectors (41174 MB) w/1916KiB Cache, CHS=5005/255/63
 Timing buffer-cache reads:   128 MB in  1.03 seconds =124.27 MB/sec
 Timing buffered disk reads:  64 MB in  2.84 seconds = 22.54 MB/sec

8GB ATA33 WD:

code:

WDC AC38400L, ATA DISK drive
16514064 sectors (8455 MB) w/256KiB Cache, CHS=1027/255/63, UDMA(33)
 Timing buffer-cache reads:   128 MB in  0.97 seconds =131.96 MB/sec
 Timing buffered disk reads:  64 MB in  5.72 seconds = 11.19 MB/sec

12GB ATA33 WD:

code:

WDC AC313000R, ATA DISK drive
25429824 sectors (13020 MB) w/512KiB Cache, CHS=1582/255/63, UDMA(33)
 Timing buffer-cache reads:   128 MB in  0.97 seconds =131.96 MB/sec
 Timing buffered disk reads:  64 MB in  4.95 seconds = 12.93 MB/sec

18GB SCSI Seagate 7200rpm:

code:

ST318275LW
SCSI device sda: 35566480 512-byte hdwr sectors (18210 MB)
 Timing buffer-cache reads:   128 MB in  0.98 seconds =130.61 MB/sec
 Timing buffered disk reads:  64 MB in  4.24 seconds = 15.09 MB/sec

100MB Parallele Iomega Zip: (voor als je niet weet wat je met je cpu tijd moet doen )

code:

ZIP 100
SCSI device sdb: 196608 512-byte hdwr sectors (101 MB)
 Timing buffer-cache reads:   128 MB in  0.99 seconds =129.29 MB/sec
 Timing buffered disk reads:  64 MB in 404.09 seconds =162.18 kB/sec

2GB Seagate

code:

ST32122A, ATA DISK drive
ST32122A, 2014MB w/128kB Cache, CHS=4092/16/63
 Timing buffer-cache reads:   128 MB in 21.65 seconds =  5.91 MB/sec
 Timing buffered disk reads:  64 MB in 57.91 seconds =  1.11 MB/sec

[Verwijderd]

RonaldH schreef op 15 oktober 2002 @ 21:54:
smbfs support geen files groter dan 2G
ook al draait de server op Reiser, XFS, JFS Ext2/3 of windows met Ntfs welke allen files van ettelijke tientallen Gigs aan kunnen.

vmware wilde bij mij geen 'virtuele schijven' van meer dan 2gb maken omdat volgens vmware dat niet mogelijk was bij ext2. wie heeft hier gelijk?
btw. die link een prachtige 404

[Ronald]

Verwijderd schreef op 15 oktober 2002 @ 21:59:
[...]

vmware wilde bij mij geen 'virtuele schijven' van meer dan 2gb maken omdat volgens vmware dat niet mogelijk was bij ext2. wie heeft hier gelijk?

vmware niet

btw. die link een prachtige 404

F1x0r3d

BTW: je weet dat hdparm nietszeggend is voor filesystem performance ?

[Verwijderd]

RonaldH schreef op 15 oktober 2002 @ 22:06:
[...]
vmware niet

[...]

F1x0r3d

BTW: je weet dat hdparm nietszeggend is voor filesystem performance ?

maar wel voor je hdd performance

[Verwijderd]

http://www.osdl.org/presentations/lwe-jgfs.pdf
http://www.linuxgazette.com/issue68/dellomodarme.html
http://www.linuxjournal.com/article.php?sid=5841

[Wirf]

Verwijderd schreef op 15 oktober 2002 @ 22:07:
[...]

maar wel voor je hdd performance

ook maar gedeeltelijk, je meet de accesstijden er niet mee.

verder haal ik op een IBM 120GXP (7200 rpm, 80 GB):

edit:
ATA100 op een SIS735

code:

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.63 seconds =203.17 MB/sec
 Timing buffered disk reads:  64 MB in  1.41 seconds = 45.39 MB/sec

je kunt beter Bonnie++ gebruiken om je performance te testen.

ow en ik kan ook wel bestanden groter dan 2GB maken op mn reiserfs filesys (maar dan weer niet op mn fat32)

[Verwijderd]

Wirf schreef op 15 oktober 2002 @ 23:06:

Timing buffer-cache reads: 128 MB in 0.63 seconds =203.17 MB/sec

'Timing buffer-cache reads' lijkt meer je memory en/of cpu te benchmarken....klopt dat?

[Wirf]

Verwijderd schreef op 15 oktober 2002 @ 23:25:
[...]

'Timing buffer-cache reads' lijkt meer je memory en/of cpu te benchmarken....klopt dat?

klopt, uit de manpage:

"This displays the speed of reading directly from the Linux buffer cache without disk access."

[deadinspace]

Verwijderd schreef op 15 oktober 2002 @ 21:31:
Ik weet dat ext2 per file maar 2GB kan hebben. Aangezien ext3 maar een dirty hack is zal dit waarschijnlijk bij ext3 ook zo zijn, dat zou ook de foutmelding verklaren.

Ext2 en ext3 kunnen onder standaard-omstandigheden (4 kb blocksize) files tot 2 terabyte aan. Zie /usr/src/linux/Documentation/filesystems/ext2.txt.
De bekende 2GB limiet is een limiet in de VFS layer van 2.2 kernels (met 2.4 kernels ben je beperkt tot 2 TB, in 2.5 wordt het weer omgegooid). Ook is het C data type size_t als 32 bits signed int gedefinieerd op 32 bits systemen (of iig op i386), wat een limiet van 2 GB aan de systemcalls geeft.
Om files groter dan 2 GB te gebruiken moet je dus een 2.4 kernel hebben en het programma moet de 64 bits versies van de system calls gebruiken. Hierbij maakt het niet uit welk FS je gebruikt (Reiserfs en XFS hebben dus ook een 2 GB beperking met 2.2 kernels).

En ext3 is geen dirty hack

Of vindt samba het niet goed als je files van meer dan 2GB wilt transferen?

Het zou kunnen dat samba dat niet ondersteunt ja.

Waarom zit xfs support nog niet standaard in de kernel?

Zit er sinds 2.5.zoveel in, en komt dus in 2.6.
Een belangrijke reden is dat de XFS patch tamelijk groot is en veel delen van de kernel beinvloedt.

Zijn er naast ext{2,3}, xfs en reiserfs nog meer filesystems die het proberen waard zijn?

JFS van IBM schijnt ook wel gaaf te zijn, al is de Linux implementatie ervan afaik nog beta.

En als we dan toch met hdd's bezig zijn....post hier je 'hdparm -tT /dev/' (met beschrijving hdd en controller)

Wil je niet weten
12 meg/sec ofzo op mijn pII met 8 GB schijf (en niet eens udma33 oid)

[Ronald]

Vooruit dan

WD 1200JB 120GB

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.67 seconds =191.04 MB/sec
Timing buffered disk reads: 64 MB in 1.39 seconds = 46.04 MB/sec

IBM 75GXP 45GB

/dev/hdc:
Timing buffer-cache reads: 128 MB in 0.67 seconds =191.04 MB/sec
Timing buffered disk reads: 64 MB in 1.79 seconds = 35.75 MB/sec

[Verwijderd]

/dev/hde:
Model=QUANTUM FIREBALLP AS20.5 BuffSize=1902kB
Timing buffer-cache reads: 128 MB in 0.70 seconds =182.86 MB/sec
Timing buffered disk reads: 64 MB in 1.84 seconds = 34.78 MB/sec

/dev/hdg:
Model=IBM-DTLA-305040 BuffSize=380kB
Timing buffer-cache reads: 128 MB in 0.75 seconds =170.67 MB/sec
Timing buffered disk reads: 64 MB in 2.11 seconds = 30.33 MB/sec

Ze hangen aan een BX board met HPT370 controller.
Niet relevant voor deze uitkomsten, maar ik gebruik XFS tot zover zonder problemen.

[Hagar]

klote time-outs

[Hagar]

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.99 seconds =129.29 MB/sec
Timing buffered disk reads: 64 MB in 2.13 seconds = 30.05 MB/sec

Op een intel 815EP chipset met Intel Corp. 82801BA IDE U100 (rev 2) controller
Schijfje is een 20GB Maxtor 7200rpm

[Verwijderd]

Je hoeft niet per definitie dd te gebruiken. Je kunt als alternatief ook bepaalde dirs afzonderlijk tarren.

RonaldH: leuk dat je ook de filesystem versies erbij zet, nu is het tamelijk nutteloos. Alle developers van de besproken FSen (behalve Ext2FS?) werken hard aan de verschillende FSen en er zijn constant veranderingen. Dat betekend niet per definitie dat het beter/stabieler loopt en dat er optimalisaties op bepaalde fronten zijn maar 't is wel mogelijk. Aangezien je de versies er niet bij zet kan nu niemand onderzoeken hoe de huidige stand van zaken mogelijk en/of inschatten of er nu belangrijke veranderingen/optimalisaties zijn en zo ja welke.

Debian XFS en ReiserFS images van Woody zijn al een tijdje beschikbaar. Sterker nog ReiserFS zat in de main 2.4 image. Hiero staat nog een leuke XFS howto. Verder ff zoeken..

Verder vind ik het nogal een loze opmerking dat Gentoo het eruit heeft gehaald omdat ze instabiele problemen hebben ondervonden? Wat dan? Zo'n problemen worden dan toch opgelost? Met welke versie was dat? Hebben ze het zelf geprobeerd op te lossen oid.? Ik bedoel You must not try to repair a mounted fs since this will result in dataloss and corruption when attempted - zomaar eventjes uit de XFS FAQ. Ik draai zelf XFS 1.0, 1.0.1 en sinds kort geupgrade naar 1.1 en heb nergens problemen mee. Al tijden niet. Daar waar Ext3FS voor mij langzaam was.

XFS draait perfect wanneer je gebruik maakt van het draaien van grote binaries. Neem nou bijvoorbeeld /usr. ReiserFS draait weer perfect wanneer jegebruik maakt van het lezen van kleine files. Bijvoorbeeld /var/spool en /var/run. Conservatieven zullen zich vast wel het best bij Ext3FS voelen. Dit kun je on-the-fly enablen wanneer je kernel er support voor heeft.

Zie ook de verschillende testresultaten op het internet. Te vinden met o.a. Google. Let er wel op dat ze de versies erbij zetten want dat is belangrijk. Zo kun je ook op Linux schelden dat-ie onstabiel is met je gloednieuwe fikker.. terwijl je een 1.x versie draait..

[Wilke]

Maxtor 40 GB 7200 toeren:

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.68 seconds =188.24 MB/sec
Timing buffered disk reads: 64 MB in 1.60 seconds = 40.00 MB/sec

Heb zelf een tijdje XFS gebruikt met Gentoo, en dat ging toen prima. Na een reinstall toch wel ReiserFS gedaan, omdat dat inmiddels wel 'standaard' in alle kernels zit.

[_JGC_]

Tja, benchmarken heeft niet zoveel zin nu ik er net achterkom dat SIS745 een paar slashes ervoor heeft staan in sis5513.c (waar dit in de originele versie niet zo is). Zal dus eerst mn kernel moeten hercompileren.

Ik wou eigenlijk een 2.4.20-pre versie gaan draaien, maar dan heb ik geen XFS support, wat ik wel graag wil hebben. Iemand ervaring met het handmatig toepassen van een 1MB diff file op een andere kernel? of gaan we dan dagen bezig zijn en huilen als een klein kind omdat je FS dan verneukt is?

[im_ik]

Verwijderd schreef op 16 oktober 2002 @ 05:49:
XFS draait perfect wanneer je gebruik maakt van het draaien van grote binaries. Neem nou bijvoorbeeld /usr. ReiserFS draait weer perfect wanneer jegebruik maakt van het lezen van kleine files. Bijvoorbeeld /var/spool en /var/run.

Hier wou ik toch eve op inspringen omdat je het zelf eigenlijk al zegt.
reiserFS voor kleine file dus / en /usr
en XFS voor groote.. dus /films /iso /mp3
aangezien XFS het erg goed doet met multimedia files en die zijn groot

[_JGC_]

XFS is ook goed in executables.

[Verwijderd]

ik was bij een pc vergeten using_dma aan te zetten(hdparm -d 1 /dev/hda). van 5 MB/sec naar 9 MB/sec....toch bijna een verdubbeling in snelheid. zijn er nog meer tips om je hdd en/of fs sneller te maken?

En wat d88 jullie van deze beredenatie:

code:

/                       ext3 vanwege backwards/forwards compatibiliteit en standaard in 2.4 kernels
/var/run            reiserfs, zie post dystopia
/var/spool        reiserfs, zie post dystopia
/films                XFS, zie post im_ik
/iso                   XFS, zie post im_ik
/usr/bin             XFS, zie post _JGC_

en software RAID en/of LVM is dat echt veel sneller?
ACL wordt niet gesupport door ReiserFS toch? wel door XFS? wel door Ext3? Is het echt nuttig?

[_JGC_]

Ik ga zo ff een server met ext3 rebooten als ext2, aangezien ik ext3 ervan verdenk dat ie niet lekker draait. Probleemstelling:
P133 met 16MB trekt zo 100 Apache/Tomcat4 processen tegelijk, weliswaar compleet vanuit de swap draaiend, maar hij blijft draaiend
P2 350 met 128MB gooit Tomcat4 plat zodra er meer dan 5 processen tegelijk draaien, ook ProFTPD en Exim willen dan niet meer forken.

Verschil tussen beide servers:
de hardware en het filesystem (die P133 draait nog ext2, die P2 draait ext3)
Als ie na mounten als ext2 geen problemen meer geeft weet ik genoeg: XFS draaien.

Edit: Hmm, is nog steeds een kjournald process aant draaien op die server, ipv van wat eerst stuk of 5 was, maakte echter niets uit in aantal mogelijke processen

* _JGC_ gaat na de vakantie die server uit de kast trekken en een geheugencheck laten ondergaan.

[Wilke]

_JGC_, jouw probleem klinkt niet alsof het aan ext3 ligt. Ext3 is echt niet 'brak' ofzo, ReiserFS is alleen vaak wat sneller.

In de C't van een paar maanden geleden (ik heb net lopen zoeken maar ben het nummer kwijt, denk ik) staat een heel artikel waarin alle Linux Journaling FS'es worden gebenched. Dus zoek die anders ff op in de bieb als je er wat meer over wil weten.

[_JGC_]

Ik denk dat die server zelf brak is. Zal zo nog ff een andere libc6 proberen die gehackt is (die P133 heeft een gehackte libc6 met meer toegestane pthreads), toen die server nog Debian Stable draaide deed ie met die libc6 helemaal niets meer. Met Sarge gedraagt ie zich al beter (Stable liet em met 3 processen al stikken, wat dat betreft werkt Testing beter)

[Verwijderd]

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.46 seconds =278.26 MB/sec
Timing buffered disk reads: 64 MB in 1.60 seconds = 40.0 MB/sec

Maxtor 40 GB 7200rpm.
IDE controller: VT8233A provides Ultra DMA133 =)

[Verwijderd]

hdparm ook al de -X optie gebruikt? Kun je DMA hoger mee instellen. Check ook manhdparm. Check ook search van GoT, zoek naar hdparm topic van RB338 staat nog wel wat info.

Ext3FS biedt naar mijn ervaring en testresultaten slechte performance. Ik ga niet weer links als argumentatie gebruiken, search van GoT bevat ze. Al dan niet recent.

Ik had zelf /var als ReiserFS en /usr als XFS. Want in /usr draai je wel executables. In /usr/local/bin draai je ook executables. Vond ik het makkelijker om /usr 1 dir te nemen. / is een kleine partitie. Paar honderd MB volstaat. Mijn probleem was met Debian meer dat apt /var/cache/apt/archives gebruikt voor de .deb's en dat dat merkbaar trager ging dan met Ext2FS.

[_JGC_]

code:

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.45 seconds =284.44 MB/sec
 Timing buffered disk reads:  64 MB in  1.63 seconds = 39.26 MB/sec

Terwijl ik aan't up en downloaden ben.
ECS K7S6A, SiS 745, Maxtor D740X 40GB, 768MB PC2100 Samsung CL2.5 DDR SDRAM, 147MHz FSB
IDE controller wordt niet eens ondersteund door de kernel, nog een redelijke score lijkt me zo

* _JGC_ gaat zo een nieuwe kernel bakken met SiS745 support (dwz: die // dingen weghalen voor SiS745)

[Verwijderd]

volgens een van de de links die ik eerder heb gepost presteerde ext3fs vooral goed op een lvm raid gedoe en met een db als geteste app.
voor parities zoals /tmp kan je misschien 't beste ext2fs gebruiken, journaling is dan niet interessant, snelheid wel. toch?

[Verwijderd]

Ok, hier mijn schijfjes, allemaal 5400 rpm dus niet echt snel

code:

/dev/hda
 Model=Maxtor 90845D4, FwRev=GAS54112, SerialNo=A408MD5C
        DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2
 Timing buffer-cache reads:   128 MB in  0.88 seconds =145.29 MB/sec
 Timing buffered disk reads:  64 MB in  4.46 seconds = 14.33 MB/sec



/dev/hdc
 Model=MAXTOR 6L080J4, FwRev=A93.0500, SerialNo=664128116928
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5 udma6
 Timing buffer-cache reads:   128 MB in  0.88 seconds =145.62 MB/sec
 Timing buffered disk reads:  64 MB in  1.72 seconds = 37.12 MB/sec



/dev/hdd
 Model=Maxtor 4D080H4, FwRev=DAH017K0, SerialNo=D41SHJGE
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
 Timing buffer-cache reads:   128 MB in  0.82 seconds =155.91 MB/sec
 Timing buffered disk reads:  64 MB in  2.10 seconds = 30.45 MB/sec

Draai trouwens al ruim een half jaar xfs zonder prblemen

[ajvdvegt]

code:

/dev/hda:
Model=QUANTUM FIREBALL CX20.4A BuffSize=418kB
UDMA modes: udma0 udma1 *udma2 udma3 udma4
 Timing buffer-cache reads:   128 MB in  1.27 seconds =100.79 MB/sec
 Timing buffered disk reads:  64 MB in  3.45 seconds = 18.55 MB/sec

Op een dual celeronnetje@400Mhz. Die buffer-cache reads zijn vrij laag . Ik krijg 'm niet op umda4 ('hdparm -X 68 /dev/hda') trouwens, daarvoor zal ik 'm wel aan m'n highpoint controller moeten hangen . En ik weet ook niet zeker of dat de performance gaat verhogen, gezien de opmerkingen in deze discussie.

Ik gebruik al ruim een jaar XFS zonder problemen trouwens. In het begin ging het herstellen van bestanden nog wel eens mis (ze werden gevuld met chr(255), waar slechts weinig programma's tegen kunnen ), maar dat lijkt nu opgelost (ik test het niet echt vaak gelukkig ).

[ Voor 0% gewijzigd door ajvdvegt op 16-10-2002 16:04 . Reden: XFS vergeten ]

[_JGC_]

buffer-cache reads geven niet de snelheid van je disk of controller aan, maar eerder de snelheid van je geheugen. Het benchmarkt nml de diskbuffers die linux aanmaakt.

[Verwijderd]

Verwijderd schreef op 16 oktober 2002 @ 11:24:
ik was bij een pc vergeten using_dma aan te zetten(hdparm -d 1 /dev/hda). van 5 MB/sec naar 9 MB/sec....toch bijna een verdubbeling in snelheid. zijn er nog meer tips om je hdd en/of fs sneller te maken?

En wat d88 jullie van deze beredenatie:

code:

/                       ext3 vanwege backwards/forwards 
compatibiliteit en standaard in 2.4 kernels
/var/run            reiserfs, zie post dystopia
/var/spool        reiserfs, zie post dystopia
/films                XFS, zie post im_ik
/iso                   XFS, zie post im_ik
/usr/bin             XFS, zie post _JGC_

en software RAID en/of LVM is dat echt veel sneller?
ACL wordt niet gesupport door ReiserFS toch? wel door XFS? wel door Ext3? Is het echt nuttig?

het is onzin en disk verspilling om /var/run als reiserfs te maken. Reiserfs heeft een overhead van +/- 33M als ik me niet vergis, en dat is een beetje teveel als je bedenkt dat /var/run over het algemeen alleen maar pid files bevat (of hoort te bevatten). Mijn /var/run (debian x86 workstation) is 104K groot...

en om het compleet te maken, hier mijn stats:

code:

misato [r3boot]$ sudo hdparm -tT /dev/discs/disc0/disc
/dev/discs/disc0/disc:
 Timing buffer-cache reads:   128 MB in  0.88 seconds =145.45 MB/sec
 Timing buffered disk reads:  64 MB in  5.19 seconds = 12.33 MB/sec

misato [r3boot]$ sudo hdparm -tT /dev/discs/disc1/disc
/dev/discs/disc1/disc:
 Timing buffer-cache reads:   128 MB in  0.88 seconds =145.45 MB/sec
 Timing buffered disk reads:  64 MB in  2.20 seconds = 29.09 MB/sec

misato [r3boot]$ dmesg |grep hd[ac]|grep sect
hda: 6346368 sectors (3249 MB) w/256KiB Cache, CHS=787/128/63, UDMA(33)
hdc: 19531250 sectors (10000 MB) w/2048KiB Cache, CHS=19376/16/63, UDMA(33)

[ Voor 0% gewijzigd door Verwijderd op 16-10-2002 16:33 . Reden: excuses voor de layout ]

[Ronald]

Verwijderd schreef op 16 oktober 2002 @ 05:49:
RonaldH: leuk dat je ook de filesystem versies erbij zet, nu is het tamelijk nutteloos. Alle developers van de besproken FSen (behalve Ext2FS?) werken hard aan de verschillende FSen en er zijn constant veranderingen. Dat betekend niet per definitie dat het beter/stabieler loopt en dat er optimalisaties op bepaalde fronten zijn maar 't is wel mogelijk. Aangezien je de versies er niet bij zet kan nu niemand onderzoeken hoe de huidige stand van zaken mogelijk en/of inschatten of er nu belangrijke veranderingen/optimalisaties zijn en zo ja welke.

Ik geef de gebruikte kernel versie, dan weet je in princiepe ook welke versies van de filesystemen er bij zaten, veel plezier ermee.

Zie ook de verschillende testresultaten op het internet. Te vinden met o.a. Google. Let er wel op dat ze de versies erbij zetten want dat is belangrijk. Zo kun je ook op Linux schelden dat-ie onstabiel is met je gloednieuwe fikker.. terwijl je een 1.x versie draait..

O? dan vind jij meer dan ik. Geef de links eens waarbij er vergelijkende benchmarks uitgevoerd worden (en niet de reiserfs benchmarks op namesys)