Linux filesystems benchmarks

[GoofyX]

Σε συνέχεια από εδώ, αλλά επειδή θεωρώ ότι είναι ξεχωριστό ως θέμα, ορίστε τα benchmarks που έκανα στο νέο μου δίσκο.

Προδιαγραφές συστήματος: Gentoo Linux x86_64, πυρήνας 2.6.26-gentoo-r1 (vanilla 2.6.26.2 + gentoo patchset), modules για τα filesystems ενσωματωμένα στον πυρήνα, Intel Core2 E8400 με P35 chipset, 4GiB RAM, δίσκος WD6400AAKS.

Λογισμικό:

mkfs.ext3  -V
mke2fs 1.40.9 (27-Apr-2008)
	Using EXT2FS Library version 1.40.9

mkfs.reiserfs -V
mkfs.reiserfs 3.6.19 (2003 www.namesys.com)

mkfs.xfs -V
mkfs.xfs version 2.9.7

mkfs.jfs -V
mkfs.jfs version 1.1.8, 03-May-2005

Οι μετρήσεις έγιναν με το bonnie++ 1.93c. Η γραμμή εντολής που χρησιμοποιήθηκε είναι:

bonnie++ -d /media/test -n 50:204800:0:30000 -u 1000

που σημαίνει:

• Τρέξε το τεστ στο /media/test (το mounted partition)
• Χρησιμοποίησε 50*1024 αρχεία με μέγεθος από 0 έως 204800 (200ΚiB) και δημιούργησε 30000 καταλόγους
• Τρέξε κάτω από το χρήστη με UID 1000 (εμένα), χρειάζεται επειδή το έτρεχα ως root

Το partition είχε μέγεθος 415GiB. Κατά σειρά έγινε format ως εξής:

mkfs.ext3 /dev/sda10  (ext3)
mkfs.xfs /dev/sda10 (xfs1)
mkfs.xfs -d agcount=16 -f /dev/sda10 (xfs2)
mkfs.xfs -d agcount=32 -f /dev/sda10 (xfs3)
mkfs.jfs /dev/sda10 (jfs)
mkfs.reiserfs --format 3.6 -f /dev/sda10 (reiserfs)

Σε παρένθεση αναφέρω το label στα γραφήματα. Το partition γινόταν mounted κάθε φορά με τις παραμέτρους noatime,nodiratime και στην περίπτωση του XFS, προστίθονταν η παράμετρος logbufs=8.

Στο συνημμένο PDF θα βρείτε τις μετρήσεις από την έξοδο του bonnie++. Το σημαντικότερο μάλλον είναι η πρώτη σελίδα που μετράει διαμεταγωγή (K/sec).

Μάλλον θα εκπλαγείτε από τα αποτελέσματα και το τι ξέραμε μέχρι τώρα...

Δείτε το και περιμένω τα σχόλιά σας.

Θα ακολουθήσουν και άλλες μετρήσεις σε μικρότερο partition ~18GiB.

[ludist]

Τρομερή δουλειά, ευχαριστούμε για τον κόπο σου!

Προσωπικά θα προτιμούσα ένα test πραγματικό. Δηλαδή time make -j 8 bzImage

<rant>
και μου την δίνει η απουσία των *atime
</rant>

[arkara]

Πολύ πολύ καλή η δουλειά σου

[mrsaccess]

Τι έκανες βρε τρελέ; Έκατσες και έφτιαξες και διαγράμματα;;;

Ωραίο bench! Μου θύμισε επίσης πως ένας λόγος που προτιμώ ext3 για κρυπτογραφημένα partition είναι και οι μικρότερες απαιτήσεις του σε CPU.

Πάντως γενικά, βλέπω το ext3 τα πάει μια χαρά. Στα μεγάλα αρχεία τα χαλάει και στην ταυτόχρονη ανάγνωση/διαγραφή νομίζω.

[arkara]

Τι έκανες βρε τρελέ; Έκατσες και έφτιαξες και διαγράμματα;;;

Ωραίο bench! Μου θύμισε επίσης πως ένας λόγος που προτιμώ ext3 για κρυπτογραφημένα partition είναι και οι μικρότερες απαιτήσεις του σε CPU.

Πάντως γενικά, βλέπω το ext3 τα πάει μια χαρά. Στα μεγάλα αρχεία τα χαλάει και στην ταυτόχρονη ανάγνωση/διαγραφή νομίζω.

Γενικά το ext3 είναι ένα αρκετά ώριμο filesystem.. και σε λίγα χρόνια που θα έχουμε και το ext4 ποιός μας πιάνει!

[KoukosNest]

Ωραιος ο GoofyX

καλα τα πηγε το jfs k xfs2

[dhatz]

Καλή δουλειά ΓοοφυΧ, αλλά νομίζω ότι τέτοια αποτελέσματα εξυπηρετούν περισσότερο για να δούμε πως πάει με το default configuration του καθενός mkfs (το οποίο κατά περιόδους αλλάζει ακόμα και μεταξύ distribution).

Γιατί ως γνωστόν τα XFS & JFS κάνουν journaling μόνο τα metadata (με τα γνωστά προβλήματα σε unclean shutdown), ενώ το ext3 και τα data.

Για άμεσες συγκρίσεις βάζουμε το ext3 με data=writeback.

[anon]

σωστός ο dhatz.Για να είμαστε σωστοί, θαθελα να δώ τα τεστ, έχοντας στο ext3 αυτή τη παράμετρο (όπως επίσης και τις άλλες, noatime πχ που μειώνουν την χρηση του δίσκου).

[WAntilles]

Γενικά το ext3 είναι ένα αρκετά ώριμο filesystem.

Καλά άθλιο filesystem της σπηλιάς είναι από το ice age.

Άντε να το σκοτώσουν να ησυχάσουμε.

[GoofyX]

Ωραιος ο GoofyX

καλα τα πηγε το jfs k xfs2

Εγώ βλέπω ότι το JFS πάει πάρα πολύ καλά, καλύτερα από το XFS. Όπως επίσης και το ext3, παραπάνω από μια χαρά είναι. Το XFS με απογοήτευσε λίγο.

Καλή δουλειά ΓοοφυΧ, αλλά νομίζω ότι τέτοια αποτελέσματα εξυπηρετούν περισσότερο για να δούμε πως πάει με το default configuration του καθενός mkfs (το οποίο κατά περιόδους αλλάζει ακόμα και μεταξύ distribution).

Γιατί ως γνωστόν τα XFS & JFS κάνουν journaling μόνο τα metadata (με τα γνωστά προβλήματα σε unclean shutdown), ενώ το ext3 και τα data.

Για άμεσες συγκρίσεις βάζουμε το ext3 με data=writeback.

Από ότι βλέπω, το default mount option για το ext3 είναι data=ordered, που σημαίνει:

ordered
This is the default mode. All data is forced directly out to the main file system prior to its metadata being committed to the journal.

Δηλαδή, θα πρέπει να βάλω data=writeback, προκειμένου να πλησιάσει τη λογική των XFS & JFS;

writeback
Data ordering is not preserved - data may be written into the main file system after its metadata has been committed to the journal. This is rumoured to be the highest-throughput option. It guarantees internal file system integrity, however it can allow old data to appear in files after a crash and journal recovery.

σωστός ο dhatz.Για να είμαστε σωστοί, θαθελα να δώ τα τεστ, έχοντας στο ext3 αυτή τη παράμετρο (όπως επίσης και τις άλλες, noatime πχ που μειώνουν την χρηση του δίσκου).

Μα, το αναφέρω στο πρώτο μήνυμα ότι σε όλες τις περιπτώσεις γίνεται με noatime,nodiratime για όλα τα filesystems.

Θα επανέλθω με update για το ext3 με data=writeback. Σε κάποια φάση είχα βάλει παράμετρο 32000 για τα directories και το bonnie++ χτύπησε, γιατί το fs έφτασε στο όριό του.

[nstamoul]

Καλά άθλιο filesystem της σπηλιάς είναι από το ice age.

Άντε να το σκοτώσουν να ησυχάσουμε.

Τεκμηριωμένη όπως πάντα η άποψή σου.
Ξέρω,ξέρω κρατάει 10% για το root....

[WAntilles]

Ξέρω,ξέρω κρατάει 10% για το root....

Και 30 δευτ. για να σβήσει απλά ένα αρχείο μεγάλου μεγέθους.

[imitheos]

Η λειτουργία των άλλων fs είναι πιο κοντά στην ordered από ότι στην writeback
επομένως το benchmark του GoofyX είναι σωστό.

Το JFS όντως αποδεικνύεται πολύ καλό σε όλα τα benchmarks που έχω διαβάσει κατά
καιρούς. Καλές ταχύτητες και πολύ μικρή χρήση επεξεργαστή.

Το JFS έχει δύο μόνο "προβλήματα":

1) Όπως και στο XFS δεν μπορεί να γίνει σμίκρυνση της κατάτμησης οπότε δεν
συνιστάται η χρήση του σε LVM (Με ReiserFS ή ext3 για παράδειγμα αν έχουμε
/usr 10G και /var 5G και μας τελειώσει ο χώρος στο /usr μπορούμε να μικρύνουμε το
/var κατά 1G και να το δώσουμε στο /usr)

2) Υπήρχε ένα πρόβλημα το οποίο έχει αναπαραχθεί από πολλούς χρήστες και υπό
άγνωστες συνθήκες και όχι πάντα, όταν δεν έκλεινε σωστά ο υπολογιστής χανόταν
το /usr/man/man3.

Το πρόβλημα αυτό εντοπίστηκε στο ArchLinux στο Δεκέμβριο του 2007. Από τότε
δεν έχω διαβάσει κάτι νεότερο και μπορεί να έχει λυθεί κιόλας.
Ιστοσελίδα : http://bbs.archlinux.org/viewtopic.php?id=41261

Γενικά αν εξαιρέσουμε την δυνατότητα σμίκρυνσης είναι μια πολύ καλή λύση.

Το ext3 τώρα που έβρισε ο Wantilles (κλασικά) είναι όντως πολύ ώριμο και πολύ
παρεξηγημένο.

1) Είναι το μόνο που καταχωρεί και τα δεδομένα (data=journal) και μάλιστα ενώ θα
περιμέναμε τρομερή μείωση στην ταχύτητα σε κάποια benchmarks (σε βάσεις
δεδομένων αν θυμάμαι καλά) παρατηρήθηκε αύξηση στην ταχύτητα.

2) Το 5% που κρατάει από την χωρητικότητα είναι ώστε να μπορούν να μη γεμίσει ο
χώρος και σταματήσει να λειτουργεί το σύστημα. Παλαιότερα, ήταν πολύ χρήσιμο
που οι δίσκοι ήταν πολύ μικροί και ουσιαστικά δεν χάνεται. Εφαρμογές που τρέχουν
ως root χρησιμοποιούν τον χώρο κανονικά. Αν πρόκειται για κατάτμηση /home π.χ
που δεν μας ενδιαφέρει απενεργοποιείται πάρα πολύ εύκολα (-m 0)
Ακόμη αυτός ο δεσμευμένος χώρος χρησιμοποιείται για την αποφυγή κατακερματισμού.

3) Ο κατά πολύ μειωμένος χώρος της κατάτμησης είναι λόγω της δέσμευσης πάρα
πολλών i-nodes κατά την δημιουργία. Και αυτό μπορεί να αλλάξει ώστε να δεσμεύει
λιγότερα.

[arkara]

Και 30 δευτ. για να σβήσει απλά ένα αρχείο μεγάλου μεγέθους.

ε και τι έγινε?
πόσο μεγάλο είναι αυτό το αρχείο? και πόσο συχνά σβήνεις εσύ μεγάλα αρχεία?
εμένα δεν με πειράζει..
κάποιο άλλο επιχείρημα έχεις έχεις για να μην το χρησιμοποιώ

[imitheos]

ε και τι έγινε?
πόσο μεγάλο είναι αυτό το αρχείο? και πόσο συχνά σβήνεις εσύ μεγάλα αρχεία?
εμένα δεν με πειράζει..
κάποιο άλλο επιχείρημα έχεις έχεις για να μην το χρησιμοποιώ

Πειράζει όταν θες να γίνει κάτι σε πραγματικό χρόνο. Για παράδειγμα παλαιότερα αυτό
ήταν το νούμερο 1 πρόβλημα για το MythTV. Έγραφε κάτι και έχανε καρέ επειδή
αργούσε να σβηστεί μια παλαιά εγγραφή. Το διόρθωσαν με το να χρησιμοποιήσουν
ένα νήμα που να σβήνει στο παρασκήνιο και να μην επηρεάζει την εγγραφή.

Σε γενικές γραμμές όμως έχεις δίκιο. Δεν μηδενίζουμε ένα σύστημα αρχείων επειδή
"κάνει 30 δευτ. για να σβήσει απλά ένα αρχείο μεγάλου μεγέθους"