Salut Testul lui imi pare cam teoretic. Nu ma intereseaza sa stiu cat ii ia unui FS sa faca sync dupa anumite operatii (arata-mi un sens practic pt asta). In schimb ma intereseaza daca am o structura de mii de directoare si sute de fisiere in fiecare (rezulta milioane si zeci de milioane de fisiere in total) cat de repede este accesul random la fisiere (pt un server de web mare), sau daca servesc video ma intereseaza cat de repede citeste dintr-un fisier mare (de ordinul GB) eventual citind din mai multe asemenea fisiere in acelasi timp, sau daca fac un server de fisiere pt o firma (in general documente intre 64k si 768k) rulez un dbench 100 (100 de clienti simultan) si vad rezultatele etc...
On Mon, 11 Aug 2003, Radu Radoveneanu wrote: > Grant Miner posted some interesting benchmark results to the lkml, = > comparing five journaling filesystems available with the current = > 2.6.0-test2 development kernel. The tests were conducted with a very = > simple shell script, mainly timing how long it takes to copy, tar, and = > remove directories, performing several syncs in between. He summarizes: > > - ext3's syncs tended to take the longest [at] 10 seconds, except > - JFS took a whopping 38.18s on its final sync > - xfs used more CPU than ext3 but was slower than ext3 > - reiser4 had highest throughput and most CPU usage > - jfs had lowest throughput and least CPU usage > > > ce vreau eu sa spun este ca nu-mi vine sa cred afirmatia asta cu xfs-ul > > --=20 > save the ozone layer > > --- > Detalii despre listele noastre de mail: http://www.lug.ro/ > > > ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. --- Detalii despre listele noastre de mail: http://www.lug.ro/
