Επαναφορά SSD στην αρχική του κατάσταση για αποκατάσταση της ταχύτητας του ?

[TheELF]

Δεν μας ενδιαφερουν οι μεγαλες συνεχομενες περιοχες με free page στους ssd, γιατι ακομα και αν υπαρχουν, ο controller επιλεγει να γραψει σε blocks που δεν εχουν πολλα writes(wear levering, για να μην κουραζονται συνεχεια τα ιδια cells και χαλασουν) και δεν τον νοιαζει να γραφει σε γειτονικα block.

 

Οπως σου ειπα, σκεφτεσαι με λογικη hdd, ενω μιλαμε για ssd.

Ε,άρα ούτε το secure erase θα κάνει διαφορά, αφού δεν μας ενδιαφέρουν οι μεγάλες περιοχές με free page,οπότε και πάλι στα ίδια είμαστε... το defrag κάνει την ίδια (δηλαδή καμία) διαφορά με το secure erase.

 

Οπότε,αν και κανένα από τα δύο δεν θα κάνει δουλειά ή διαφορά.

Το (ένα και μοναδικό) defrag επιδεινώνει και μειώνει την διάρκεια ζωής του ssd περισσότερο ή λιγότερο από το να κάνεις secure erase + win install + drivers + programs + updates.... 

[haHa]

Ε,άρα ούτε το secure erase θα κάνει διαφορά, αφού δεν μας ενδιαφέρουν οι μεγάλες περιοχές με free page,οπότε και πάλι στα ίδια είμαστε... το defrag κάνει την ίδια (δηλαδή καμία) διαφορά με το secure erase.

 

Οπότε,αν και κανένα από τα δύο δεν θα κάνει δουλειά ή διαφορά.

Το (ένα και μοναδικό) defrag επιδεινώνει και μειώνει την διάρκεια ζωής του ssd περισσότερο ή λιγότερο από το να κάνεις secure erase + win install + drivers + programs + updates.... 

 

Λαθος καταλαβες..

Δεν ειπα οτι "δεν μας ενδιαφέρουν οι μεγάλες περιοχές με free page" , αλλα οτι "Δεν μας ενδιαφερουν οι μεγαλες συνεχομενες περιοχες με free page στους ssd"

 

 

Στους ssd μας ενδιαφερουν τα free pages. Αυτα μπορει να δημιουργηθουν ΜΟΝΟ με trim ή secure erase.

Δεν μας ενδιαφερει ομως αυτα τα free pages να ειναι συνεχομενα.

 

Συνεχιζεις μετα απο 4 σελιδες και γραφεις ανακριβειες, επειδη δεν διαβαζεις..

Επισης συνεχιζεις κ σκεφτεσαι με λογικη hdd ενω μιλαμε για ssd.

Δεν καταλαβες καν το χαρακτηριστικο παραδειγμα του palp:

 

Edit για να δώσω ένα παράδειγμα: Έχεις ένα SSD 40 GB για αποθηκευτικό χώρο σε Windows 7/8. Γράφεις και στα 40 GB και μετά τα διαγράφεις όλα οπότε έχεις όλο τον χώρο ελεύθερο.

Το defrag ουσιαστικά δεν κάνει τίποτα καθώς έχεις μηδέν αρχεία για να μετακινήσει. Ο SSD όμως βλέπει ακόμα 40 GB "γεμάτα". Έτσι όταν πάς να γράψει κάτι νέο θα έχει μειωμένη ταχύτητα από την αρχική καθώς έχει μία καθυστέρηση αφού πρώτα πρέπει να ελευθερώσει το χώρο και μετά να γράψει.

[TheELF]

Λαθος καταλαβες.. 

Στους ssd μας ενδιαφερουν τα free pages. Αυτα μπορει να δημιουργηθουν ΜΟΝΟ με trim ή secure erase.

Δεν μας ενδιαφερει ομως αυτα τα free pages να ειναι συνεχομενα.

Γιατί λες ότι δεν κατάλαβα;Να τι είπα:

Ε,άρα ούτε το secure erase θα κάνει διαφορά, αφού δεν μας ενδιαφέρουν οι μεγάλες περιοχές με free page,οπότε και πάλι στα ίδια είμαστε... το defrag κάνει την ίδια (δηλαδή καμία) διαφορά με το secure erase.

(Με το secure erase έχεις μια τεράστια συνεχόμενη περιοχή (όλο το δίσκο) με free page)

 

Ακόμα και έτσι λοιπόν,πως γίνεται με secure erase + win install + drivers + programs + updates(κάνεις το σύστημα σου δηλαδή όπως ήταν πριν) να έχεις περισσότερα free page από το όταν κάνεις απλά defrag(ή απλά δεν κάνεις τίποτα);Και να έχεις περισσότερα θα είναι ελάχιστη η διαφορά...

 

Για το παράδειγμα του palp τι να πω;Αν τα σβήσεις όλα από πάνω του είναι απλά αποθήκη οπότε δεν σε νοιάζει η ταχύτητα, αλλά όπως είπαμε, και να τα κάνεις όλα delete μετά πάλι μπορείς να κάνεις ένα trim δεν σε σταματάει κανείς.

[haHa]

Ακόμα και έτσι λοιπόν,πως γίνεται με secure erase + win install + drivers + programs + updates(κάνεις το σύστημα σου δηλαδή όπως ήταν πριν) να έχεις περισσότερα free page από το όταν κάνεις απλά defrag;Και να έχεις περισσότερα θα είναι ελάχιστη η διαφορά...

Παμε ξανα:

Με το defrag  δεν δημιουργεις free pages, αντιθετα δημιουργεις invalid pages.

 

Μονο με trim/secure erase μπορεις να κανεις τα σβησμενα αρχεια/invalid pages να γινουν free pages.

[TheELF]

«Παμε ξανα:

Με το defrag  δεν δημιουργεις free pages»

Οκ δηλαδή το defrag δεν βάζει στην σειρά τα κομμάτια των αρχείων ούτε βάζει σε σειρά τα αρχεία ούτε βάζει όλα τα αρχεία μαζί στην αρχή γιατί όπως λες «ο controller επιλεγει να γραψει σε blocks που δεν εχουν πολλα writes(wear levering)» ,οκ αυτό.

Ουσιαστικά δηλαδή απλά πάει μια βόλτα όλα τα αρχεία και ξαναγράφονται το ίδιο τυχαία (όπου νάνε στον δίσκο αναλόγως το wear leveling)  με πριν το defrag, σπαταλώντας write cycles.

«αντιθετα δημιουργεις invalid pages»

Αυτό συνεχίζω να μην το καταλαβαίνω,γιατί δημιουργεί invalid αφού δεν κάνει ούτε delete ούτε προσθέτει στοιχεία;

Ο μόνος λόγος να βγάζει invalid θα ήταν αν πραγματικά θα άλλαζε την σειρά των αρχείων και τον κομματιών τους,που όπως είπαμε δεν συμβαίνει.

 

Λαθος κανεις, δεν μιλαει απευθειας με τον controller το defrag.

 

Επιμενεις να γραφεις ανακριβειες.

Ειναι πολυ απλο:

εγραψες οτι το defrag βοηθαει εξισου με secure erase, κατι που φυσικα δεν ισχυει γιατι το defrag δεν βοηθαει τους ssd να επανελθουν σε ταχυτητα.

Αντιθετα το secure erase και το trim βοηθανε τους ssd να επανελθουν σε ταχυτητα.

 

Εσυ μπορεις να επιμενεις να γραφεις ανακριβειες οτι ο topic starter μπορει να κανει defrag για να επανελθουν οι ταχυτητες, οτι το defrag βοηθαει(ή δεν βοηθαει) εξισου με το secure erase κλπ.

 

Απλα εισαι ο μονος που πιστευεις αυτες τις ανακριβειες.

 

 

Αν καποιος θελει να επαναφερει τον ssd στις αρχικες ταχυτητες, φροντιζει να εχει trim ή κανει secure erase. Το defrag δεν βοηθαει και δεν πρεπει να γινεται σε ssd, οσο κ αν επιμενεις. Δεν εχει νοημα να κανεις defrag σε ssd, γιατι θα δημιουργησεις περισσοτερα invalid pages(αρα ακομα πιο αργος) και επισης θα του μειωσει την διαρκεια ζωης τσαμπα.

Ε,αυτό πως γίνεται τώρα;;;Αφού «ο controller επιλεγει να γραψει σε blocks που δεν εχουν πολλα writes(wear levering)» άρα και με το secure erase θα παραμείνει η ίδια ταχύτητα,τι μου διαφεύγει;;;;

[Palp]

Ε,αυτό πως γίνεται τώρα;;;Αφού «ο controller επιλεγει να γραψει σε blocks που δεν εχουν πολλα writes(wear levering)» άρα και με το secure erase θα παραμείνει η ίδια ταχύτητα,τι μου διαφεύγει;;;;

 

Το πρόβλημα με την μείωση της απόδοσης ξεκινά όταν αρχίζεις να γράφεις και να σβήνεις αρχεία καθώς αυτό γίνεται στο logical level (λειτουργικό) και όχι στο physical level (firmware/flash/controller) αρχικά. Όταν πας να γράψεις κάτι στο σκληρό ο controller λέει αρχικά "αυτό είναι κενό σύμφωνα με το λειτουργικό, πάω να γράψω εδώ". Μετά βλέπει ότι υπάρχουν δεδομένα στο σημεία, που είναι άχρηστα και έχουν διαγραφεί από το λειτουργικό, σταματά την εγγραφή, κάνει διαγραφή, και μετά ξεκινά την εγγραφή. Οπότε υπάρχει αυτή η καθυστέρηση που βλέπεις ως πτώση επιδόσεων.

Ο controller γράφει τυχαία σε blocks με μικρότερο wear αλλά πάλι μπορεί να πέσει σε "διεγραμμένα" αρχεία και να καθυστερήσει. Και το TRIM ουσιαστικά ενημερώνει τον controller του σκληρού σε "νεκρό" χρόνο ώστε αυτά που βλέπει το λειτουργικό και αυτό που βλέπει ο SSD να συμφωνούν.

 

Το secure erase είναι σε επίπεδο firmware/controller του δίσκου και σβήνει τα πάντα (γράφει παντού 0) οπότε μετά αυτή την διαδικασία ο δίσκος είναι κενός και ο controller ξέρει ότι ο δίσκος είναι 100% άδειος (όπως δηλαδή είναι όταν τον βγάζεις από το κουτί την πρώτη φορά από πλευρά επιδόσεων).

[TheELF]

Το secure erase είναι σε επίπεδο firmware/controller του δίσκου και σβήνει τα πάντα (γράφει παντού 0) οπότε μετά αυτή την διαδικασία ο δίσκος είναι κενός και ο controller ξέρει ότι ο δίσκος είναι 100% άδειος (όπως δηλαδή είναι όταν τον βγάζεις από το κουτί την πρώτη φορά).

Αυτό δεν εξηγεί όμως γιατί δεν πιάνει το wear leveling που λέει ο haHA,και 100% άδειος να είναι μετά το secure πριν δεν ήταν,υπάρχουν περιοχές που είχαν γραφεί περισσότερο και άλλες λιγότερο,έτσι δεν είναι;Πρέπει να πιάνει το wear, και πάλι να μην είναι στην μέγιστη ταχύτητα.

[haHa]

Τα εχεις μπερδεμενα. Το wear leveling δεν καθυστερει τους ssd, αλλα τα invalid pages καθυστερουν τους ssd.

 

Αυτο που περιεγραψε ο palp:

"Όταν πας να γράψεις κάτι στο σκληρό ο controller λέει αρχικά "αυτό είναι κενό σύμφωνα με το λειτουργικό, πάω να γράψω εδώ". Μετά βλέπει ότι υπάρχουν δεδομένα στο σημεία, που είναι άχρηστα και έχουν διαγραφεί από το λειτουργικό, σταματά την εγγραφή, κάνει διαγραφή, και μετά ξεκινά την εγγραφή. Οπότε υπάρχει αυτή η καθυστέρηση που βλέπεις ως πτώση επιδόσεων."

 

Οκ δηλαδή το defrag δεν βάζει στην σειρά τα κομμάτια των αρχείων ούτε βάζει σε σειρά τα αρχεία ούτε βάζει όλα τα αρχεία μαζί στην αρχή γιατί όπως λες «ο controller επιλεγει να γραψει σε blocks που δεν εχουν πολλα writes(wear levering)» ,οκ αυτό.

Ουσιαστικά δηλαδή απλά πάει μια βόλτα όλα τα αρχεία και ξαναγράφονται το ίδιο τυχαία (όπου νάνε στον δίσκο αναλόγως το wear leveling) με πριν το defrag, σπαταλώντας write cycles.

«αντιθετα δημιουργεις invalid pages»

Αυτό συνεχίζω να μην το καταλαβαίνω,γιατί δημιουργεί invalid αφού δεν κάνει ούτε delete ούτε προσθέτει στοιχεία;

Ο μόνος λόγος να βγάζει invalid θα ήταν αν πραγματικά θα άλλαζε την σειρά των αρχείων και τον κομματιών τους,που όπως είπαμε δεν συμβαίνει.

 

To defrag θα προσπαθησει να μεταφέρει δεδομένα κ να τα βαλει σε σειρα.

Μονο που το αν ειναι σε σειρα ή οχι δεν προσφερει πλεονέκτημα στους ssd. Οπως ειπα κ προηγομενως, δεν μας ενδιαφέρει να εινα ΣΥΝΕΧΟΜΕΝΑ τα blocks στους ssd.

 

Και απο την στιγμη που το defrag θα κανει μεταφορα δεδομένων, σημαίνει οτι θα δημιουργήσει invalid pages, δηλαδη pages που πριν ειχαν δεδομένα αλλα τωρα δεν εχουν λογω μεταφορας, χωρις ομως αυτο να το ξερει ο ssd.

[TheELF]

«Τα εχεις μπερδεμενα. Το wear leveling δεν καθυστερει τους ssd, αλλα τα invalid pages καθυστερουν τους ssd»

 

Δεν μας ενδιαφερουν οι μεγαλες συνεχομενες περιοχες με free page στους ssd, γιατι ακομα και αν υπαρχουν, ο controller επιλεγει να γραψει σε blocks που δεν εχουν πολλα writes(wear levering, για να μην κουραζονται συνεχεια τα ιδια cells και χαλασουν) και δεν τον νοιαζει να γραφει σε γειτονικα block.

 

Οπως σου ειπα, σκεφτεσαι με λογικη hdd, ενω μιλαμε για ssd.

Σύμφωνα με εσένα το wear leveling είναι η αιτία που δεν μας ενδιαφέρουν τα συνεχόμενα,η εμφανείς πτώση ταχύτητας στους ssd είναι όταν πέφτει από την sequential στην random ταχύτητα,και λες ότι εγώ τα έχω μπερδεμένα;;;;   

Πας να μας τρελάνεις πιστεύω,δηλαδή τα sequential read/write που διαφημίζουν οι ssd είναι ένα ψέμα και μισό;;
Αν υπάρχουν αυτές οι sequential ταχύτητες τότε μας παρά ενδιαφέρει να υπάρχουν συνεχόμενες περιοχές αφού θέλουμε να αξιοποιήσουμε αυτήν την sequential ταχύτητα.
Δες εδώ (και είναι από το atto που είναι και το ποιο δίκαιο για τους ssd) και πες μετά ότι οι ssd γενικά δεν χάνουν σε ταχύτητα όταν διαβάζουν μικρά τμήματα (4K σε αυτό γράφει το λειτουργικό) ναι υπάρχουν δίσκοι που μένουν πάντα το ίδιο ταχύ και σε μικρά τμήματα αλλά είναι πολύ μεγάλο και το τμήμα των δίσκων που χάνουν σε ταχύτητα.

Και συνεχίζεις και συνεχίζεις να λες ότι το defrag φτιάχνει invalid pages,αφού υπάρχει όμως το trim που της μετατρέπει σε free που το πρόβλημα;;;(ντάξη το ότι κάνει write το καταλάβαμε,μην το ξανά λες... ) 

[haHa]

«Τα εχεις μπερδεμενα. Το wear leveling δεν καθυστερει τους ssd, αλλα τα invalid pages καθυστερουν τους ssd»

 

 

Σύμφωνα με εσένα το wear leveling είναι η αιτία που δεν μας ενδιαφέρουν τα συνεχόμενα,η εμφανείς πτώση ταχύτητας στους ssd είναι όταν πέφτει από την sequential στην random ταχύτητα,και λες ότι εγώ τα έχω μπερδεμένα;;;;   

 

Για αυτο σου λεω οτι τα εχεις μπερδεμενα..

Ποιος σου ειπε οτι η πτωση ταχυτητας του ssd ειναι " όταν πέφτει από την sequential στην random ταχύτητα".

 

Οπως σου ειπα, καλυτερα να διαβασεις...

 

Πας να μας τρελάνεις πιστεύω,δηλαδή τα sequential read/write που διαφημίζουν οι ssd είναι ένα ψέμα και μισό;;

Αν υπάρχουν αυτές οι sequential ταχύτητες τότε μας παρά ενδιαφέρει να υπάρχουν συνεχόμενες περιοχές αφού θέλουμε να αξιοποιήσουμε αυτήν την sequential ταχύτητα.

 

 

Δεν ισχυει κατι τετοιο, τα εχεις μπερδεμενα.

 

Σκεφτεσαι με ορους hdd, ενω μιλαμε για ssd.

Οι ταχυτητες sequential δεν αναφερονται σε εγγραφη σε μεγαλες συνεχομενες περιοχες(αλλωστε οι ssd ΔΕΝ γραφουν σε μεγαλες συνεχομενες περιοχες, λογω wear leveling).

Στο αφηνω σαν homework για να βρεις σε τι αναφερονται.

 

--------------------------

 

 

Τελικως μαλλον καταληγουμε οτι δεν ξερεις να διαβαζεις , αφου πολλες φορες γραψαμε για ποιο λογο οι ssd γινονται πιο αργοι, αλλα εσυ πιστευεις οτι γινονται πιο αργοι επειδη η ταχυτητα τους πεφτει απο sequential σε random λογω μη συνεχομενων περιοχων.

Στα ξαναποσταρω μπας και μαθεις να διαβαζεις:

 

 

Καμμια σχεση με fragmentation, που φυσικα οχι μονο δεν βοηθαει, αλλα μαλιστα χειροτερευει την κατασταση, γιατι γραφει ακομα περισσοτερα block-pages προσπαθωντας να κανει μεταφορες, οποτε ο SSD νομιζει οτι ειναι ακομα πιο γεματος και οταν θα χρειαστει να γραψει πανω σε block-page που ηταν πριν γραμμενο, θα κανει περισσοτερη ωρα.

 

Εκει μπαινει το TRIM και χοντρικα τρεχει ενα command για να ενημερωσει τον SSD οτι πραγματι σβηστηκαν τελειως τα block-pages που ηταν πριν γραμμενα και ετσι την επομενη φορα ο SSD θα γραψει σε αυτα κατευθειαν χωρις να χρειαζεται να τα κανει move-erase-write, αλλα κατευθειαν write.

 

 

 

Οταν σβηνεις ενα αρχειο ή το μεταφερεις (αυτο που κανει το defragment), τοτε το page που το περιειχε , δεν γινεται free/empty, αλλα invalid page.

Και οταν ο SSD παει να γραψει σε invalid page(θεωρει οτι ειχε δεδομενα) κ ετσι η διαδικασια ειναι αρκετα πιο αργη, γιατι πρεπει να κανει  move-erase-write και οχι κατευθειαν write.

Το TRIM και το secure erase φροντιζουν να μετατρεψουν ολα τα invalid pages σε free/empty pages ωστε να γινεται κατευθειαν write σε αυτα.

Το defragment δεν μπορει να το κανει αυτο, αλλα αντιθετα επειδη χρησιμοποιει χωρο για τις μεταφορες, δημιουργουνται ακομα περισσοτερα invalid pages(δηλαδη pages που ειχαν data,αλλα σβηστηκαν απο το ΛΕΙΤΟΥΡΓΙΚΟ χωρις να ειδοποιηθει ο SSD κ ετσι δεν μπορει να κανει write κατευθειαν πανω τους) σε σχεση με πριν το defrag.

 

Όπως σημειώσαμε και πιο πάνω, όταν διαγράφεις ένα αρχείο, στην ουσία δεν διαγράφεται το αρχείο αλλά ορίζεται από το λειτουργικό ως κενός χώρος το κομμάτι που καταλάμβανε. Ο SSD δεν το γνωρίζει και έτσι όταν πάει να γραψει πάνω σε αυτό ξανά έχει καθυστέρηση καθώς πρέπει να διαγράψει ή να μετακινήσει ότι ήταν εκεί πρώτα και μετά να κάνει την εγγραφή (αυτό το κάνει ο SSD controller).

[TheELF]

Για αυτο σου λεω οτι τα εχεις μπερδεμενα..

Ποιος σου ειπε οτι η πτωση ταχυτητας του ssd ειναι " όταν πέφτει από την sequential στην random ταχύτητα".

Αυτός που σκέφτεται να κάνει secure erase για να ξανά αυξηθεί...

Νομίζεις πραγματικά ότι κατάλαβε την αρκετά μικρή διαφορά στην ταχύτητα επειδή άρχισε να πιάνει το garbage collection;;;

Ή κατάλαβε αυτήν την διαφορά(seq. με 4k)

https://www.google.gr/search?safe=off&hl=el&site=imghp&tbm=isch&source=hp&biw=1024&bih=621&q=ssd+benchmark&oq=ssd+&gs_l=img.3.0.0l8j0i24l2.2533.3903.0.4900.6.5.1.0.0.0.188.705.0j5.5.0...0.0...1ac.1.14.img.foVVYT34OeQ

τι θεωρείς ποιο λογικό;;

[haHa]

Αυτός που σκέφτεται να κάνει secure erase για να ξανά αυξηθεί...

Που το ειπε αυτο?

Οτι η πτωση της ταχυτητας του ssd ειναι " όταν πέφτει από την sequential στην random ταχύτητα".

 Δειξε το ποστ, διαφορετικα σταματα τα ψεμματα. 

[TheELF]

Που το ειπε αυτο?

Οτι η πτωση της ταχυτητας του ssd ειναι " όταν πέφτει από την sequential στην random ταχύτητα".

 Δειξε το ποστ, διαφορετικα σταματα τα ψεμματα.

Είναι πολύ απλό, το garbage collection γίνεται στο παρασκήνιο,οπότε δεν το καταλαβαίνει κάποιος,και ακόμα και να το καταλάβει θα είναι αρκετά μικρή διαφορά,κανένας λογικός άνθρωπος δεν θα μπει στον κόπο να κάνει secure erase + win install + drivers + programs + updates , για κάτι που δεν το καταλαβαίνει.

 

Πες μου εσύ σε ποια περίπτωση και πόσο έντονα μπορεί κάποιος να καταλάβει το garbage collection;

 

Να και το post

δεν αναφερομαι τοσο στο λειτουργικο, αλλα στο πως θα επαναφερω το δισκο στην αρχικη του κατασταση , επειδη ειναι ssd.

Ο δισκος φαινεται να εχει μεγαλη πτωση, στην αρχη (1 χρονο πριν) τα disk test μου εδιναν 250gb read/write , ενω τωρα εχουν πεσει στα 70/150 !

Σύγκρινε αυτά τα νούμερα με αυτά από το ssd benchmark και θα καταλάβεις (ακόμα και εσύ) ότι μιλάμε για πτώση αυτό sequential σε random.

Διαφορετικά δείξε μου κάποιο άρθρο που να λέει ότι το garbage collection μπορεί να έχει τόσο δραματική πτώση ταχύτητας...

[haHa]

Συνεχιζεις τα ψεμματα.

Πουθενα δεν εγραψε ο φιλος toxotis70 οτι η πτωση της ταχυτητας του ssd ειναι λογω οτι "επεσε απο την sequential στην random".

 

Και φυσικα ακομα να καταλαβεις οτι η πτωση της ταχυτητας του ssd λογω χρησης(κ υπαρξης invalid pages κλπ) δεν εχει σχεση με το random κ sequential performance, παρα μονο στο μυαλο μερικων...

 

 

--------------------------------
 

Σκεφτεσαι με ορους hdd, ενω μιλαμε για ssd.

Οι ταχυτητες sequential δεν αναφερονται σε εγγραφη σε μεγαλες συνεχομενες περιοχες(αλλωστε οι ssd ΔΕΝ γραφουν σε μεγαλες συνεχομενες περιοχες, λογω wear leveling).

Στο αφηνω σαν homework για να βρεις σε τι αναφερονται.

Για οποιον θελει να διαβασει κ μπορει να καταλαβει γιατι οι μετρησεις σε ssd για random γινονται με 4kb αρχεια , ενω για sequential  γινονται με 128kb.

Στους ssd, οταν γραφεις αρχεια των 4kb, ο ssd αναγκαζεται να κανει γραψιμο 128kb(ή κ παραπανω, πχ 512kb=block) , οποτε ειναι πιο αργος κ για αυτο ονομαζουν αυτο το τεστ random.

Οταν ομως τα αρχεια ειναι μεγαλυτερα των 128kb, τοτε ο ssd δεν χρειαζεται να γραψει παραπανω, οποτε εχει καλυτερες ταχυτητες.

Ολα αυτα φυσικα δεν εχουν καμμια σχεση με την πτωση αποδοσης του ssd λογω χρησης,invalid pages και απουσιας trim. Ουτε φυσικα χρειαζεται ο ssd μεγαλες ΣΥΝΕΧΟΜΕΝΕΣ περιοχες, μιας και δεν γραφει ΣΥΝΕΧΟΜΕΝΑ block. Προσπαθει να αποφευγει να γραφει ΣΥΝΕΧΟΜΕΝΑ block για να μην φθειρει συνεχεια τα ιδια. (wear levering)

 

 

http://www.anandtech.com/show/2829/3

 

 

On the other side we have how NAND flash stores data, in groups of cells called pages. These days a 4KB page size is common.

In reality there’s no fence that separates the two, rather a lot of logic, several busses and eventually the SSD controller. The latter determines how the LBAs map to the NAND flash pages.

 

The most straightforward way for the controller to write to flash is by writing in pages. In that case the logical page size would equal the physical page size.

Unfortunately, there’s a huge downside to this approach: tracking overhead. If your logical page size is 4KB then an 80GB drive will have no less than twenty million logical pages to keep track of (20,971,520 to be exact). You need a fast controller to sort through and deal with that many pages, a lot of storage to keep tables in and larger caches/buffers.

The benefit of this approach however is very high 4KB write performance. If the majority of your writes are 4KB in size, this approach will yield the best performance

If you don’t have the expertise, time or support structure to make a big honkin controller that can handle page level mapping, you go to a larger logical page size. One such example would involve making your logical page equal to an erase block (128 x 4KB pages). This significantly reduces the number of pages you need to track and optimize around; instead of 20.9 million entries, you now have approximately 163 thousand. All of your controller’s internal structures shrink in size and you don’t need as powerful of a microprocessor inside the controller.

 

The benefit of this approach is very high large file sequential write performance. If you’re streaming large chunks of data, having big logical pages will be optimal. You’ll find that most flash controllers that come from the digital camera space are optimized for this sort of access pattern where you’re writing 2MB - 12MB images all the time.

Unfortunately, the sequential write performance comes at the expense of poor small file write speed. Remember that writing to MLC NAND flash already takes 3x as long as reading, but writing small files when your controller needs large ones worsens the penalty. If you want to write an 8KB file, the controller will need to write 512KB (in this case) of data since that’s the smallest size it knows to write. Write amplification goes up considerably.

[Palp]

Το secure erase είχε περισσότερο νόημα στους πρώτους SSD που δεν είχαν TRIM ή Garbage collection, ή όταν το λειτουργικό δεν υποστήριζει TRIM (πχ windows vista ή παλαιότερες εκδόσεις του MacOS). Έτσι καθώς με την χρήση έπεφταν οι επιδόσεις, για να τις επαναφέρεις ο μόνος τρόπος ήταν το secure erase και η επαναεγκατάσταση του λειτουργικού.

 

Μία σημείωση για το TRIM/GC. Το Trim είναι εντολή που υποστηρίζεται από τον SSD και δίνεται από το λειτουργικό. Το GC είναι διαδικασία που γίνεται από τον SSD ανεξάρτητα από το λειτουργικό και δεν είναι τόσο αποτελεσματική όσο το TRIM.

 

Επίσης η εντολή TRIM λειτουργεί μόνο σε intel 6 & 7-series σε RAID-0, σε παλαιότερα chipsets πρέπει να βασιστείς στο GC.

 

Έτσι σήμερα κάνεις secure erase αν: 1) έχεις παλιό SSD 2) δεν υποστηρίζει TRIM το λειτουργικό 3) έχεις raid-0 σε pre 6-series chipset.

 

Τώρα αν κάποιος θα μπει στον κόπο να κάνει secure erase ή όχι εξαρτάται από τον χρήστη. Μερικοί θέλουν να έχουν τα πάντα στο 100% και κάποιοι άλλοι δεν τους ενδιάφέρει και τόσο.

Ο topic starter ενδιαφέρεται για τις επιδόσεις οπότε η λύση για αυτόν είναι secure erase.