Τέλος εποχής για τους "γρήγορους" μαγνητικούς δίσκους (Μέρος 2)

[Hemispasm1442169066]

"even if the manufacturer rates the lifeline of these drives at 140 years of 50GB read/write's per day, real world results by enterprise guru's such as Dave Graham state that NAND Based SSD's actually deteriorate rather rapidly in a server environment. A large scale corporation would be much better suited waiting for more data on longevity before implementing any kind of setup like this in a server."

http://www.nextlevelhardware.com/storage/battleship/

Lol

[DarthMoul]

http://www.nextlevelhardware.com/storage/battleship/

Lol

Έτσι είναι και υπάρχει σαφής λόγος που συμβαίνει αυτό. Οι κατασκευαστές των SSD υπολογίζουν την διάρκεια ζωής του δίσκου με αναγωγή του μέγιστου transfer rate που μπορεί να δώσει ο δίσκος σε sequential write. Αυτό είναι μπαρούφα γιατί στην πραγματικότητα αν γράψεις μόνο 2 cross-block bytes έχεις προκαλέσει την ίδια ζημιά που θα έκανες αν έγραφες 2 full blocks των 8192 bytes. Με δεδομένο το μικρό seek time των SSD και το υψηλό transfer rate που έχουν στα μικρά chunks, το πραγματικό worst case scenario είναι μερικές μέρες και όχι πέντε χρόνια όπως μας λένε. Για να επιβεβαιώσω την παραπάνω υπόθεση έγραψα ένα προγραμματάκι που κάνει την παραπάνω δουλειά και το δοκίμασα σε ένα παλιό NAND flash usb κλειδάκι της SONY που είχα των 128 MB. Μου άφησε χρόνους μετά από μερικά λεπτά, αλλά αν δούλευε πάνω σε SATA και όχι σε USB θα είχε ζήσει πολύ λιγότερο.

Τα σοβαρά databases πλέον δουλεύουν με πολύ μικρά chuncks και παρακάμπτουν πλήρως το cache του λειτουργικού με asynchronous direct i/o για να εκμεταλλεύονται στο μέγιστο την ταχύτητα του δίσκου. Γι αυτό και οι SSD σε servers καταρρέουν ταχύτατα και για αυτόν τον λόγο μένουν στα αζήτητα προς το παρόν.

Αυτά για το worst case σενάριο. Με κανονική χρήση, ο μόνος τρόπος για να υπολογίσεις την πραγματική διάρκεια ζωής του δίσκου είναι να κάνεις αυτό που είπα πριν στον tristeno. Να κρατήσεις per block i/o statistics, να απομονώσεις τα writes και να κάνεις τις αναγωγές. Αυτό πιστεύω ότι κάνουν και οι κατασκευαστές των SSD σε μεγάλη κλίμακα, δηλαδή με πολλούς διαφορετικούς χρήστες που κάνουν διαφορετική χρήση, ώστε να ξέρουν τι ποσοστό επιστροφών να υπολογίσουν πριν την λήξη της εγγύησης του προϊόντος και να σταθμίσουν την πιθανή μελλοντική ζημιά τους. Μπορεί τελικά η διάρκεια ζωής του SSD για τον μέσο χρήστη να είναι και μεγαλύτερη της πενταετίας, αλλά αν δεν μας δώσουν συγκεκριμένες μελέτες και όχι θεωρητικά μοντέλα που δεν στέκονται, δεν μπορούμε να το ξέρουμε.

[tristeno1416003162]

Για να επιβεβαιώσω την παραπάνω υπόθεση έγραψα ένα προγραμματάκι που κάνει την παραπάνω δουλειά και το δοκίμασα σε ένα παλιό NAND flash usb κλειδάκι της SONY που είχα των 128 MB.

Νομίζω ότι παραβλέπεις μια σημαντικότατη διαφορά μεταξύ οποιουδήποτε USB Flash και ενός SSD.

The way that SSD oems deal with the management of write endurance internally within their products varies but they all have the common theme of scoring how many times a block of memory has been written to, and then reallocating physical blocks to logical blocks dynamically and transparently to spread the laod across the whole disk. In a well designed flash SSD you would have to write to the whole disk the endurance number of cycles to be in danger.

Some manufacturers go a step further. SiliconSystems has a patented algorith which delivers a lifetime which it claims is better than simplistic wear levelling. Another manufacturer Adtron actually has a percentage of spare flash blocks in the SSD - which are invisible to the host interface and don't show up as spare storage. But internally - when blocks get close to the limit - the data is transparently switched over to the spare parts of the disk to give an additional breathing space.

Δεν πιστεύω να νομίζεις ότι το flash που δοκίμασες κάνει κάτι από τα παραπάνω.

tristeno added 5 Minutes and 3 Seconds later...

state that NAND Based SSD's actually deteriorate rather rapidly in a server environment. A large scale corporation would be much better suited waiting for more data on longevity before implementing any kind of setup like this in a server."

Υπάρχουν τίποτα νούμερα να δούμε? Γιατί αν θεωρούν ότι "γρήγορη φθορά" σημαίνει 10 χρόνια αντί για 40 δεν έχει καμμία πρακτική σημασία.

Μην ξεχνάμε ότι μιλάνε πάλι για χρήση διακομιστή. Να υποθέσω ότι υπονοούν ότι δεν υπάρχει θέμα για οικιακή χρήση? :001:

[DarthMoul]

Δεν πιστεύω να νομίζεις ότι το flash που δοκίμασες κάνει κάτι από τα παραπάνω.

Το ξέρω ότι δεν το κάνει. Δοκιμή στον κώδικα μου έκανα. Και δοκιμή του πως αντιδρά η NAND όταν φάει τα ψωμιά της. Για 2 cross-block bytes με 8190 bytes pad, 0.1 ms seek time x 1.000.000 φορές για έναν δίσκο 32 Giga, πόσο χρόνο θέλω για ένα thread; Όσα relocations και να κάνει ο δίσκος, δεν σώζεται. Αυτό είναι το worst case σενάριο.

DarthMoul added 2 Minutes and 50 Seconds later...

Υπάρχουν τίποτα νούμερα να δούμε? Γιατί αν θεωρούν ότι "γρήγορη φθορά" σημαίνει 10 χρόνια αντί για 40 δεν έχει καμμία πρακτική σημασία.

Μην ξεχνάμε ότι μιλάνε πάλι για χρήση διακομιστή. Να υποθέσω ότι υπονοούν ότι δεν υπάρχει θέμα για οικιακή χρήση? :001:

Δεν ξέρω αν υπάρχουν νουμερα, αλλά υπάρχουν standard πρακτικές που ακολουθούμε στα data centers. Πχ δεν μπαίνει μέσα στο rack δίσκος αν δεν δώσει εγγύηση για 5 χρόνια 24/7.

[tristeno1416003162]

Με τι transfer rate να στο υπολογίσω και με ποιό αλγόριθμο "φθοράς".

Και ένα από την ίδια την IBM

IBM analysis indicates that the replacement rate of a solid state drive on a typical Blade server configuration is only about 1% per year, vs. 3% on SAS drives.

[DarthMoul]

Με τι transfer rate να στο υπολογίσω και με ποιό αλγόριθμο "φθοράς".

Με ότι transfer rate δίνει ο δίσκος γράφοντας κατ'εξακολούθηση τα 2 bytes per write με random seek σε σταθερές διευθύνσεις. Για τους δίσκους με 100,000 cycles θα σου βγει λογικά κάτι πάνω από χρόνο και στους άλλους με 1,000,000 cycles επί 10.

Και ένα από την ίδια την IBM

Το οποίο δεν έχει να κάνει με αυτό που συζητάμε. Εξετάσει αποτυχία των δίσκων λόγω της φθοράς των κινητών μερών η συγκεκριμένη παράγραφος

Για αυτό που συζητάμε η IBM λέει τα παρακάτω:

Some Hybrid disks, and some types of solid state memory in general, do have limitations in the number of write cycles they can handle. For those unhappy with the frequency and slowness for rebuilds on SATA disk may find similar problems with hybrid drives. For that reason, businesses may not trust using hybrid drives for their busiest, mission-critical applications, but certainly might use it for archive data with lower write-cycle requirements.

[tristeno1416003162]

Με ότι transfer rate δίνει ο δίσκος γράφοντας κατ'εξακολούθηση τα 2 bytes per write με random seek σε σταθερές διευθύνσεις

Το "σταθερές" πως θα το καταφέρεις σε έναν SSD?

[DarthMoul]

Το "σταθερές" πως θα το καταφέρεις σε έναν SSD?

Θα το ζητήσω από το λειτουργικό με μια lseek. Το τι θα κάνει ο δίσκος είναι δικό του ζήτημα. Θα κάνει ότι μπορεί για να διασπείρει την φθορά ισορροπημένα. Αν όμως έχει write cycle πχ 100,000 και ζητήσω 100,000 writes, όπου και να την πάει την φθορά, τελικά θα την υποστεί στο 100%. Αυτό που βλέπω πάντως είναι ότι οι πιο μεθοδικές αναλύσεις καταλήγουν στο ίδιο συμπέρασμα. Κάτι πάνω από χρόνο για 100,000 write cycles. Οι υπόλοιπες που δεν λαμβάνουν υπόψην ότι οι εφαρμογές γράφουν bytes, αλλά το λειτουργικό μόνο blocks, καταλήγουν στα τερατώδη νούμερα των 40, 50 και 140 χρόνων!!!! worst case.

[tristeno1416003162]

Για να τα βάλουμε με την σειρά.

Έστω ότι έχει 100.000 write cycles "ανοχή" και είναι χωρητικότητας 32GB με διαμεταγωγή 100ΜΒ/s.

Τι όγκο δεδομένων (ή blocks) πρέπει να γράψεις για να υποστεί ολόκληρος ο δίσκος φθορά μια φορά?

[DarthMoul]

Για να τα βάλουμε με την σειρά.

Έστω ότι έχει 100.000 write cycles "ανοχή" και είναι χωρητικότητας 32GB με διαμεταγωγή 100ΜΒ/s.

Τι όγκο δεδομένων πρέπει να γράψεις για να υποστεί ολόκληρος ο δίσκος φθορά μια φορά?

2 cross-block bytes με pad 8190 επί τον αριθμό των blocks / 2.

Ολα τα σημερινά fs έχουν default block 4096, οι SSD physical sector 512 από όσο ξέρω. Όταν λοιπόν το λειτουργικό ζητάει εγγραφή ενός block, ο δίσκος είναι υποχρεωμένος να γράψει όσους sectors χρειάζονται για να ικανοποιήσει το request. Το που θα γράψει ο δίσκος το λειτουργικό δεν το αφορά, ούτε στους μαγνητικούς, ούτε στους SSD.

Η διαμεταγωγή διαφέρει ανάμεσα σε read/write και sequential/random. Εδώ, επειδή μιλάμε για πολύ μικρά chunks (2 bytes) με random access, είναι πολύ μικρή, αφού ως διαμεταγωγή μετράμε πάντα τον ρυθμό με το οποίο ο δίσκος μεταφέρει από και προς την CPU τα data και όχι τι έκανε ο ίδιος για να εκτελέσει το αίτημα.

Στην πράξη τώρα, το αίτημα εγγραφής 2 bytes από την εφαρμογή, υποχρεώνει το λειτουργικό να ζητήσει εγγραφή ενός block, και τον δίσκο να εκτελέσει εγγραφή από αντίστοιχο αριθμό sectors, προκαλώντας και ανάλογη φθορά. Αναφορικά με τον χρόνο ο περιοριστικός πάραγωντας εδώ δεν είναι το transfer rate. Θα ήταν αν είχα sequential (ή και random) writes σε μεγάλα blocks. Εδώ ο περιοριστικός παράγωντας είναι το seek time του δίσκου.

Στην ιδανική περίπτωση περιορισμού της φθοράς, θα πρέπει το block του fs να ταυτιστεί σε μέγεθος με αυτό του physical block του δίσκου και ακόμα καλύτερα να μικρύνουν και τα δύο όσο περισσότερο γίνεται. Πάνω σε αυτό έχουν αρχίσει να κοιτάνε οι κατασκευαστές των λειτουργικών, ώστε να μπουν μετά από λίγα χρόνια οι SSD μαζικά στην αγορά και στα data centers. Ενώ θεωρητικά φαίνεται απλό το να μικρύνεις το fs block, στην πράξη ανεβάζει πολύ CPU load, οπότε θα πρέπει να αναθεωρηθούν αρκετά πράγματα ώστε να περιοριστούν οι παράπλευρες συνέπειες.

[BeetleJuice]

Στο σύστημα μου έχω συνολικά 524 GB χωρητικότητα.

Γρήγορο access δεν χρειάζομαι στα mp3.

Γρήγορο access δεν χρειάζομαι στις εικόνες.

Γρήγορο access δεν χρειάζομαι στα αρχεία video.

Γρήγορο access δεν χρειάζομαι στα κείμενα.

Γρήγορο access δεν χρειάζομαι στο mailbox.

Όσο και να αυξήσω το transfer rate στα παραπάνω, η αύξηση στην ανταποκρισιμότητα του συστήματος δεν είναι καν αισθητή και μπορώ να την μετρήσω μόνο με kernel level profiling.

Γρήγορο access χρειάζομαι για τα libraries του συστήματος.

Γρήγορο access χρειάζομαι για το swap, που όμως το σύστημα χρησιμοποιεί ελάχιστα.

Tα δύο παραπάνω πιάνουν συνολικά 4.5 GB.

Και επειδή είμαι επαγγελματίας και κάνω development, άντε να χρειάζομαι άλλα 2-3 GB με γρήγορο access. Όλα μαζί αντιστοιχούν στο 1.4% της συνολικής μου χωρητικότητας.

Κάποιος άλλος που κάνει επεξεργασία video, θα χρειαστεί το πολύ καμμιά 20 αριά GB με πραγματικά γρήγορο access.

Κάποιος που δεν είναι επαγγελματίας μάλλον δεν χρειάζεται ακόμα.

Καλά ψώνια

μιας και εισαι επαγγελματιας , εσυ θα επελεγες λοιπον για αυτα τα 2 πραγματακια ενα ssd μικρο?

και αν οχι για ποιο λογο?

οταν λες libraries , τι εννοεις

ας πουμε σε ΧΡ μπορεις να πεις οτι ο ταδε φακελος θα ειναι σε αλλο δισκο?

νομιζω οχι

αν ναι πως μπορουμε να το κανουμε αυτο (για swap ξερω πως γινεται)

γρηγορο acess ΓΙΑΤΙ δεν χρειαζεσαι στις εικονες?

ενας που δουλευει photoshop και εχει φακελο με κατι φωτο ολοκληρα γιγα η καθεμια και θελει να κανει ενα review γρηγορο με thumbnails δεν θα εξυπηρετηθει απο ενα ssd?

και μια απορια

την αισθηση αποκρισης κατα την γνωμη σου (ειλικρινα πιστευω οτι ξερω ελεχιστα σε σχεση με σενα) ΤΙ την ανεβαζει?

ΠΟΛΛΗ ραμ?

ΓΡΗΓΟΡΗ ραμ?

ΠΟΛΛΑ Mhz core?

ΠΟΛΛΑ cores?

ορμωμενος απο το ποστ σου νομιζω μπορουμε να βγαλουμε καταπληκτικα συμπερασματα για βελτιωση αποκρισης και ποιος χρειαζεται τι και πως..

περιμενω απαντηση

σκαθαρι (για οσους δε με καταλαβαν)

[DarthMoul]

μιας και εισαι επαγγελματιας , εσυ θα επελεγες λοιπον για αυτα τα 2 πραγματακια ενα ssd μικρο?

και αν οχι για ποιο λογο?

Γιατί επειδή είμαι επαγγελματίας, το pc μου θα έρθει με έναν build in scsi u320 controller. Μπορώ να πετύχω τις ίδιες επιδόσεις με μαγνητικό δίσκο, μεγαλύτερη χωρητικότητα, χωρίς ορατούς περιορισμούς στα writes που θα κάνω. Το pc έρχεται με εγγυήσεις, συμβόλαια συντήρησης και τακτικό backup, ώστε ακόμα και αν αποτύχει ο δίσκος από πλευράς μηχανικών μερών, δεν μου καίγεται καρφί, και δεν δικαιολογείται το επιπλέον αρχικό κόστος κτήσης ενός SSD.

οταν λες libraries , τι εννοεις

ας πουμε σε ΧΡ μπορεις να πεις οτι ο ταδε φακελος θα ειναι σε αλλο δισκο?

νομιζω οχι

αν ναι πως μπορουμε να το κανουμε αυτο (για swap ξερω πως γινεται)

Στα XP μπορείς να βάλεις τις εφαρμογές και τα data σου σε άλλο δίσκο, κρατώντας όλο το λειτουργικό στον ίδιο. Δεν έχει διαφορά. Το ίδιο αποτέλεσμα έχεις. Όταν η εφαρμογή σε ρωτά αν θα εγκατασταθεί στο C:\Program Files εσύ την στέλνεις στο D:\Program Files. Θα δουλέψει μια χαρά.

γρηγορο acess ΓΙΑΤΙ δεν χρειαζεσαι στις εικονες?

ενας που δουλευει photoshop και εχει φακελο με κατι φωτο ολοκληρα γιγα η καθεμια και θελει να κανει ενα review γρηγορο με thumbnails δεν θα εξυπηρετηθει απο ενα ssd?

Οι SSD έχουν μοναδικό πλεονέκτημα το χαμηλό seek time. Σε transfer rates είναι κατώτεροι από τους SCSI. Ίσως και από κάποιους γρήγορους SATA. Όσο μεγαλώνει δε το transfer που θα κάνεις, τόσο πέφτει το transfer rate τους σε σχέση με τους μαγνητικούς. Για να έχεις αισθητό κέρδος θα πρέπει να έχεις πολλά seeks και μικρά transfers.

Αν φτιάχνεις τα thumbnails on-the-fly, σημαίνει πως διαβάζεις ολόκληρη την εικόνα. Το transfer που κάνεις στην μνήμη είναι το 100% των τεραστίων data που έχεις στον δίσκο, και κέρδος από το μικρό seek δεν υπάρχει, αφού ότι χρόνο κερδίσεις από αυτό, θα τον χάσεις λόγω του μεγάλου transfer που θα κάνεις . Αν έχεις τα thumbnails έτοιμα και ομαδοποιημένα σε κάποιο μεγάλο αρχείο, έχεις πάλι ένα και μοναδικό seek, και transfer ενός πολύ μεγάλου αρχείου στην μνήμη. Πάλι κέρδος δεν βλέπω πουθενά.

και μια απορια

την αισθηση αποκρισης κατα την γνωμη σου (ειλικρινα πιστευω οτι ξερω ελεχιστα σε σχεση με σενα) ΤΙ την ανεβαζει?

ΠΟΛΛΗ ραμ?

ΓΡΗΓΟΡΗ ραμ?

ΠΟΛΛΑ Mhz core?

ΠΟΛΛΑ cores?

Εγώ την ανεβάζω με ένα πολύ μικρό timeslice στον io-scheduler εξαιρώντας τα read-once data από το disk cache για να μην έχω βρωμιά, και προσπελαύνοντας τα ασύγχρονα. Με hardware λίγο ακριβότερο από τον μέσο όρο, και σίγουρα δεν χρειάζομαι SSD. Ο καθένας το παλεύει όπως μπορεί.

[tristeno1416003162]

Αν έχεις τα thumbnails έτοιμα και ομαδοποιημένα σε κάποιο μεγάλο αρχείο, έχεις πάλι ένα και μοναδικό seek, και transfer ενός πολύ μεγάλου αρχείου στην μνήμη. Πάλι κέρδος δεν βλέπω πουθενά.

Αυτό είναι ανακριβές γιατί τα thumbails δεν ομαδοποιούνται σε ένα μεγάλο αρχείο.

Επιστρογή στο θέμα τώρα.

Ευκαιρία να ξαναδούμε τώρα που υπάρχουν διαθέσιμοι και οι SSD της OCZ και οι Velociraptor το κόστος στην σύνθεση συστήματος με συνολικό αποθηκευτικό χώρο 1ΤΒ.

[DarthMoul]

Αυτό είναι ανακριβές γιατί τα thumbails δεν ομαδοποιούνται σε ένα μεγάλο αρχείο.

Εξαρτάται για ποιό πρόγραμμα μιλάς tristeno. Μάλλον την ψάχνεις για flame μήπως ξεφορτώσεις κάνεναν SSD από αυτούς που σου ξέμειναν.

[tristeno1416003162]

Σε XP είναι διαφοτερικό σε κάθε directory. Σε Vista, πάλι είναι πολλά διαφορετικά αρχεία σε ένα βασικό directory. Σε ποιό πρόγραμμα αναφέρεσαι να το δούμε και αυτό.

PS Δεν βλέπω να ξεμένει τίποτα, σε αντίθεση με μερικούς άλλους.

[DarthMoul]

Σε XP είναι διαφοτερικό σε κάθε directory. Σε Vista, πάλι είναι πολλά διαφορετικά αρχεία σε ένα βασικό directory. Σε ποιό πρόγραμμα αναφέρεσαι να το δούμε και αυτό.

PS Δεν βλέπω να ξεμένει τίποτα, σε αντίθεση με μερικούς άλλους.

Δηλαδή εννοείς ότι τα 5.000.000 σκαναρισμένα έγγραφα που έχω στο γραφείο μαζί με τα thumbnail τους θα τα δουλέψω με τα build in tools που έχει το λειτουργικό; Και θα έχω 10.000.000 αρχεία με συνολικό μέγεθος 2 Tera χύμα στον δίσκο μέσα σε κάποιο directory;

Μάλλον απευθύνεσαι σε αυτούς που έχουν 200-300 φωτογραφίες, αλλά ούτε και αυτοί χρειάζονται SSD για να κάνουν την δουλειά τους.

Άντε καλές δουλειές

[tristeno1416003162]

Πες μας με ποιό πρόγραμμα τα δουλεύεις να σου πούμε τότε.

[DarthMoul]

Πες μας με ποιό πρόγραμμα τα δουλεύεις να σου πούμε τότε.

Αυτό που δουλεύω εγώ το έχω φτιάξει εγώ οπότε δεν θα το βρεις για να μου πεις. Πάντως να είσαι σίγουρος ότι δεν κρατάει 10Μ αρχεία στον δίσκο γιατί οποιοδήποτε filesystem σε οποιοδήποτε λειτουργικό και με οποιοδήποτε hardware θα τα έφτυνε κανονικά. Οι φωτογραφίες και τα thumnails είναι μαζεμένα σε 2 αρχεία και συνοδεύονται από 4-5 άλλα πολύ μικρά για indexing. Δηλαδή ότι ακριβώς κάνει ένα image database software από αυτά που κυκλοφορούν στο εμπόριο. Αν θέλεις διάλεξε ένα από αυτά και πες μου, το ίδιο αποτέλεσμα θα έχουμε.

[tristeno1416003162]

Τα windows τα έχουν χώρια τα thumbs και όχι σε ΕΝΑ μεγάλο αρχείο. Αν τα έγγραφα μπαίνουν σε sub-directories και όχι "χύμα" σε ένα ενιαίο γιατί να υπάρχει πρόβλημα να έχεις όχι 10Μ αλλά και 1000Μ φωτογραφιών?

Κοιτώντας στο Picasa που χρησιμοποιώ διαπίστωσα ότι για 20.000 σαρωμένα έγγραφα/φωτογραφίες η βάση δεδομένων που κρατά είναι ένα αρχείο 160ΜΒ, οπότε μάλλον έχει εγκυκλοπαιδική σημασία η χρήση SSD ή μαγνητικού.

[tristeno1416003162]

Total recall

κοντά 10Κ views!!