Stress menguji kartu SD menggunakan linux

19

Saya masuk ke sebuah perdebatan kecil dengan seseorang kemarin mengenai logika dan / atau kebenaran jawaban saya di sini , vis., Bahwa logging dan memelihara meta-data fs pada kartu SD berukuran (GB +) yang layak tidak akan pernah cukup signifikan untuk memakai kartu dalam jumlah waktu yang wajar (bertahun-tahun). Inti dari kontra-argumen tampaknya adalah bahwa saya pasti salah karena ada begitu banyak cerita online tentang orang-orang yang memakai kartu SD.

Karena saya memiliki perangkat dengan kartu SD di dalamnya yang berisi filesystem rw root yang tersisa pada 24/7, saya telah menguji premis sebelumnya untuk kepuasan saya sendiri. Saya telah mengubah tes ini sedikit, mengulanginya (menggunakan kartu yang sama, sebenarnya) dan saya mempresentasikannya di sini. Dua pertanyaan utama yang saya miliki adalah:

  1. Apakah metode yang saya gunakan untuk mencoba merusak kartu layak, mengingat itu dimaksudkan untuk mereproduksi efek terus menulis ulang sejumlah kecil data?
  2. Apakah metode yang saya gunakan untuk memverifikasi kartu masih layak?

Saya mengajukan pertanyaan di sini daripada SO atau SuperUser karena keberatan pada bagian pertama mungkin harus menyatakan bahwa tes saya tidak benar-benar menulis ke kartu seperti yang saya yakin, dan menyatakan bahwa akan memerlukan beberapa pengetahuan khusus tentang linux.

[Bisa juga kartu SD menggunakan semacam buffering pintar atau cache, sehingga menulis berulang ke tempat yang sama akan disangga / di-cache di suatu tempat yang kurang rentan untuk dikenakan. Saya belum menemukan indikasi ini di mana pun, tetapi saya bertanya tentang itu di SU]

Gagasan di balik tes ini adalah menulis ke blok kecil yang sama pada kartu jutaan kali. Ini jauh melampaui klaim berapa banyak siklus tulis yang dapat dipertahankan oleh perangkat seperti itu, tetapi menganggap leveling keausan efektif, jika kartu berukuran layak, jutaan penulisan semacam itu masih tidak terlalu penting, seperti "blok yang sama" tidak secara harfiah menjadi blok fisik yang sama. Untuk melakukan hal ini, saya perlu untuk memastikan setiap menulis itu benar-benar memerah ke perangkat keras, dan sama jelas tempat.

Untuk membilas ke perangkat keras, saya mengandalkan panggilan perpustakaan POSIX fdatasync():

#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <unistd.h>
#include <stdlib.h>

// Compile std=gnu99

#define BLOCK 1 << 16

int main (void) {
    int in = open ("/dev/urandom", O_RDONLY);
    if (in < 0) {
        fprintf(stderr,"open in %s", strerror(errno));
        exit(0);
    }

    int out = open("/dev/sdb1", O_WRONLY);
    if (out < 0) {
        fprintf(stderr,"open out %s", strerror(errno));
        exit(0);
    }

    fprintf(stderr,"BEGIN\n");

    char buffer[BLOCK];
    unsigned int count = 0;
    int thousands = 0;
    for (unsigned int i = 1; i !=0; i++) {
        ssize_t r = read(in, buffer, BLOCK);
        ssize_t w = write(out, buffer, BLOCK);
        if (r != w) {
            fprintf(stderr, "r %d w %d\n", r, w);
            if (errno) {
                fprintf(stderr,"%s\n", strerror(errno));
                break;
            }
        }
        if (fdatasync(out) != 0) {
            fprintf(stderr,"Sync failed: %s\n", strerror(errno));
            break;
        }
        count++;
        if (!(count % 1000)) {
            thousands++;
            fprintf(stderr,"%d000...\n", thousands);
        }
        lseek(out, 0, SEEK_SET);
    }
    fprintf(stderr,"TOTAL %lu\n", count);
    close(in);
    close(out);

    return 0;
}                                 

Saya menjalankan ini selama ~ 8 jam, sampai saya mengumpulkan 2 juta + penulisan ke awal /dev/sdb1partisi. 1 Saya bisa saja dengan mudah menggunakan /dev/sdb(perangkat mentah dan bukan partisi) tetapi saya tidak bisa melihat apa bedanya ini.

Saya kemudian memeriksa kartu dengan mencoba membuat dan me-mount sistem file aktif /dev/sdb1. Ini berhasil, menunjukkan blok spesifik yang telah saya tulis sepanjang malam itu layak. Namun, itu tidak berarti bahwa beberapa wilayah kartu tidak aus dan tergeser oleh leveling keausan, tetapi tetap dapat diakses.

Untuk mengujinya, saya gunakan badblocks -v -wpada partisi. Ini adalah tes baca-tulis yang merusak , tetapi leveling aus atau tidak, itu harus menjadi indikasi kuat kelayakan kartu karena masih harus memberikan ruang untuk setiap rolling menulis. Dengan kata lain, itu setara dengan mengisi kartu sepenuhnya, lalu memeriksa bahwa semua itu baik-baik saja. Beberapa kali, sejak saya membiarkan badblock bekerja melalui beberapa pola.

[Komentar Contra Jason C di bawah ini, tidak ada yang salah atau salah tentang menggunakan badblocks dengan cara ini. Meskipun tidak akan berguna untuk mengidentifikasi blok-blok buruk karena sifat kartu SD, tidak apa-apa untuk melakukan tes baca-tulis destruktif dengan ukuran acak menggunakan -bdan -csakelar, yang merupakan tempat uji revisi berjalan (lihat jawaban saya sendiri) ). Tidak ada jumlah sihir atau caching oleh pengontrol kartu yang dapat mengelabui tes di mana beberapa megabyte data dapat ditulis ke perangkat keras dan dibaca kembali dengan benar. Komentar Jason yang lain tampaknya didasarkan pada kesalahan membaca - IMO yang disengaja , itulah sebabnya saya tidak repot-repot berdebat. Dengan kepala itu, saya serahkan kepada pembaca untuk memutuskan apa yang masuk akal dan apa yang tidak .]

1 Kartu itu adalah kartu Sandisk 4 GB lama (tidak ada nomor "kelas" di atasnya) yang jarang saya gunakan. Sekali lagi, perlu diingat bahwa ini bukan 2 juta menulis ke tempat fisik yang sama secara harfiah; karena leveling keausan, "blok pertama" akan dipindahkan secara konstan oleh pengontrol selama pengujian, seperti yang dinyatakan dalam istilah, leveling keausan.

goldilocks
sumber
Ini adalah tes yang tidak dapat diandalkan untuk alasan yang diuraikan di bawah ini. Anda juga tidak dapat menggunakan badblocksuntuk menunjukkan kegagalan halaman pada flash drive (dan mengklaim itu sangat menyesatkan). Itu ditangani oleh pengontrol dan dipetakan untuk menyediakan ruang ketika terdeteksi. Tata letak fisik data pada drive tidak sama dengan tata letak fisik yang Anda lihat ketika melakukan I / O, karena itulah leveling aus menjaga transparansi. Semua ini tidak terlihat oleh Anda selama I / O. Paling-paling, jika drive mendukung SMART, Anda bisa mendapatkan sedikit info tentang kegagalan dan ruang yang tersisa dari pengontrol.
Jason C
Adapun /dev/sdb1vs /dev/sdbtidak ada bedanya untuk program Anda, tetapi apa yang membuat perbedaan (seperti yang dijelaskan di bawah) adalah bahwa negara blok yang tidak digunakan pada perangkat Anda tidak diketahui dan belum ditemukan dalam pengujian Anda, dan kecuali Anda mengisi seluruh perangkat (misalnya /dev/sdb) dengan data pertama, jumlah levelling ruang pakai harus bekerja dengan adalah variabel utama. Jadi, sementara perangkat vs partisi tidak relevan untuk pengujian Anda, yang sebagian besar merupakan konsekuensi dari pengujian cacat, seperti setelah mengisi perangkat dengan data dengan benar, per-partisi tidak akan menjadi pilihan yang tersedia (kecuali Anda diformat setelah).
Jason C
Namun poin lain yang membuat tes Anda tidak realistis adalah bahwa halaman dapat (dan biasanya tidak) gagal tetapi masih meninggalkan kartu SD 100% dapat digunakan setelahnya. Dalam kasus di mana kegagalan terdeteksi dan ditutupi oleh pengontrol tetapi data tidak dapat dibaca, data sistem file dapat menjadi rusak ketika pengontrol mencoba menyalin blok.
Jason C
Saya memberitahu Anda apa - menjelaskan kepada saya dalam hal tertentu sebuah tes direproduksi yang tidak memakai kartu SD keluar, dan kemudian saya akan membawa Anda serius. "Klaim dari otoritas" yang tak dapat direproduksi dan anekdot pribadi hanyalah itu. Argumentum ab auctoritate
goldilocks
1
Saya tidak tahu tentang kartu itu, tetapi kebanyakan dari mereka setidaknya sudah sedikit mati. Orang-orang ini meretas mikrokontroler pada setidaknya satu merek kartu SD: bunniestudios.com/blog/?p=3554 Jam-bicara yang mereka lakukan pada subjek cukup bagus.
mikeserv

Jawaban:

11

Saya pikir stress testing kartu SD pada umumnya bermasalah diberikan 2 hal:

  1. memakai leveling Tidak ada jaminan bahwa satu menulis ke yang berikutnya sebenarnya berolahraga di lokasi fisik yang sama di SD. Ingatlah bahwa sebagian besar sistem SD yang ada aktif mengambil blok seperti yang kita ketahui dan memindahkan lokasi fisik yang membelakanginya berdasarkan "keausan" yang dirasakan bahwa setiap lokasi telah dikenai.

  2. perbedaan teknologi (MLC vs SLC) Masalah lain yang saya lihat adalah perbedaan dalam teknologi. Tipe SLC dari SSD yang saya harapkan memiliki umur yang jauh lebih lama vs varietas MLC. Juga ada banyak toleransi yang lebih ketat pada MLC yang Anda tidak harus berurusan dengan SLC, atau setidaknya mereka jauh lebih toleran terhadap kegagalan dengan cara ini.

    • MLC - Sel Multi Level
    • SLC - Sel Level Tunggal

Masalahnya dengan MLC adalah bahwa sel yang diberikan dapat menyimpan banyak nilai, bit pada dasarnya ditumpuk menggunakan tegangan, bukan hanya menjadi fisik + 5V atau 0V, misalnya, jadi ini dapat menyebabkan potensi tingkat kegagalan yang jauh lebih tinggi daripada SLC mereka. setara.

Harapan hidup

Saya menemukan tautan ini yang membahas sedikit tentang berapa lama perangkat keras dapat bertahan. Judulnya: Know Your SSDs - SLC vs. MLC .

SLC

SSD SLC dapat dihitung, sebagian besar, untuk hidup di mana saja antara 49 tahun dan 149 tahun, rata-rata, dengan perkiraan terbaik. Pengujian Memoright dapat memvalidasi SSD 128Gb yang memiliki usia ketahanan tulis lebih dari 200 tahun dengan rata-rata penulisan 100GB per hari.

MLC

Di sinilah desain mlc jatuh pendek. Belum ada yang dirilis. Tidak ada yang benar-benar memeriksa harapan hidup seperti apa yang dijamin dengan mlc kecuali bahwa, itu akan jauh lebih rendah. Saya telah menerima beberapa keyakinan berbeda yang rata-rata mencapai 10 hingga 1 umur yang mendukung desain slc. Perkiraan konservatif adalah bahwa sebagian besar perkiraan umur akan datang antara 7 dan 10 tahun, tergantung pada kemajuan 'algorythms levelling pakai' dalam pengontrol setiap produsen.

Perbandingan

Untuk menggambar perbandingan melalui siklus tulis, satu slc akan memiliki masa pakai 100.000 siklus tulis lengkap dibandingkan dengan mlc yang memiliki masa pakai 10.000 siklus tulis. Ini bisa meningkat secara signifikan tergantung pada desain 'wear leveling' yang digunakan.

slm
sumber
1
Leveling memakai WRT "Tidak ada jaminan bahwa satu penulisan ke yang berikutnya benar-benar menggunakan lokasi fisik yang sama di SD" - yang diasumsikan dalam pertanyaan slm! Sangat eksplisit, saya pikir ... Tanpa perataan keausan, saya tidak akan pernah berharap tes ini lulus karena saya akan melampaui batas umur siklus tulis yang dinyatakan. Tes ini dimaksudkan untuk membuktikan kemanjuran pemakaian level , bukan mengabaikannya. Fakta bahwa saya bisa menulis 2 juta kali untuk sama jelas tempat menunjukkan keawetan yang berlaku.
goldilocks
WRT # 2, kualitas dan teknologi tentu saja akan membedakan satu kartu dari yang lain. Maksud saya adalah bahwa kartu Sandisk run-of-the-mill murahan masih akan bertahan lebih lama daripada siapa pun benar-benar membutuhkannya juga jika jumlah data yang ditulis per hari relatif kecil.
goldilocks
@goldilocks - OK, OK, jangan menyalahkan saya tentang hal itu. 8-), jadi apa yang Anda katakan adalah jika saya menulis sejumlah besar data sehingga saya secara efektif menghilangkan keausan level dari persamaan, dan menjalankan badblock di atasnya, apakah itu cukup untuk menunjukkan kemanjuran leveling keausan?
slm
1
@goldilocks - apakah saya baru saja membuka kotak pandora?
slm
1
(Misalnya: Jika Anda mengkloning kartu SD dengan menulis gambar padanya dan tidak / tidak bisa fstrimsetelah itu, Anda telah sepenuhnya menonaktifkan perataan level dinamis [Anda akan sulit sekali menemukan kartu SD kelas konsumen dengan leveling statis]] oleh menandai setiap halaman sebagaimana digunakan.)
Jason C
6

Ada beberapa masalah dengan tes Anda, beberapa tidak jelas, beberapa tidak. Itu juga tergantung pada tujuan Anda. Dua masalah fuzzy yang halus:

  • Anda tidak membaca dari area yang sama dengan yang Anda tulis, tes membaca Anda secara efektif, maka, tidak melakukan apa-apa (kecuali controller telah membaca koreksi gangguan, dalam hal ini kadang-kadang dapat memindahkan halaman yang sedang dibaca ke tempat lain, tetapi ini masih tidak tidak memengaruhi tes Anda).
  • Anda berasumsi (dan kemungkinan besar, tetapi tidak dijamin) bahwa blok baca / tulis ke blok buruk terdeteksi dan dilaporkan oleh pengontrol - Anda ingin menulis data, membacanya kembali, dan membandingkannya dengan pemeriksaan yang dijamin.

Namun, itu bisa dibilang pedantic. Lebih serius adalah:

  • Anda tidak dapat menggunakan badblocksuntuk menampilkan halaman yang gagal pada memori flash; semua deteksi kegagalan dan pemetaan halaman selanjutnya dilakukan oleh pengontrol dan transparan untuk OS. Anda bisa mendapatkan beberapa info dari SMART jika drive mendukungnya (saya tahu tidak ada kartu SD yang mendukungnya, mungkin ada thumb drive yang lebih tinggi yang melakukannya).
  • Leveling aus, rumit oleh pengujian Anda yang tidak memperhitungkan perintah TRIM sebelumnya, status drive yang digunakan selama pengujian, dan ruang yang dipesan.

Leveling Wear: Masalah utama adalah leveling wear adalah variabel utama dalam tes Anda. Ini terjadi pada controller (biasanya), dan dalam hal apapun transparan untuk perangkat bahkan langsung mencari + baca / tulis. Dalam contoh Anda, Anda tidak benar-benar mengetahui status level keausan (khususnya, apakah perintah TRIM telah dikeluarkan untuk membebaskan blok baru-baru ini?) ...

Untuk meratakan keausan dinamis (ada di hampir semua perangkat penyimpanan kelas konsumen) pada perangkat Anda, maka, bisa dalam keadaan apa pun: Pada satu ekstrem, tidak ada halaman yang ditandai sebagai bebas, sehingga satu-satunya halaman controller harus bekerja dengan adalah yang ada di ruang yang dipesan (jika ada). Perhatikan bahwa jika ada yang ruang dicadangkan pada perangkat, itu akan harus gagal sepenuhnya sebelum Anda mulai mendapatkan dijamin gagal pada halaman menulis (menganggap tidak ada halaman lain ditandai sebagai bebas yang tersisa). Di sisi lain, setiap halaman ditandai sebagai bebas, dalam hal ini Anda secara teoritis harus membuat setiap halaman pada perangkat gagal sebelum Anda mulai melihat kegagalan penulisan.

Untuk leveling keausan statis (yang cenderung dimiliki SSD, kartu SD cenderung tidak memilikinya, dan thumb drive berbeda-beda): Tidak ada jalan lain, selain menulis berulang-ulang ke setiap halaman di perangkat.

... Dengan kata lain, ada detail perataan keausan yang Anda tidak memiliki cara untuk mengetahui dan tentu saja tidak ada cara untuk mengendalikan - terutama apakah perataan keausan dinamis digunakan atau tidak, apakah perataan keausan statis digunakan atau tidak, dan jumlah ruang yang disediakan pada perangkat untuk meratakan keausan (yang tidak terlihat melewati controller [atau driver dalam beberapa kasus, seperti M-Systems DiskOnChip lama]).

SLC / MLC: Sedangkan untuk SLC vs MLC, ini memiliki dampak yang sangat langsung pada batas yang Anda harapkan untuk dilihat, tetapi prosedur leveling keausan umum dan prosedur pengujian adalah sama untuk keduanya. Banyak vendor tidak mempublikasikan apakah perangkat mereka SLC atau MLC untuk produk konsumen yang lebih murah, meskipun setiap flash drive yang mengklaim batas siklus 100 k + per halaman kemungkinan SLC (tradeoff yang disederhanakan adalah SLC = daya tahan, MLC = kepadatan).

Caching: Adapun caching, agak rapuh. Pada level OS, dalam kasus umum, tentu saja, fsync / fdatasync tidak menjamin bahwa data sebenarnya ditulis. Namun, saya pikir aman untuk menganggap bahwa itu (atau setidaknya controller telah berkomitmen untuk melakukannya yaitu penulisan tidak akan tertelan dalam cache) dalam kasus ini, karena drive yang dapat dilepas umumnya dirancang untuk pola penggunaan umum "eject" (unmount> sync) lalu hapus (power cut). Meskipun kita tidak tahu pasti, dugaan yang berpendidikan mengatakan bahwa aman untuk menganggap bahwa jaminan sinkronisasi bahwa penulisan akan benar-benar terjadi, terutama dalam penulisan -> sinkronisasi -> baca kembali (jika tidak, drive tidak akan dapat diandalkan setelah dikeluarkan). Tidak ada perintah lain selain 'sinkronisasi' yang dapat dikeluarkan saat dikeluarkan.

Pada controller semuanya mungkin, tetapi asumsi di atas juga mencakup asumsi bahwa controller setidaknya tidak melakukan sesuatu yang "rumit" cukup untuk mengambil risiko kehilangan data setelah sinkronisasi. Dapat dibayangkan bahwa pengontrol dapat, katakanlah, buffer dan grup menulis, atau tidak menulis data jika data yang sama sedang ditulis ulang (sampai batas tertentu). Dalam program di bawah ini, kami bergantian antara dua blok data yang berbeda dan melakukan sinkronisasi sebelum membaca kembali secara khusus untuk mengalahkan mekanisme caching pengontrol yang masuk akal. Tetap, tentu saja, tidak ada jaminan dan tidak ada cara untuk mengetahui, tetapi kita dapat membuat asumsi yang masuk akal berdasarkan penggunaan normal perangkat ini dan mekanisme caching yang waras / umum.

Pengujian:

Sayangnya, kenyataannya adalah, kecuali jika Anda tahu bahwa perangkat tidak memiliki ruang yang disediakan dan tidak melakukan perataan statis, tidak ada cara untuk secara pasti menguji batas siklus halaman tertentu. Namun, yang terdekat yang bisa Anda dapatkan adalah sebagai berikut (menganggap tidak ada leveling statis):

Hal pertama yang perlu Anda lakukan adalah mengisi seluruh kartu dengan data. Ini penting, dan merupakan variabel utama yang tersisa dalam tes asli Anda. Ini menandai sebanyak mungkin blok yang digunakan, selain dari ruang yang dipesan (yang Anda tidak memiliki cara mengakses). Perhatikan bahwa kami bekerja dengan seluruh perangkat (yang akan memusnahkan semua data), karena bekerja dengan satu partisi hanya memengaruhi satu area spesifik pada perangkat:

dd if=/dev/urandom bs=512k of=/dev/sdb conv=fsync oflag=sync

Jika Anda adalah tipe bilah kemajuan:

pv -pterb -s <device_size> /dev/urandom | dd bs=512k of=/dev/sdb conv=fsync oflag=sync

Sunting: Untuk kartu dengan blok 4MB hapus, coba ini untuk menulis lebih cepat:

dd if=/dev/urandom bs=4M of=/dev/sdb conv=fsync oflag=direct,sync iflag=fullblock

Selanjutnya, Anda dapat menulis program pengujian siklus sebagai berikut, menggunakan O_DIRECTdan O_SYNC(dan mungkin paranoid, penggunaan berlebihan fsync()) untuk memotong sebanyak mungkin buffering OS dan caching out dari gambar dan, secara teoritis, menulis langsung ke controller dan tunggu sampai melaporkan bahwa operasi telah selesai:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <cstdlib>
#include <cstdio>
#include <cstring>

using namespace std;

static const int BLOCK_SIZE = 512;
static const int ALIGNMENT = 512;
static const int OFFSET = 1024 * ALIGNMENT; // 1024 is arbitrary


int main (int argc, char **argv) {

    if (argc != 2) {
        fprintf(stderr, "usage: %s device\n", argv[0]);
        return 1;
    }

    int d = open(argv[1], O_RDWR | O_DIRECT | O_SYNC);
    if (d == -1) {
        perror(argv[1]);
        return 1;
    }

    char *block[2], *buffer;
    int index = 0, count = -1;

    // buffers must be aligned for O_DIRECT.
    posix_memalign((void **)&(block[0]), ALIGNMENT, BLOCK_SIZE);
    posix_memalign((void **)&(block[1]), ALIGNMENT, BLOCK_SIZE);
    posix_memalign((void **)&buffer, ALIGNMENT, BLOCK_SIZE);

    // different contents in each buffer
    memset(block[0], 0x55, BLOCK_SIZE);
    memset(block[1], 0xAA, BLOCK_SIZE);

    while (true) {

        // alternate buffers
        index = 1 - index;

        if (!((++ count) % 100)) {
            printf("%i\n", count);
            fflush(stdout);
        }

        // write -> sync -> read back -> compare
        if (lseek(d, OFFSET, SEEK_SET) == (off_t)-1)
            perror("lseek(w)");
        else if (write(d, block[index], BLOCK_SIZE) != BLOCK_SIZE)
            perror("write");
        else if (fsync(d))
            perror("fsync");
        else if (lseek(d, OFFSET, SEEK_SET) == (off_t)-1)
            perror("lseek(r)");
        else if (read(d, buffer, BLOCK_SIZE) != BLOCK_SIZE)
            perror("read");
        else if (memcmp(block[index], buffer, BLOCK_SIZE))
            fprintf(stderr, "memcmp: test failed\n");
        else
            continue;

        printf("failed after %i successful cycles.\n", count);
        break;

    }

}

Perhatikan bahwa untuk O_DIRECT, buffer harus disejajarkan. Batas-batas 512 byte umumnya cukup. Anda dapat dikompilasi dengan:

g++ -O0 test.cpp -o test

Tambahkan -D_POSIX_C_SOURCE=200112Ljika perlu.

Kemudian, setelah mengisi perangkat sepenuhnya seperti di atas, biarkan beroperasi semalam:

./test /dev/sdb

512 byte, selaras menulis baik-baik saja, yang akan memberi Anda satu halaman penuh dihapus dan ditulis ulang. Anda dapat mempercepat tes secara signifikan dengan menggunakan ukuran blok yang lebih besar, tetapi kemudian menjadi sulit untuk sampai pada hasil yang nyata.

Saat ini saya sedang menguji pada thumb drive 4GB PNY yang agak usang yang saya temukan di trotoar kemarin (tampaknya yang tersisa dari http://www3.pny.com/4GB-Micro-Sleek-Attach-- -Purple-P2990C418.aspx ).

Program di atas pada dasarnya adalah versi terbatas badblocksdan Anda tidak akan melihat kegagalan sampai semua ruang yang dicadangkan habis. Oleh karena itu, harapan (dengan 1 halaman ditulis per iterasi) adalah bahwa prosedur di atas, rata-rata, harus gagal dalam iterasi reserved_page_count * iterations write_cycle_limit (sekali lagi, leveling keausan adalah variabel utama). Sayang sekali thumb drive dan kartu SD biasanya tidak mendukung SMART, yang memiliki kemampuan untuk melaporkan ukuran ruang yang dipesan.

Omong-omong, fsyncvs fdatasynctidak membuat perbedaan untuk perangkat blok tulis yang Anda lakukan, untuk keperluan tes ini. open()Mode Anda penting.

Jika Anda ingin tahu tentang rincian teknis; di sini adalah segala sesuatu yang Anda mungkin ingin tahu (ditambah lagi) tentang cara kerja kartu SD: https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

Sunting: Bytes vs Pages: Dalam konteks jenis tes ini, penting untuk memikirkan hal-hal dalam hal halaman, bukan byte. Sangatlah menyesatkan untuk melakukan yang sebaliknya. Misalnya, pada SanDisk 8GB SD, ukuran halaman sesuai dengan pengontrol (dapat diakses melalui /sys/classes/mmc_host/mmc?/mmc?:????/preferred_erase_size) adalah 4MB penuh. Menulis 16MB (selaras dengan batas 4MB), lalu, hapus / tulis 4 halaman. Namun, menulis empat byte tunggal masing-masing pada offset 4MB dari satu sama lain juga menghapus / menulis 4 halaman.

Itu tidak akurat, maka untuk mengatakan "Saya diuji dengan menulis 16MB", karena itu adalah jumlah yang sama seperti memakai "Saya diuji dengan menulis 4 byte". Lebih tepatnya, "Saya diuji dengan 4 halaman menulis".

Jason C
sumber
Saya menambahkan komentar tentang byte vs halaman.
Jason C
PNY tampaknya tidak bisa dihancurkan. Namun, setelah ~ 8.1mil iterasi (lebih dari 8 jam) menggunakan MicroSD 8GB SanDisk yang baru, diikuti oleh siklus daya, laju penulisan maksimum (awalnya 4MB / detik) turun secara permanen menjadi ~ 410kB / detik, dan ddgagal setelah penulisan 250MB . Kerusakan tidak muncul sampai setelah siklus daya. Thumb drive PNY tetap tidak terpengaruh setelah ~ 30 juta iterasi. Saya memodifikasi program di atas (tidak tercermin dalam kode di atas, namun) untuk menulis ke lokasi acak 16kB setiap kali alih-alih sama, tetapi saya melakukannya setelah ~ 4mil iters di SD. Akan menguji ulang dengan kartu baru.
Jason C
Upaya ketiga ddpada kartu itu berhasil melewati tanda 250MB, dan kinerja penulisan meningkat lagi menjadi 4MB / detik penuh ke area setelah titik itu. Saya berharap kinerja tidak dapat diprediksi, karena blok terus diacak. Saya tidak akan mengatakan kartunya hancur, tetapi sudah pasti tidak 100%.
Jason C
5

Hanya menambahkan beberapa poin pada jawaban slm - perhatikan ini lebih sesuai untuk SSD daripada kartu SD "bodoh", karena SSD memainkan banyak trik kotor dengan data Anda (mis. De-duplikasi):

  • Anda menulis 64KB ke awal perangkat - ini sendiri memiliki dua masalah:

    1. sel flash biasanya menghapus blok ukuran dari 16KB (lebih mungkin dalam kisaran 128-512KB, meskipun). Yang berarti bahwa itu membutuhkan cache setidaknya ukuran ini. Karenanya menulis 64KB tampaknya tidak cukup bagi saya.

    2. untuk solusi low-end (baca "non-perusahaan") (dan saya berharap ini lebih untuk kartu SD / CF daripada untuk SSD) produsen dapat memilih untuk membuat permulaan perangkat lebih tangguh untuk dipakai daripada yang lain karena struktur penting - tabel partisi dan FAT pada partisi tunggal pada perangkat (sebagian besar kartu memori menggunakan pengaturan ini) - terletak di sana. Jadi pengujian awal kartu mungkin bias.

  • fdatasync() tidak benar-benar menjamin bahwa data dapat ditulis ke media fisik (meskipun mungkin melakukan yang terbaik di bawah kendali OS) - lihat halaman manual:

    Panggilan memblokir hingga perangkat melaporkan bahwa transfer telah selesai

    Saya tidak akan terlalu terkejut jika ternyata ada kapasitor kecil, yang mampu memberikan energi untuk menulis data cache ke memori flash jika kehilangan daya eksternal.

    Dalam kasus apa pun, dengan asumsi ada cache pada kartu (lihat jawaban saya untuk pertanyaan Anda pada SU ), menulis 64KB dan menyinkronkan (dengan fdatasync()) tampaknya tidak cukup meyakinkan untuk tujuan ini. Bahkan tanpa "cadangan daya" firmware mungkin masih memainkannya tidak aman dan menyimpan data tidak tertulis untuk sedikit lebih lama dari yang diharapkan (karena dalam kasus penggunaan umum itu seharusnya tidak membuat masalah).

  • Anda mungkin ingin membaca data sebelum menulis blok baru dan membandingkannya, hanya untuk memastikan itu benar-benar berfungsi (dan gunakan buffer yang dibersihkan untuk membaca, jika Anda cukup paranoid).

peterph
sumber
+1 Untuk menyoroti kemungkinan cache dan pentingnya blok hapus di ini. Tapi ...
goldilocks
"menguji permulaan kartu mungkin bias" Ingat, karena leveling keausan (yang harus dimainkan - saya telah melampaui jumlah siklus tulis yang masuk akal pada saat ini) - ini sepertinya hanya blok pertama. Yaitu, ini adalah blok virtual pertama, bukan blok fisik pertama .
goldilocks
"fdatasync () tidak benar-benar menjamin bahwa data dapat ditulis ke media fisik" IMO, perangkat yang melaporkan bahwa transfer telah selesai mengindikasikan bahwa penulisan harus terjadi jika perangkat juga lulus tes baca-tulis (itu belum gagal satu). Caching dapat memperumit ini, tetapi jika kita menggunakan bongkahan yang cukup besar untuk menyiasatinya, tidak mungkin ada "tulisan salah" ketika perangkat melaporkan keberhasilan. Akan sia-sia jika melakukan itu.
goldilocks
1
@goldilocks no, membaca kembali data dari perangkat tidak menjamin apa pun. Adalah masuk akal untuk mengharapkan data berada di media fisik, dan mungkin dalam kebanyakan kasus, tapi itu tidak dijamin - setidaknya kecuali Anda melampaui ukuran cache.
peterph
1
@goldilocks peterph memunculkan hal lain yang ingin saya tunjukkan; yang readdi tes Anda tidak perlu, itu tidak menambah informasi dan tidak relevan untuk tes siklus tulis. Untuk pengujian yang sebenarnya, Anda akan ingin membaca kembali blok yang baru saja Anda tulis dan memvalidasinya, kecuali Anda tahu pasti bahwa controller dapat mendeteksi dan melaporkan kembali semua mode kegagalan.
Jason C
2

Jawaban Peterph memang membuat saya mempertimbangkan masalah kemungkinan caching lebih lanjut. Setelah menggali sekitar, saya masih tidak bisa mengatakan dengan pasti apakah ada, beberapa, atau semua kartu SD melakukan ini, tetapi saya pikir itu mungkin.

Namun, saya tidak percaya bahwa caching akan melibatkan data yang lebih besar daripada blok hapus. Untuk benar-benar yakin, saya mengulangi tes menggunakan potongan 16 MB bukannya 64 kB. Ini adalah 1/250 volume total kartu 4 GB. Butuh ~ 8 jam untuk melakukan ini 10.000 kali. Jika leveling aus melakukan yang terbaik untuk menyebarkan beban, ini berarti setiap blok fisik akan digunakan 40 kali.

Itu tidak banyak, tetapi poin asli dari tes ini adalah untuk menunjukkan kemanjuran pemakaian level dengan menunjukkan bahwa saya tidak dapat dengan mudah merusak kartu melalui penulisan berulang jumlah data sederhana ke lokasi yang sama (jelas). IMO tes 64 kB sebelumnya mungkin nyata - tetapi yang 16 MB harus. Sistem telah mem-flush data ke perangkat keras dan perangkat keras telah melaporkan penulisan tanpa kesalahan. Jika ini adalah tipuan, kartu tidak akan baik untuk apa pun, dan tidak bisa melakukan caching 16 MB di mana pun kecuali di penyimpanan utama, yang merupakan tujuan tes ini.

Mudah-mudahan, 10.000 menulis masing-masing 16 MB sudah cukup untuk menunjukkan bahwa bahkan pada kartu merek nama ujung bawah (nilai: $ 5 CDN), menjalankan sistem file rw root 24/7 yang menulis jumlah data sederhana setiap hari tidak akan memakai kartu dalam periode waktu yang wajar. 10.000 hari adalah 27 tahun ... dan kartunya masih baik-baik saja ...

Jika saya dibayar untuk mengembangkan sistem yang bekerja lebih berat dari itu, saya ingin melakukan setidaknya beberapa tes untuk menentukan berapa lama kartu dapat bertahan. Perkiraan saya adalah bahwa dengan yang seperti ini, yang memiliki kecepatan tulis rendah, bisa butuh waktu berminggu-minggu, berbulan-bulan, atau bertahun-tahun untuk menulis terus-menerus dengan kecepatan maksimal (faktanya tidak ada banyak sekali tes komparatif online semacam ini yang berbicara kepada fakta bahwa itu akan menjadi urusan yang sangat berkepanjangan).

Berkenaan dengan mengkonfirmasi kartu masih baik-baik saja, saya tidak lagi berpikir menggunakan badblockskonfigurasi default itu sesuai. Sebaliknya, saya melakukannya dengan cara ini:

badblocks -v -w -b 524288 -c 8

Yang berarti menguji menggunakan blok 512 kB yang diulang 8 kali (= 4 MB). Karena ini adalah tes rw destruktif, mungkin akan lebih baik seperti yang saya lakukan di rumah untuk menekankan perangkat jika digunakan dalam loop terus menerus.

Saya juga membuat sistem file di atasnya, disalin dalam file 2 GB, difffile melawan yang asli dan kemudian - karena file tersebut adalah iso - mount itu sebagai gambar dan menelusuri filesystem di dalamnya.

Kartu masih baik-baik saja. Yang mungkin diharapkan, setelah semua ...

;);)

goldilocks
sumber
Saya pikir matematika Anda tidak benar. Kartu Kelas 2 telah mempertahankan throughput 2MB / s, itu berarti Anda akan menempatkan 20TB dalam waktu sekitar 4 bulan. Tentu, Anda menyebutkan bahwa Anda memiliki kartu non-kelas, tetapi Anda tampaknya benar-benar pesanan yang sangat besar (seperti yang ditunjukkan terdon di unix.stackexchange.com/questions/84902/… ). Kalau tidak, saya sepenuhnya setuju dengan slm.
peterph
Saya percaya kita bisa cukup yakin bahwa caching memiliki minimal, jika ada, dampak setelah sinkronisasi untuk media yang dirancang untuk sering dihapus dan juga bus bertenaga. Pertimbangkan bahwa perangkat ini dirancang untuk "dikeluarkan" dengan andal dan dihapus, dan bahwa sinkronisasi adalah hal terakhir mutlak yang dapat dilakukan OS terhadap perangkat selain memotong kekuatannya (jika mungkin). Masuk akal untuk menganggap bahwa mis. Drive USB atau kartu SD ditulis secara fisik setelah sinkronisasi, atau paling tidak berkomitmen untuk membuat penulisan dalam waktu yang sangat singkat setelah daya mati.
Jason C
Selain itu, btw, badblockstidak akan menampilkan halaman yang gagal pada memori flash. Ini bukan alat yang tepat untuk pekerjaan ini dan Anda tidak dapat menggunakannya untuk menemukan halaman yang gagal pada flash. Ketika controller mendeteksi kegagalan, ia akan secara internal menandai halaman sebagai buruk dan memetakannya kembali ke halaman di ruang yang disediakan. Semua ini terjadi di belakang pengontrol dan tidak terlihat oleh Anda, bahkan di dump perangkat mentah, sama sekali . Anda bisa mendapatkan beberapa info dari controller jika SMART didukung. Urutan fisik data pada perangkat tidak sesuai dengan urutan byte yang Anda lihat saat melakukan IO pada perangkat.
Jason C
Satu lagi komentar, lebih dari FYI: pada SanDisk 8GB MicroSD, tingkat konsumen, unit alokasi (yaitu ukuran halaman) adalah 4MB seperti yang dilaporkan oleh controller; artinya 16MB pada kartu itu adalah 4 halaman (5 jika tidak sejajar). Anda dapat mempercepat tes itu dengan menulis 512 byte pada 4MB offset dari satu sama lain daripada memberi makan 16MB ke kartu. Anda tidak membuat perbedaan antara byte dan jumlah halaman tetapi Anda harus - dalam contoh Anda, jika berada pada kartu SanDisk 8GB, "16MB" menggunakan kartu yang sama dengan "2KB". Sangat menyesatkan untuk merujuk pada byte alih-alih halaman.
Jason C
Setelah ~ 8.1mil iterasi (lebih dari 8 jam) dalam program pengujian yang saya tulis di atas, diikuti oleh siklus daya, pada MicroSD SanDisk 8GB yang baru, kecepatan menulis dibatasi secara permanen hingga sekitar 450kB / detik dan ddgagal menulis melampaui 250MB menandai. Pada ddupaya ketiga berhasil melewati 250MB dan setelah itu, kinerja menulis meningkat lagi di daerah tersebut Saya tidak akan mengatakan kartunya hancur tetapi sudah pasti tidak 100%.
Jason C