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

[TheELF]

Ωραία και καλά αυτά για το write,το read γιατί πέφτει σε ταχύτητα;;;

[Palp]

Και μετά βέβαια θα τον βάλεις στο ντουλαπάκια σου;;;Είπαμε ότι θα ξανά χτίσει και όλο του το σύστημα... 

 

1.5 εγγραφες... καταστροφή για το δίσκο...

[haHa]

Και μετά βέβαια θα τον βάλεις στο ντουλαπάκια σου;;;Είπαμε ότι θα ξανά χτίσει και όλο του το σύστημα... 

Ειπαμε:

"To secure erase φροντιζει ωστε ολα τα blocks που ειχαν δεδομενα πριν να γινουν free blocks, ωστε να μπορει ο ssd να κανει write κατευθειαν πανω τους και να μην χρειαζεται να κανει read-modify-write που καθυστερει."

 

Οποτε αφοτου χτισει ολο του το συστημα, ο υπολοιπος χωρος θα ειναι με free blocks, αρα ο ssd θα κανει κατευθειαν write και οχι read-modify-write(που θα εκανε περιπτωση με invalid pages και blocks) , κατι που θα τον καθυστερουσε.

 

Το defrag ομως δεν μπορει να δημιουργησει free blocks και για αυτο δεν προσφερει καμμια βελτιωση επιδοσεων.

[TheELF]

Ωραία όλα αυτά(μιας και είσαστε σίγουροι ότι δεν υπάρχει trim και υπό αυτές της συνθήκες οκ μόνο το se θα κάνει κάτι),αλλά πως επιδρούν στο read;;;;

Εδώ υπάρχει μεγάλη πτώση στο read που δεν την εξηγεί τίποτα από αυτά που είπατε.

[haHa]

Ωραία όλα αυτά(μιας και είσαστε σίγουροι ότι δεν υπάρχει trim και υπό αυτές της συνθήκες οκ μόνο το se θα κάνει κάτι),αλλά πως επιδρούν στο read;;;;

Εδώ υπάρχει μεγάλη πτώση στο read που δεν την εξηγεί τίποτα από αυτά που είπατε.

 

To defrag δεν θα βοηθουσε σε καμμια περιπτωση, αυτο ακομα να το καταλαβεις..

 

Αντιθετα, trim και secure erase βοηθανε την κατασταση.

 

Για την πτωση του read χρειαζομαστε κ αλλες πληροφοριες, αλλα προφανως ο topic starter δεν συμμετεχει, ισως να ενοχληθηκε απο τα ανακριβειες και τις συμβουλες για defrag .

[TheELF]

Εξαρτάτε πάντα από τον δίσκο.
Μάθε λίγο τι θεωρεί sequential όλος ο κόσμος (εκτός από εσένα)
http://en.wikipedia.org/wiki/IOPS

Sequential operations access locations on the storage device in a contiguous manner and are generally associated with large data transfer sizes, e.g., 128 KB.

 

contiguous = συνεχόμενα

Έμφαση στην εικόνα

 

Γιατί νομίζει ότι όλοι οι κατασκευαστές δίνουν sequential read/write σε mb/sec ενώ τα random τα δίνουν σε iops(και τα έχουν και κρυφά,πρέπει να τα ψάξεις);;;

Ακριβός για να μην βλέπει ο κόσμος ταχύτητες τύπου 100-200mb/sec(πραγματικές random 4k qd32) και δεν τους πάρει.

 

Αν λοιπόν ένας δίσκος έχει πολύ ψιλό sequential(όπως το εξηγούν στο πάνω wiki) σε σχέση με τα random iops τότε έχει όφελος από συνεχόμενο ελεύθερο χώρο,σε κάθε άλλη περίπτωση δεν έχει. 

[haHa]

Τα εχεις μπερδεμενα και επιμενεις οτι το defrag βοηθαει!!!!

 

To TRIM και το secure erase φροντιζει αυτο ακριβως:

να υπαρχουν free blocks των 128kb(ή των 512kb)

 

To defrag ομως δεν μπορει να το κανει αυτο.

 

Στα εξηγησα κ πιο πριν, αλλα δεν το καταλαβες:

http://www.insomnia.gr/topic/486446-επαναφορά-ssd-στην-αρχική-του-κατάσταση-για-αποκατ/?p=52372348

 

 

 

Για οποιον θελει να διαβασει κ μπορει να καταλαβει γιατι οι μετρησεις σε 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.

[iniohos]

Κανοντας καποιος secure erase, σημαινει πως θα πρεπει να ξαναπερασει τα παντα απο την αρχη?

Δηλαδη σβηνετε τελειως ο δισκος?

[haHa]

Κανοντας καποιος secure erase, σημαινει πως θα πρεπει να ξαναπερασει τα παντα απο την αρχη?

Δηλαδη σβηνετε τελειως ο δισκος?

Ναι.

Αλλα αν εχει TRIM, δεν το πολυχρειαζεται το secure erase, παρα μονο σε ακραιες περιπτωσεις.

 

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

[TheELF]

Τα εχεις μπερδεμενα και επιμενεις οτι το defrag βοηθαει!!!!

 

128kb συνεχομενα μπορεις να βρεις ανα πασα στιγμη σε εναν ssd, γιατι αυτο ειναι το μικροτερο που μπορει να γραψει.

 

Και εκει ειναι το σημαντικο: οτι στους ssd δεν εχει νοημα πανω απο 128kb(ή 512kb) συνεχομενα, για αυτο και τα benchmark γινονται με 128kb δεδομενα και με 4k γινονται για τα small files.

To TRIM και το secure erase φροντιζει αυτο ακριβως:

να υπαρχουν free blocks των 128kb(ή των 512kb)

Άλλα γράφω εγώ και σε άλλα απαντάς εσύ...

Είδες τι σημαίνει sequential;;; Είδες την εικόνα;;;;

Καταλαβαίνεις την διαφορά που μπορεί να έχει στο read αυτό το πράγμα;;;;;;

Σου δίνω στοιχεία και εσύ επιμένεις να λες της ίδιες ιστορίες συνεχώς.

[haHa]

Άλλα γράφω εγώ και σε άλλα απαντάς εσύ...

Είδες τι σημαίνει sequential;;; Είδες την εικόνα;;;;

Καταλαβαίνεις την διαφορά που μπορεί να έχει στο read αυτό το πράγμα;;;;;;

Σου δίνω στοιχεία και εσύ επιμένεις να λες της ίδιες ιστορίες συνεχώς.

Mια χαρα ξερω τι σημαινει sequential κ σου εξηγησα γιατι τα τεστ στους ssd για sequential γινονται με πολλα δεδομενα των 128kb/512kb block(πχ 100mb δεδομενων me block 128/512) και οχι πχ με ενα αρχειο των 100mb:

γιατι πολυ απλα οι ssd γραφουν ανα 128kb(ή 512kb) και οχι σε γειτονικα blocks(λογω wear leveling), αρα δε μας ενδιαφερει να ειναι ΣΥΝΕΧΟΜΕΝΑ τα blocks.

 

Σε μικρα αρχεια (4kb) ειναι πιο αργοι, γιατι πρεπει να γραψουν 128kb(ή 512kb) παρολο που εχουν ενα αρχειο των 4kb μονο.

Σε αρχεια μεγαλυτερα των 128kb(ή 512kb), δεν εχει σχεση για την ταχυτητα αν ειναι συνεχομενα τα ελευθερα blocks  . Αρκει μονο να υπαρχουν ελευθερα blocks, για  read-modify-write.

 

Ειναι οπως ειπαμε σημαντικο* να υπαρχουν free blocks των 128kb(ή 512kb). Αυτο το καταφερνεις μονο με trim ή secure erase.

To defrag μπορει να δημιουργει μεγαλες ΣΥΝΕΧΟΜΕΝΕΣ περιοχες με free space(για το λειτουργικο , οχι για τον ssd που αυτες οι περιοχες ειναι με invalid blocks), αλλα αυτες οι περιοχες δεν ειναι με free blocks, για  αυτο δεν βελτιωνει τις επιδοσεις.

 

 

*

Τo secure erase φροντιζει ωστε ολα τα blocks που ειχαν δεδομενα πριν να γινουν free blocks, ωστε να μπορει ο ssd να κανει write κατευθειαν πανω τους και να μην χρειαζεται να κανει read-modify-write που καθυστερει.

 

Το defrag δεν βοηθαει σε τιποτα(δεν μπορει δημιουργησει free blocks, αρα την επομενη φορα που θα παει να γραψει ο ssd θα αργησει γιατι θα πρεπει να κανει read-modify-write και οχι κατευθειαν write)

 

Επεξ/σία 21 Μαΐου 2013 από haHa

[TheELF]

 

1000mb (1gb) αρχείο δοκιμής ... 425mb/sec στο sequential  94mb/sec στο 4κ (qd32 que depth ότι δηλαδή γράφει σε 32 pages ταυτόχρονα)

 

 

(Και πόσες φορές το είπα ότι το defrag το λέω σε συνδυασμό με το trim)

[haHa]

Προς ενημερωση:

http://crystalmark.info/software/CrystalDiskMark/manual-en/MainWindow.html

 

 

 

Test Types

• All : All Test (Seq, 512K, 4K, 4K QD32)
• Seq : Sequential Read/Write Test (Block Size = 1024KB)
• 512K : Random Read/Write Test (Block Size = 512KB)
• 4K : Random Read/Write Test (Block Size = 4KB)
• 4K QD32 : Random Read/Write Test (Block Size = 4KB, Queue Depth = 32) for NCQ&AHCI

 

 

1000mb (1gb) αρχείο δοκιμής ..

1000ΜΒ ειναι τα δεδομενα, δεν ειναι μονο ενα αρχειο..

 

Me 1000MB δεδομενων(ωστε να εχουν πολλες μετρησεις) κανουν διαφορα τεστ: με 4kb block(που οπως ειπαμε οι ssd ειναι αργοι γιατι γραφουν ανα 128/512kb, ακομα κ αν εχουν μονο 4kb να γραψουν ), με 512kb block κλπ.

 

Τελος, εχεις καταλαβει οτι οι ssd δεν γραφουν σε συνεχομενα block??

 

 

 

(Και πόσες φορές το είπα ότι το defrag το λέω σε συνδυασμό με το trim)

Οχι δεν το ειπες σε συνδυασμο με το trim.

Δες εδω τι ειπες:

(Μπορείς και απλά να ρίξεις ένα defrag και να τελειώνεις,υπάρχουν και ειδικά defrag με λιγότερα write,αν σκεφτείς πόσα write θα κάνει η εγκατάσταση και τα προγράμματα που θα ξαναπεράσεις + το secure erase,δεν έχει μεγάλη διαφορά,μπορεί να κάνει ακόμα και λιγότερα write το defrag) 

 

 

 

Αλλα ακομα και για τον συνδυασμο defrag με trim, τι θα προσεφερε διαφορετικο απο το σκετο trim δεν μας ειπες.

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

[georgeadams]

Τι κάνετε ωρέ; Όχι άλλο κάρβουνο!

[TheELF]

Ας το ρίξουμε στην μαθηματική λοιπόν....

 

Ας πούμε ότι ο ssd έχει blocksize 128kb όπως λες.

 

 

Για να γράψει 1gb δεδομένα,δηλαδή 1000Χ1MB ή 1000χ1024kb

Τα 1024kb θέλουν 1024kb/128kb = 8 πράξεις για να γραφούν 

αν το πάρουμε επί 1000 βγαίνει 8000 iops για να γραφούν τα 1000mb.

 

Το 4κ με qd32 δηλαδή 32χ4κ γράφει 128kb με κάθε πράξη.

Τα 1024kb συνεχίζουν δηλαδή να θέλουν 8 πράξεις(1024kb/128kb) για να γραφούν

αν το πάρουμε επί 1000 βγαίνει 8000 iops για να γραφούν τα 1000mb.

 

 

Αφού θέλουν της ίδιες πράξεις (8000) για να γράψουν τα δεδομένα πως γίνεται το ένα να είναι στα 500mb/sec και το άλλο στα 90mb/sec;;;;;;

 

Όχι δεν είναι μαγικά είναι η διαφορά μεταξύ του sequential(που δεν πιστεύεις ότι υπάρχει) με το random.

Τι κάνετε ωρέ; Όχι άλλο κάρβουνο!

Κιάαααλο κιάαααλο