format σε 4Κ δίσκους

[trd64]

Ποιος είναι ο σωστός τρόπος για τους νέους 4K δίσκους.

Σε λίγο καιρό όλοι οι δίσκοι θα είναι αυτής της μορφής οπότε δεν θα μπορούμε να τους αποφύγουμε.

[imitheos]

Ποιος είναι ο σωστός τρόπος για τους νέους 4K δίσκους.

Σε λίγο καιρό όλοι οι δίσκοι θα είναι αυτής της μορφής οπότε δεν θα μπορούμε να τους αποφύγουμε.

Εδώ και κάμποσο καιρό δεν χρειάζεται να κάνεις τίποτα. Τα fdisk,cfdisk από
την έκδοση 2.17.2 του util-linux-ng (τυπικά από την 2.17 αλλά στις .1 και .2 μπήκαν
κάποια fixes) και το parted ευθυγραμμίζουν στο 1MB οπότε οι κατατμήσεις που
παράγονται είναι βέλτιστες και για 4K και για 128Κ και για 512Κ που χρειάζονται οι SSD.

Σε παλαιότερες εκδόσεις, έχουμε κάποιες επιλογές:
1) Χρησιμοποιούμε custom επιλογές για heads και sectors που να διαιρούνται με το 4Κ.
Έτσι μπορούμε να δημιουργήσουμε κατατμήσεις όπως παλιά (δηλαδή με cylinders)
και να είναι σωστά ευθυγραμμισμένες. Ο Ted Ts'o συνιστά 224 για Heads και 56
για sectors. Έτσι ο κάθε cylinder θα έχει 224*56*512 = 6,422,528 bytes που
διαιρείται με το 4Κ οπότε η κάθε κατάτμηση θα είναι ευθυγραμμισμένη.

2) Οι δίσκοι εδώ και πολλά χρόνια δεν έχουν σταθερό αριθμό τομέων σε όλη
την επιφάνειά τους και έτσι η διευθυνσιοδότηση CHS δεν έχει κανένα νόημα πια.
Οπότε δεν χρησιμοποιούμε καν την αηδία που λέγεται CHS αλλά μόνο τομείς (LBA)
Αν θυμάμαι καλά το cfdisk δεν αναγνωρίζει τέτοιους MBR και λέει ότι είναι corrupted,
οπότε μπορεί να γίνει με το fdisk. Η σύνταξη είναι fdisk -u.

Έπειτα θα μπορούμε να δηλώσουμε απευθείας τομείς. Το DOS ήθελε για κάποιο
λόγο (δεν θυμάμαι γιατί αλλά μάλλον ηλίθιος λόγος θα ήταν) την πρώτη κεφαλή
να είναι άδεια, οπότε η πρώτη κατάτμηση αρχίζει στον τομέα 63 (ο πιο συνήθης
αριθμός τομέων είναι 63 / track). Αυτούς τους τομείς εκμεταλλεύεται και το grub.
Οπότε, αντί να αρχίσουμε την 1η κατάτμηση στο 63 τομέα, την αρχίζουμε στον 64.
Οι επόμενες κατατμήσεις θα δημιουργηθούν με τον ίδιο σκεπτικό.

*** Οι νέες εκδόσεις του fdisk/cfdisk δεν χρησιμοποιούν καν την DOS συμβατότητα
και μπορούν να χρησιμοποιήσουν και τομείς πριν τον 63. Το ίδιο μπορούμε να
χρησιμοποιήσουμε και στις παλιές εκδόσεις πατώντας c στο prompt του fdisk.
Αρκεί να θυμόμαστε ότι το grub χρειάζεται 15 τομείς οπότε καλό είναι να
χρησιμοποιηθεί είτε ο τομέας 32 ή ο 64 για αρχή της 1ης κατάτμησης. ***

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

εδώ είχα γράψει περίπου τα ίδια πριν κάποιο διάστημα

........Auto merged post: imitheos πρόσθεσε 89 λεπτά και 4 δευτερόλεπτα αργότερα ........

Ξέχασα να αναφέρω το σημαντικότερο που είναι τα υποστρώματα (layers επί
το ελληνικότερον). Τα πράγματα είναι πολύ καλύτερα τώρα και δεν είναι αναγκαία
η μανούρα που είχα φάει.

Καταρχήν από την έκδοση 2.6.31 (καλύτερα 2.6.32 και ακόμη καλύτερα 2.6.34),
ο πυρήνας εμφανίζει πληροφορίες για την τοπολογία που μπορούν να εκμεταλλευτούν
τα διάφορα προγράμματα.

1) LVM
Από την έκδοση 2.02.52 (νομίζω, δεν θυμάμαι στα σίγουρα) η ευθυγράμμιση γίνεται
αυτόματα. Σε περίπτωση που θέλουμε να ευθυγραμμίσουμε χειροκίνητα υπάρχει
η παράμετρος --dataalignment που μπορούμε να δώσουμε στην pvcreate.
Από την 2.02.7κάτι ακολουθείται ευθυγράμμιση στο 1MB

2) dmcrypt
Το cryptsetup ευθυγραμμίζει αυτόματα σε 4K οπότε για τους δίσκους δεν χρειάζεται
να κάνουμε τίποτα. πχ αν χρησιμοποιήσουμε aes-xts-plain με 2x256 κλειδιά τότε
τα δεδομένα αρχίζουν μετά από 4040 τομείς. Ο αριθμός 4040 διαιρείται με το 8.
Αν όμως έχουμε RAID ή SSD και θέλουμε να ευθυγραμμίσουμε πχ στα 128K
τότε υπάρχει η παράμετρος --align-payload=τομείς

Από την έκδοση 1.2.0 και έπειτα η μανίσια ευθυγράμμιση γίνεται στο 1MB οπότε
δεν χρειάζεται να πειράξουμε τίποτα σε κανένα σενάριο.

3) RAID
Το md-raid είναι το μόνο που δεν παρέχει δυνατότητα ευθυγράμμισης, το οποίο
είναι πολύ σπαστικό. Η αρχή των δεδομένων αναφέρεται στον header οπότε
δεν είναι fixed in stone απλά το πρόγραμμα mdadm δεν δίνει την δυνατότητα
να επιλέξουμε κάτι διαφορετικό.

Αν επιλέξουμε έκδοση metadata 0.9 ή 1.0 τότε τα δεδομένα βρίσκονται στην αρχή
οπότε δεν επηρεάζεται η ευθυγράμμιση και αν έχουμε δημιουργήσει σωστές
κατατμήσεις δεν υπάρχει κανένα πρόβλημα.

Αν χρησιμοποιούμε metadata 1.1 ή 1.2 τότε στην αρχή βρίσκονται οι πληροφορίες
για το RAID και τα δεδομένα αρχίζουν μετά. Αν δημιουργήσουμε το RAID με mdadm
έκδοσης < 3.1.2, τότε ΔΕΝ θα έχουμε σωστή ευθυγράμμιση το οποίο θα
καταστρέψει και όλα τα layers που θα έχουμε πάνω από το RAID. Όταν είχα
ρωτήσει στη λίστα μου είχαν προτείνει δύο λύσεις. Η μία ήταν να πάω την
κατάτμηση τόσο πίσω όσο πιάνουν τα μεταδεδομένα του RAID. Η άλλη ήταν
να κάνω hex-edit τα μεταδεδομένα και να πάω χειροκίνητα την αρχή των δεδομένων
πιο μετά. Το hex-edit δούλεψε τζάμι αλλά φυσικά δεν συστήνεται.

Από την έκδοση 3.1.2 και έπειτα, πάλι δεν μπορούμε να επιλέξουμε αλλά χρησιμοποιείται
ευθυγράμμιση στο 1MB οπότε δουλεύει σε όλα τα σενάρια.


WESTERN DIGITAL EARS/AARS

Οι δίσκοι της Western Digital (οι μόνοι με 4Κ τομείς για την ώρα) αναφέρουν
ψευδώς ότι έχουν 512Β τομείς οπότε όσο νέο πυρήνα και να χρησιμοποιούμε
δεν μπορούμε να εκμεταλλευτούμε την τοπολογία.

Συνέπειες:
LVM < 2.02.7κατι = χρησιμοποιούμε την --dataalignment
XFS = χρησιμοποιούμε -s size=4096

Ζητώ συγγνώμη για το τεράστιο μήνυμά μου.

[Hwoarang]

Πρέπει να το διαβάσω 3-4 φορές για να καταλάβω τί γράφεις

[imitheos]

Πρέπει να το διαβάσω 3-4 φορές για να καταλάβω τί γράφεις

Ναι είναι τεράστιο
Απλά έγραψα όλα όσα θυμόμουν ότι χρειάστηκε να κάνω για να μη ψάχνει κάποιος
όπως εγώ τότε.

[GoofyX]

Off Topic

Ζητώ συγγνώμη για το τεράστιο μήνυμά μου.

Ναι είναι τεράστιο
Απλά έγραψα όλα όσα θυμόμουν ότι χρειάστηκε να κάνω για να μη ψάχνει κάποιος
όπως εγώ τότε.

Μη ζητάς συγγνώμη για τίποτα. Δεν πρέπει.

[trd64]

Ευχαριστώ πολύ.

Δεν είναι μόνο οι WD αλλά και μερικοί samsung με 4K.

Διαβάζοντας πολλοί λένε ότι πρέπει να αφήνουμε 1 MB χώρο στην αρχή του δίσκου και μετά οι κύλινδροι να είναι πολλαπλάσια του 8 (αν δεν κάνω λάθος).

Χρησιμοποιώντας το Gparted σε γραφικό περιβάλλων γίνεται σωστό alignment?

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

[flamelab]

Ναι είναι τεράστιο
Απλά έγραψα όλα όσα θυμόμουν ότι χρειάστηκε να κάνω για να μη ψάχνει κάποιος
όπως εγώ τότε.

Off Topic

Eχεις καταλαβει οτι κανουμε ομαδικώς bookmark ό,τι post γραφεις , ετσι ; Δεν κανω πλακα

[megahead13]

Off Topic

Eχεις καταλαβει οτι κανουμε ομαδικώς bookmark ό,τι post γραφεις , ετσι ; Δεν κανω πλακα

[WAntilles]

Εδώ και κάμποσο καιρό δεν χρειάζεται να κάνεις τίποτα. Τα fdisk,cfdisk από
την έκδοση 2.17.2 του util-linux-ng (τυπικά από την 2.17 αλλά στις .1 και .2 μπήκαν
κάποια fixes) και το parted ευθυγραμμίζουν στο 1MB οπότε οι κατατμήσεις που
παράγονται είναι βέλτιστες και για 4K και για 128Κ και για 512Κ που χρειάζονται οι SSD.

Υπάρχουν όμως αρκετές motherboards που δεν μπουτάρουν, αν δεν έχουν DOS compatibility mode τα partitions.

[gorillaki]

Προσωπικά έμαθα (με το ζόρι) να δουλεύω με parted από cli, το οποίο έχει πολύ περισσότερες δυνατότητες από το gparted. Είναι σπαστικό στον χειρισμό του (ακόμη και σε σύγκριση με το curses fdisk), αλλά κάνει τα πάντα...

[imitheos]

Διαβάζοντας πολλοί λένε ότι πρέπει να αφήνουμε 1 MB χώρο στην αρχή του δίσκου και μετά οι κύλινδροι να είναι πολλαπλάσια του 8 (αν δεν κάνω λάθος).

Αν θέλεις να δουλεύεις κυλίνδρους τότε χρησιμοποίησε H224,S56 ώστε να
είναι πάντα οι κατατμήσεις ευθυγραμμισμένες και να μη πρήζεσαι.

Αν όπου "κύλινδροι" εννοείς "τομείς", τότε ναι. Πρέπει η αρχή της κατάτμησης
να είναι πολλαπλάσιο του 8. Αν αφήσεις στην αρχή 1MB κενό, θα είναι σωστή
και η 1η φυσικά, μια και το 1MB είναι πολλαπλάσιο του 4096K.
Κάτι που ξέχασα να αναφέρω είναι ότι όταν έχουμε λογικές κατατμήσεις μέσα
σε μία επεκταμένη (extended) τότε η κάθε μία έχει ένα header στην αρχή οπότε
θα χαλάσει την ευθυγράμμιση. Οι extended κατατμήσεις ήταν μια άθλια hackιά
και καλό είναι να μην χρησιμοποιούνται ασχέτως τι δίσκους έχουμε.

Χρησιμοποιώντας το Gparted σε γραφικό περιβάλλων γίνεται σωστό alignment?

Το gparted είναι γραφικό frontend για το parted. Αν το parted που χρησιμοποιείται
από κάτω είναι πρόσφατο τότε ναι το gparted δημιουργεί σωστό alignment.

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

Όχι απλά πολύ, τρομερά μειωμένες επιδόσεις έχει σε random i/o. Σαν αποθήκη
για dvd/bluray/κτλ δηλαδή μεγάλα αρχεία θα έχει μικρή διαφορά. Ειδικά πολύ
μεγάλη διαφορά έχει το ZFS.

Υπάρχουν όμως αρκετές motherboards που δεν μπουτάρουν, αν δεν έχουν DOS compatibility mode τα partitions.

Υπό κανονικές συνθήκες, η μητρική αυτή καθεαυτή δεν έχει καμμία σχέση
(εκτός αν δεν έχω καταλάβει τι εννοείς). Το BIOS φορτώνει σε μια θέση στη μνήμη
τον MBR και έπειτα πηδάει σε εκείνη τη θέση επομένως εκτελείται ο MBR.

Ο MBR που είχε το DOS και τα windows μέχρι τα XP, απλά κοιτούσε ποια κατάτμηση
είναι μαρκαρισμένη ως bootable και φόρτωνε στη μνήμη εκείνο τον bootloader.
Ίσως τέτοιοι MBR να έχουν πρόβλημα. Ο LILO (και υποθέτω και ο grub) δεν έχει
κανένα πρόβλημα. Εδώ και πολύ καιρό έχω παντού GPT αλλά παλιότερα που είχα
MBR δεν χρησιμοποιούσα ποτέ DOS compatibility και ο LILO έπαιζε πάντα.


ZFS
Ο κολλητός μου τρέχει OpenSolaris (τώρα OpenIndiana) οπότε είχα κάνει ένα μικρό
ψάξιμο αλλά δεν έχω ασχοληθεί πολύ οπότε επιφυλάσσομαι για αυτά που γράφω.

Το zfs χρησιμοποιεί μεταβλητό block size. Όταν είναι συνεχόμενα μεγάλα αρχεία
χρησιμοποιεί μεγάλο block size και σε μια άλλη περιοχή που υπάρχουν μικρά αρχεία
έχει μικρό block size. Αυτό όμως έχει ως αποτέλεσμα ότι και ευθυγραμμισμένες
να είναι οι κατατμήσεις, το zfs σέρνεται. Υπάρχει μια μαγκιά που αναφέρεται
σε πολλά blogs και λέγεται ashift. Αυτή λέει στο zfs ποια είναι η μικρότερη μονάδα
που μπορεί να χρησιμοποιεί. Όλα τα pools δημιουργούνται με ashift=9 δηλαδή
2^9 = 512 bytes. Έτσι, μπορούμε να δημιουργήσουμε ένα pool με ashift=12 δηλαδή
2^12 = 4096 bytes αλλά το πρόγραμμα zpool δεν παρέχει τέτοια επιλογή. Μπορεί
όμως κάποιος πολύ εύκολα να αλλάξει τη γραμμή που αναφέρεται στο ashift
και να το κάνει compile. Για Solaris/OpenSolaris υπάρχουν έτοιμα binaries με ashift=12.
Δεν ξέρω τι γίνεται με το FreeBSD. Έπειτα, οι επιδόσεις του zfs θα είναι πολύ καλές.
Το μόνο μειονέκτημα είναι ότι το zfs δεν θα μπορεί πλέον να χρησιμοποιεί block size
μικρότερο από 4096 οπότε αν έχουμε πολλά μικρά αρχεία θα πιάνουν περισσότερο χώρο.

[Slammer]

Πήρα έναν USB εξωτερικό Samsung S1(τον 200αρη σε 1.8'' μεγεθος) χωρίς να ξέρω τίποτα περί 4Κ. Ολα λοιπον, κανονικά με fdisk αφαιρώ το FAT partition, δημιουργώ ενα ext3 (τον θελω μονο για linux) και όλα φαίνονται να δουλεύουν κανονικά.....
Στη χρήση όμως μου φαίνεται τραγικά αργός, το πολύ να πιάνει 3 MB/sec ενω όταν είχα κάνει κάποιες δοκιμές πρίν τον φορμάρω, σε FAT έπιανε 30αρια χαλαρα.....
Ψάχνωντας βρήκα ότι ο συγκεκριμένος σκληρός είναι 4Κ και έκανα αυτό που λέει ο imitheos περί 224 Heads και 56 sectors τα οποία τα κάνεις force όταν καλείς το fdisk και στη συνέχεια φιάχνεις τα partition (στην ουσία ευθυγραμμίζονται τα 4Κ blocks του σκληρού με τα αντίστοιχα blocks του file system). Τελικά με αυτό το κολπάκι, ο σκληρός μεταμορφώθηκε και χτυπάει 30-35 MB/sec σε ext3.
Ολα καλά λοιπόν.....

ΥΓ:Όλα αυτά σε Debian Sid

[WAntilles]

Υπό κανονικές συνθήκες, η μητρική αυτή καθεαυτή δεν έχει καμμία σχέση
(εκτός αν δεν έχω καταλάβει τι εννοείς). Το BIOS φορτώνει σε μια θέση στη μνήμη
τον MBR και έπειτα πηδάει σε εκείνη τη θέση επομένως εκτελείται ο MBR.

Ο MBR που είχε το DOS και τα windows μέχρι τα XP, απλά κοιτούσε ποια κατάτμηση
είναι μαρκαρισμένη ως bootable και φόρτωνε στη μνήμη εκείνο τον bootloader.
Ίσως τέτοιοι MBR να έχουν πρόβλημα. Ο LILO (και υποθέτω και ο grub) δεν έχει
κανένα πρόβλημα. Εδώ και πολύ καιρό έχω παντού GPT αλλά παλιότερα που είχα
MBR δεν χρησιμοποιούσα ποτέ DOS compatibility και ο LILO έπαιζε πάντα.

Είναι το GRUB στο MBR, και το boot δεν φτάνει καν στο στάδιο του να δείξει στην οθόνη το μενού του GRUB.

Μένει κολλημμένο στο πέρας της απαρίθμησης των συνδεδεμένων δίσκων, από τον disk controller του chipset της motherboard.

[imitheos]

Είναι το GRUB στο MBR, και το boot δεν φτάνει καν στο στάδιο του να δείξει στην οθόνη το μενού του GRUB.

Μένει κολλημμένο στο πέρας της απαρίθμησης των συνδεδεμένων δίσκων, από τον disk controller του chipset της motherboard.

Ίσως η assembly του grub να γράφτηκε με την υπόθεση ότι οι κατατμήσεις είναι
πάντα aligned σε cylinders και να μη δουλεύει διαφορετικά. Περίεργο μου φαίνεται
πάντως γιατί το grub ξεκίνησε πολύ πιο μετά από το lilo το οποίο παίζει, οπότε δεν
νομίζω να έκαναν κάτι τόσο χαζό. Μάλλον κάτι άλλο θα παίζει.
Το grub legacy άλλωστε έχει πολλά "προβλήματα". Τις προάλλες διάβαζα ότι
σε μητρική asus p7h57d-v δεν ξεκινά καθόλου ενώ το lilo παίζει κανονικά.

[tsapi]

Καλή σας μέρα!

Αντιμετωπίζω το εξής πρόβλημα: μόλις έστησα τον fileserver μου σε debian wheezy με 4 δίσκους των 2tb σε raid5 (δίσκοι samsung με φυσικό sector size 4096 αλλά δηλούμενο 512) και θέλω να βεβαιωθώ ότι οι ευθυγραμίσεις είναι σωστές. Το storage space είναι, όπως προείπα, σε raid5, encrypted και φορμαρισμένο με ext4. Κάθε δίσκος έχει 1 partition των 2tb. Τα partitions τα έκανα "χειροποίητα" με parted και το softraid, το encryption και το φορμάρισμα με ext4 τα έκανα με τα stock εργαλεία του debian wheezy κατά τη διάρκεια της εγκατάστασης (εγκατάσταση πριν 3-4 μέρες).

Μου μπαίνουν ψύλλοί στ αυτιά, επειδή οι ταχύτητες μου δεν είναι και πάρα πολύ καλές. Δηλαδή, αντιγράφοντας από τον παλιό μου fileserver με rsync οι ταχύτητες που πιάνω είναι ~45mb/sec σε αρχεία ~10gb, ενώ όταν αντιγράφω με rsync πολλά μικρότερα αρχεία (πχ mp3) οι ταχύτητες που πιάνω πέφτουν στα ~32-35mb/sec. Αντιγράφοντας τα ίδια αρχεία (με rsync πάντα) αλλά με προορισμό αυτήν τη φορά το /home directory του καινούριου fileserver, το οποίο βρίσκεται πάνω σε raid1 με 500άρηδες δίσκους που δεν έχουν θέμα alignment, οι ταχύτητες είναι αντίστοιχα ~29mb/sec και ~24mb/sec.

Το hdparm δίνει:
Για το raid1 array (που είναι σε δίσκους με 512 bytes, όπου δεν υπάρχει θέμα alignment):

root@xyta:~# hdparm -tT /dev/md0
/dev/md0:
 Timing cached reads:   2670 MB in  2.00 seconds = 1334.56 MB/sec
 Timing buffered disk reads: 390 MB in  3.00 seconds = 129.94 MB/sec

Ενώ για το raid5 array (με τους τέσσερις δίσκους των 4kb sector) δίνει:

root@xyta:~# hdparm -tT /dev/md2
/dev/md2:
 Timing cached reads:   2772 MB in  2.00 seconds = 1386.09 MB/sec
 Timing buffered disk reads: 878 MB in  3.11 seconds = 282.19 MB/sec

Anyway, για τους ανωτέρω λόγους θέλω να επαληθεύσω ότι όλα τα layers μου (partitions, raid, encryption, ext4) είναι ευθυγραμμισμένα.

Για τα partitions τα πράματα είναι εύκολα:

root@xyta:~# parted /dev/sdd
GNU Parted 2.3
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s                                                           
(parted) print                                                            
Model: ATA SAMSUNG HD204UI (scsi)
Disk /dev/sdd: 3907029168s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start  End          Size         File system  Name  Flags
 1      2048s  3907026943s  3907024896s                     raid

(parted)

Το output του parted σε ό,τι αφορά το starting sector του partition είναι ίδιο και για τους 4 δίσκους του raid5 array, οπότε είμαι aligned.

Για τα άλλα layers όμως πώς μπορώ να κάνω την επαλήθευση??

Κάθε βοήθεια ευπρόσδεκτη!!