NTFS vs EXT3 vs REISERFS vs XFS

[WAntilles]

Χρειάζεσαι τα πακέτα xfsprogs & xfsdump.

Το φτιάχνεις έτσι:

http://www.adslgr.com/forum/showthre...60950&garpg=29

Το κάνεις mount με options:

noatime,logbufs=8

[point456]

tnks το φτιαχνω να δω τι θα μου δωσει απο επιδοση

[anon]

Γιατί το λες αυτό - εάν επιτρέπεται;
Αφού έχει journal.

Το filesystem journaling γίνεται βασικά με δύο τρόπους. Metadata ή full data. Στην πρώτη περίπτωση δεν διασφαλίζονται τα data, αλλά τα χαρακτηριστικά του αρχείου. Δηλαδή ότι δεν θα το χάσεις, αλλά μπορεί να χάσεις data. full data είναι ότι διασφαλίζουμε την εγγραφή των δεδομένων. Οπως τα transactions στις βάσεις δεδομένων.

Τώρα όλα τα journaled filesystems συνήθως υποστηρίζουν και τις δυο μορφές, αλλά δίνουν βαρυτητα σε μια εξ αυτών. To reiserfs βασικά λειτουργεί με metadata only. Αυτό το κάνει πολύ γρήγορο. Εαν διαλέξεις full data θαναι πιο αργό απο το ext3 (να γιατί η Oracle αποτρέπει την χρήση reiserfs και προτείνει μόνο ext3).

Περισσότερα εδώ.
http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc

[holyghost]

Γιατί το λες αυτό - εάν επιτρέπεται;



Γιατί το λες αυτό - εάν επιτρέπεται;

Αφού έχει journal.

Τα XFS JFS ZFS πάντα τα μπέρδευα. Ποιό είναι ποιό. Ένα είναι της IBM, άλλο της SUN, και το 3ο ποιανής είναι;

Πάντως στο ίδιο hardware, εκεί όπου πριν με reiser 3.6 έδινε μέσο sustained transfer rate κάτι πάνω από 15 MByte/sec τώρα δίνει πάνω από 25 με XFS.

Όπως είπα και παραπάνω κάθε σύστημα αρχείων είναι για διαφορετική δουλειά.

Κατα κόρον τα enterprise συστήματα αρχείων χρησιμοποιούν metadata journals, πολύ απλά για λόγους ταχύτητας, αποθηκευτικού χώρου και ασφάλειας. Τα JFS, XFS κάνουν metadata journaling, δηλαδή δεν παίρνουν και τπτ σοβαρές προφυλάξεις για να διαβεβαιώνουν ότι τα δεδομένα τα κατάφεραν μέχρι το δίσκο τελικά, πριν γραφτούν τα metadata. Το ίδιο παθαίνει και το reiser.

Πρόσεξε όμως!!!!!!
Με το reiser ένα απρόσμενο reboot μπορεί να έχει ως αποτέλεσμα τα πιο πρόσφατα αρχεία που επεξεργάστηκες πριν το reboot να περιέχουν κομμάτια απο διαγραμμένα αρχεία πριν το reboot.
Θεικό ε;;; Εκτός απο την απώλεια δεδομένων είναι και μεγάλη τρύπα ασφαλείας.

Απ' την άλλη τα XFS,JFS εξασφαλίζουν ότι κάθε άγραφο block δεδομένων τιγκάρεται με μηδενικά κατα την επανεκκίνηση όταν γίνεται replay του journal. Κατά συνέπεια, τα missing blocks γεμίζουν με άχρηστα (null) bytes εξαλείφοντας την τρύπα ασφαλείας. Όσον αφορά την απώλεια δεδομένων τώρα, ελαχιστοποιείται κατα πολύ σε σχέση με το reiser μιας και γράφουν πολύ πιο συχνά τα εκκρεμή metadata updates στον δίσκο., ειδικά σε φάσεις μεγάλου φόρτου. Με λίγα λόγια με τα XFS,JFS χάνεις λιγότερα δεδομένα απο το reiser.
Νομίζω ότι είναι μια πιο ασφαλής προσσέγγιση.

Δηλαδή εάν εκεί που δουλεύεις σου τη βαρέσει και τραβήξεις το φις απο την πρίζα, το ξαναβάλεις και εκκινήσεις το pc θα εκπλαγείς βλεποντας πως οι καταλόγοι-αρχεία βρίσκονται σε πολύ συνεπής κατάσταση. Θα μπορείς δηλαδή να κάνεις ls στους καταλόγους και να δεις περιεχόμενα. Δεν θα σου χαλάσει το filesystem δηλαδή.
Εντούτοις, πιθάνότατα έχασες τα δεδομένα απο αρχεία που ήταν ανοιχτά πριν τραβήξεις το καλώδιο.
Ακόμα και ειδικά filesystems όπως το OCFS2 (Oracle Clustered filesystem v2) χρησιμοποιούν metadata journaling.

Βασικά τα XFS,JFS τα βρίσκω πολύ διασκεδαστικά, ως σύστηματα αρχείων. Έχουν ένα πολύ γλυκό τρόπο αυτοκαταστροφής ο οποίος ενεργοποιείται μόλις υπάρξει απώλεια ενέργειας. Όλως τυχαίως για το XFS ενεργοποιήθηκε στους πυρήνες 2.6.17 (ψάξτο)

Επίσης είναι φτιαγμένα για μεγάλα συστήματα τα άτιμα... Δεν μπορούν να σμικρυνθούν. Δηλαδή άμα τα έχεις σε LVM χέσε μέσα πολυχρόνη που δε γίναμε ευζώνοι. Οι devels του XFS είχαν ως μοτο το "think big" (ναι, είναι αλήθεια!!!!)

Αν θυμάμαι καλά grub<0.90 η 0.91 δεν μπορούν να μπουτάρουν XFS. Αυτό έχει λυθεί βέβαια, αν και νομίζω πως ακόμη και σήμερα ο grub δεν μπορεί να μπουτάρει αν έχει εγκατασταθεί σε xfs partition αντί στο MBR ας πούμε. (λυνεται απλά με /boot σε ext2). Κάποιος μου έλεγε ότι το ubuntu δεν επιτρέπει το /boot σε XFS.

Επίσης ξέχνα την επαναφορά αρχείων με το XFS. Είναι σχεδόν ακατόρθωτο (αν και αυτό είναι και καλό συνάμα).

To JFS είναι un-tune-able. Δεν έχει περιθώρια βελτίωσης απο το χρήστη (δουλεύει γαμιστερά απο την μάνα του...χεχεχ ) . Το XFS θέλει και τα mount-options του για να δουλεψει επιιθυμητά.

Στο XFS για linux υπάρχουν σημάδια ασυμβατότητας μεταξύ διαφορετικών αρχιτεκτονικών. Δηλαδή χρησιμοποείς έναν δίσκο με XFS στον x86_64 και τον μεταφέρεις σε κάποιο μηχάνημα x86. Λύνεται βέβαια κάνοντας ένα xfs_repair για να καθαρίσει το journal πριν γίνει η προσάρτηση στο νέο σύστημα.

Εάν θες γρήγορη δημιουργία fs και mounting-unmounting και γρήγορες διαδικασίες σε μεγάλα αρχεία, επιλέγεις XFS η JFS με το JFS να καταναλώνει λιγότερους πόρους. Εάν θες maximum-capacity τότε reiserfs. Στα μικρά αρχεία (<1kb) τα XFS,JFS τα ψιλοσκατώνουν. Εκεί το reiser είναι μονόδρομος για το linux.
Εάν γουστάρεις η find να πάρει κλήση για υπερβολικη ταχύτητα τότε:
1. πολύ γρήγορο με μεγάλη κατανάλωη cpu --> reiserfs, XFS
2. πιο αργό αλλά με μικρότερη κατανάλωση cpu --> ext3, JFS

Εγώ ο λόγος που προτιμώ JFS από XFS είναι η υψηλή χρήση cpu εκ μέρους του XFS (πάντα παραμένει μικρότερη από του reiser). Το JFS παραμένει ελαφρύ για την cpu ακόμα και σε μεγάλα h/d loads. Είναι δύο συστήματα που ενώ μοιάζουν πολύ στη συμπεριφορά, διαφέρουν στη θεωρία και την κατασκευή. Ένα κοινό τους είναι ότι και τα δύο είναι 64bit Αυτό επηρεάζει κυρίως το μέγιστο τους μέγεθος (άλλο σε 32bit συστήματα και άλλο σε 64bit). Το xfs έχει σε 32bit max 16TB και σε 64bit max 9exabytes (φυσικά με πολύ μικρό block size). Ενημερωτικά το XFS είναι απο τα αρχαιότερα jounaling file systems.

Γενικά απο ότι παρατηρώ όλα τα καινούργια συστήματα (η οι μετεξελίξεις) αρχείων έχουν εμπνευστεί απο τα transactions των βάσεων δεδομένων.

Επίσης δε προτιμώ reiserfs (καμία έκδοση του) λόγω ηλίθιου data loss σε παλιότερες εκδόσεις και λόγω cpu initialization στην 4η σειρά. Δηλαδή ένας 500άρης Celeron θα είναι τρελό bottleneck. Αν και έχει κάτι plugins που τα σπάνε (βλ. default on the fly συμπίεση και κωδικοποίηση των αρχείων)

Και για να μη μπερδεύουμε τα μπούτια μας
JFS = IBM
XFS = Silicon Graphics Inc. (SGI)
ZFS = Sun (Solaris και OpenSolaris) - αυτό είναι αλλουνού παπά ευαγγέλιο -

sorry για το μεγάλο post.

[point456]

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

[WAntilles]

Ωραιότατος.

Πάντως αυτά που έλεγες για το reiser και την περίπτωση power loss, λογικά ισχύουν για το 3.6 και όχι για το 4, μιας και το τελευταίο έχει στα χαρακτηριστικά του:

- atomic writes -> a file is either written entirely or not written at all

[Slammer]

Καλά, αυτός ο Reiser, γιατί σκοτωσε (κατηγορείται) τη γυναίκα του? Μηπως τον ενοχλούσε και δεν μπορούσε να τελειώσει την εκδοση 4?
Οπως και να έχει το reiserfs 4 εχει πάρει το δρόμο του, για ενσωμάτωση στον πυρήνα επισήμως. Αυτό σημαίνει ότι η διαδικασία ανάπτυξης δεν είναι πια προσωπική υπόθεση του κ. Reiser... Επίσης πολύ καιρό τωρα υπάρχει σε patchset και το χρησιμοποιεί πολύς κόσμος.

και ενα αρθράκι για συγκριση μεταξύ fs : http://www.debian-administration.org/articles/388

[WAntilles]

Οπως και να έχει το reiserfs 4 εχει πάρει το δρόμο του, για ενσωμάτωση στον πυρήνα επισήμως.

Άντε να γίνει επιτέλους ώστε όλα τα "/", και τα repositories εδώ πέρα να περάσουν σε Reiser4.

[pelasgian]

μπορεις να κανεις recover files με αυτο το file system(ext3)? και πώς αν πχ καταλαθως κανεις format. στο REISERFS νομιζω γινεται αν και δεν ξερω τον τρόπο

Εγώ πάντως το έχω για ΑΥΤΟ το λόγο.
Αν σβύσεις κάτι, οφείλεις να το βρεις σε backup, αν όμως σβύσεις κάτι και θέλεις να μείνει σβυσμένο, τότε οφείλει να μην μπορεί να βρεθεί ΜΕ ΤΙΠΟΤΑ.
(εγώ μηδενίζω που και που και τον ελεύθερο χώρο στο δίσκο, όπου μπορεί να υπάρξουν υπολείμματα αρχείων και σε ορισμένες περιπτώσεις βάζω και safe delete.)(

Με άλλα λόγια, αυτό που θεωρείς ως «μειονέκτημα», άμα το «λύσεις» να μας πεις, για να αλλάξουμε format!

[point456]

Με άλλα λόγια, αυτό που θεωρείς ως «μειονέκτημα», άμα το «λύσεις» να μας πεις, για να αλλάξουμε format!

Χρησιμοποιείς reiserfs η ext3? Τα πλεονεκτήματα και μειονεκτήματα δεν τα γνωρίζω είναι και ένας λόγος που ήθελα να ανοίξω αυτή την συζήτηση να τα μάθω, εγώ αλλά και όποιος το διαβάζει. Κοίτα να δεις τι συμβαίνει στο δικό μου σύστημα. Έχω το /root σε ext3, έστω και διαγράψω ένα αρχείο από το σκληρό το αρχείο αυτό δεν είναι διαγραμμένο απλά υπάρχει με μια κατάληξη ~ στο τέλος και αυτό το βλέπω μόνο αν μπώ σαν root. Αν το σβήσω σαν root τότε παύει να υπάρχει. Fafe delete πώς το ενεργοποιείς και το ανάστροφο? Το μόνο που γνωρίζω είναι η εντολή chmod a+w -R όπου δηλώνεις τα δικαιώματα να γράφεις σβήνεις . Κατα την γνώμη σου ποιο ειναι το ποιο ευέλικτο(ότι και αν υπάγεται σ' αυτό) forma?

[holyghost]

Χρησιμοποιείς reiserfs η ext3? Τα πλεονεκτήματα και μειονεκτήματα δεν τα γνωρίζω είναι και ένας λόγος που ήθελα να ανοίξω αυτή την συζήτηση να τα μάθω, εγώ αλλά και όποιος το διαβάζει. Κοίτα να δεις τι συμβαίνει στο δικό μου σύστημα. Έχω το /root σε ext3, έστω και διαγράψω ένα αρχείο από το σκληρό το αρχείο αυτό δεν είναι διαγραμμένο απλά υπάρχει με μια κατάληξη ~ στο τέλος και αυτό το βλέπω μόνο αν μπώ σαν root. Αν το σβήσω σαν root τότε παύει να υπάρχει. Fafe delete πώς το ενεργοποιείς και το ανάστροφο? Το μόνο που γνωρίζω είναι η εντολή chmod a+w -R όπου δηλώνεις τα δικαιώματα να γράφεις σβήνεις . Κατα την γνώμη σου ποιο ειναι το ποιο ευέλικτο(ότι και αν υπάγεται σ' αυτό) forma?

Όσον αφορά το rm και την περισπωμένη που είπες, εγώ δεν έχω δει πουθενά στον manual της rm να λέει "μόνο ο superuser δικαιούται να σβήνει με την πρώτη τα αρχεία, στον χρήστη τα κάνουμε τσουρέκια και του το ξαναπετάμε με μια ~". Όταν ως χρήστης παρατήρησες πως όταν έκανες rm σε ένα αρχείο μετά με ls έβλεπες το ίδιο με μια περισπωμένη, ήταν απλά τυχαίο. Το αρχείο με την περισπωμένη παράχθηκε απο τον text editor φεριπήν (κατά την επεξεργασία, όχι την δημιουργία του αρχείου), ο οποίος έχει ενεργοποιημένο το auto-save η backup.
Τσέκαρε το.

Στο linux γενικά το deletion είναι απλά μια πλάνη, τουλάχιστον μέχρι το επόμενο reboot η τις ενέργειες του με @@@ admin .
Στα linux filesystems ένα αρχείο είναι απλά ένας σύνδεσμος σε ένα inode, το οποίο περιέχει όλες τις ιδιότητες του αρχείου όπως δικαιωματα χρήσης, ιδιοκτησία και παράλληλα τις διευθύνσεις των μπλοκ δεδομένων στα οποία είναι αποθηκευμένα τα περιεχόμενα του αρχείου στο σκληρό.

Όταν λοιπόν κάνεις rm σε ένα αρχείο, απλά αφαιρείς το δεσμό στο inode. όχι το ίδιο το inode, άλλες διεργασίες (όπως ένας επεξεργαστής κειμένου, η music player) μπορεί να το κρατάνε ακόμα ανοιχτό.
Εφόσον λοιπόν υπάρχει εφαρμογή που κρατάει το αρχείο ακόμα ανοικτό τότε μπορείς να το σώσεις.
Εδώ μπαίνει στο παιχνίδι το εικονικό σύστημα αρχείων proc (process pseudo-filesystem). Κάθε διεργασία του συστήματος μας έχει μία καταχώρηση (κατάλογος συνήθως) στο /proc με το όνομα της, μέσα στον οποίο υπάρχουν πολλά σημαντικά πράματα (ψάξτε τα)όπως ο υποκατάλογος fd (file descriptor) ο οποίος περιέχει links για όλα τα αρχεία που κρατά ανοιχτά αυτή η εφαρμογή. Ακόμα και άν έκανες rm στο αρχείο τα δεδομένα θα βρίσκονται εκεί:

/proc/pid/fd/file descriptor

Για να ξέρεις που θα κοιαξεις πρέπεις να βρείς το pid (process identification) η οποία το κρατά ανοιχτό και file decriptor.

δημιουργείς το αρχείο --> touch arxeio
του βάζεις δεδομένα --> echo data data data data >> arxeio
Είναι σίγουρα εκεί;; --> ls -l arxeio η stat arxeio
το διαβάζεις με τον pager less --> less arxeio
κάνεις suspend τον less --> πατάς ctrl+z *****
και τέλος σβήνεις το αρχείο --> rm arxeio
Τσεκάρεις αν υπάρχει χρησιμοποιόντας την ls και την stat.

***** Η εφαρμογή δεν τερματίστηκε. Αν τύχει το ίδιο σκηνικό με ένα video που παίζει στον mplayer ας πούμε, τότε αυτό που πρέπει να κάνεις μόλις πάρεις πρέφα πως το έσβησες είναι να κάνεις pause στον mplayer ώστε να αποφύγεις την έξοδο του προγράμματος.

Χρησιμοποιούμε την μαγική εντολή lsof (list open files), η οποία είναι απο τις πιο χρήσιμες στο administration σε πολυχρηστικά μηχανήματα. Εγώ την εκτιμώ πάρα πολύ ως έντολή.
- Σου λύνει τα χέρια και τα πόδια των χρηστών μόλις τους στέλνεις mail και τους λές "κύριε σε τι ακριβώς χρησιμεύει το πρόγραμμα dd που τρέχετε το οποίο ακούει στην 15567 πόρτα τραβάει απο τους τάδε σέρβερς το αρχείο lolitas 17...mpg;;;" -

Δίνουμε ένα lsof | grep arxeio έχουμε ώς έξοδο κάτι τέτοιο:

less 4422 holyghost 4r REG 3,5 119620 16732 /home/holyghost/arxeio (deleted)

To less είναι η διεργασία που κρατά το αρχείο, το 4422 είναι το pid και το 4r είναι το file descriptor που λέμε (το r σημαίνει regular file).
Οπότε κάνουμε ls -l /proc/4422/fd/4 και έχουμε έξοδο:

lr-x------ 1 holyghost users 64 Dec 23 19:01 /proc/4422/fd/4 -> /home/holyghost/arxeio (deleted)

Με ένα απλό cp (προσοχή!!! ποτέ με -a flag) cp /proc/4422/fd/4 arxeio_restored έχεις το αρχείο που κατά λάθος έσβησες. Αν το κάνεις ως τεστ χρησιμοποίησε και την cmp απλά για να τσεκάρεις το original με το restored.

Τα υπόλοιπα που σου είπε ο pelasgian (γέμισμα με μηδενικά κτλ) γίνονται κυρίως με την εντολή dd.

[holyghost]

Ωραιότατος.

Πάντως αυτά που έλεγες για το reiser και την περίπτωση power loss, λογικά ισχύουν για το 3.6 και όχι για το 4, μιας και το τελευταίο έχει στα χαρακτηριστικά του:

- atomic writes -> a file is either written entirely or not written at all

Ναι ακριβώς. Μιλάω κυρίως για το 3.6.
Για το 4 το μόνο που ξέρω μετά απο ένα ψιλοτεστάκι που έκανα είναι το υψηλο cpu-consuming. Κατά τα άλλα δεν έχω ασχοληθεί πολύ ακόμα επίτηδες. Περιμένω να μπεί mainline και μετά απο κανα 2-3 χρόνια θα κριθεί αξιόλογα πιστεύω. Τώρα είναι νωρίς.

[sdn]

Το ReiserFS είναι στη φυλακή με την κατηγορία της δολοφονίας:

http://linux.slashdot.org/article.pl.../12/22/0334259

Το zenwalk δεν το υποστηρίζει πια (μέχρι νεοτέρας)

Το xfs νομίζω οτι είναι το καλύτερο fs to date. Αν ψάξετε θα βρείτε πολλά τεστς. Εγώ μιλάω από προσωπική αίσθηση ταχύτητας + δεν έχω ουτε 1 kb χαμένα δεδομένα. Βέβαια λόγο zenwalk δεν υπάρχουν hard resets

[WAntilles]

Το zenwalk δεν το υποστηρίζει πια (μέχρι νεοτέρας)

Δεν υπήρχε κανένας μα κανένας λόγος να προβεί σε τέτοια κίνηση.

Το reiserfs 3.6 έχει γίνει vanilla mainstream εδώ και πολλά χρόνια και ο έλεγχος έχει περάσει στους kernel devs.

[george_apan]

Έχω την εντύπωση πως ο sdn αναφέρεται στο Reiser4 και όχι στο ReiserFS 3.6.