;) ;)

Question 1

SD 카드 스트레스 테스트에는 일반적으로 두 가지 문제가 있다고 생각합니다.

웨어 레벨링은 다음 쓰기가 실제로 SD의 동일한 물리적 위치를 사용한다는 것을 보장하지 않습니다. 대부분의 기존 SD 시스템은 우리가 알고 있는 블록을 적극적으로 획득하고 각 위치가 겪는 인지된 "마모"를 기반으로 해당 블록을 지원하는 물리적 위치를 이동한다는 점을 명심하십시오.
서로 다른 기술(MLC vs. SLC) 제가 보는 또 다른 문제는 기술의 차이입니다. SLC 유형 SSD는 MLC 유형보다 훨씬 오래 지속될 것으로 예상됩니다. 또한 MLC의 허용 오차는 훨씬 엄격한 반면 SLC에서는 이러한 문제를 처리할 필요가 없거나 적어도 그러한 오류에 대해 훨씬 더 관대합니다.
- MLC - 다단계 장치
- SLC - 단일 레벨 장치

MLC의 문제점은 주어진 셀이 여러 값을 저장할 수 있고 비트가 본질적으로 물리적인 +5V나 0V가 아닌 전압을 사용하여 쌓이기 때문에 동일한 양의 경우 SLC보다 잠재적인 실패율이 훨씬 더 높아질 수 있다는 것입니다.

기대 수명

하드웨어 지속 시간과 관련된 몇 가지 문제를 논의하는 이 링크를 찾았습니다. 제목은 다음과 같습니다.SSD 이해 – SLC와 MLC.

SLC

최선의 추정에 따르면 SLC SSD의 평균 수명은 대부분의 경우 49~149년입니다. Memoright 테스트를 통해 128Gb SSD의 쓰기 수명이 200년 이상이며 하루 평균 100Gb를 쓸 수 있음을 확인할 수 있습니다.

다층 커패시터

이것이 MLC 디자인이 부족한 부분입니다. 아직 아무것도 출판되지 않았습니다. MLC가 어떤 종류의 기대 수명을 보장하는지 실제로 연구한 사람은 아무도 없으며 단지 그 수명이 상당히 낮아질 것이라는 것뿐입니다. 몇 가지 다른 의견을 받았는데 SLC 디자인의 수명은 평균 10대 1입니다. 보수적으로 추측하면 각 제조업체의 컨트롤러 내 "웨어 레벨링 알고리즘"의 발전에 따라 대부분의 수명 추정치는 7~10년 사이가 될 것입니다.

비교하다

쓰기 주기별로 비교하자면, SLC의 수명은 100,000회의 전체 쓰기 주기인 반면, MLC의 수명은 10,000회의 쓰기 주기입니다. 이는 사용된 "웨어 레벨링"의 설계에 따라 크게 증가할 수 있습니다.

Answer

SD 카드 스트레스 테스트에는 일반적으로 두 가지 문제가 있다고 생각합니다.

웨어 레벨링은 다음 쓰기가 실제로 SD의 동일한 물리적 위치를 사용한다는 것을 보장하지 않습니다. 대부분의 기존 SD 시스템은 우리가 알고 있는 블록을 적극적으로 획득하고 각 위치가 겪는 인지된 "마모"를 기반으로 해당 블록을 지원하는 물리적 위치를 이동한다는 점을 명심하십시오.
서로 다른 기술(MLC vs. SLC) 제가 보는 또 다른 문제는 기술의 차이입니다. SLC 유형 SSD는 MLC 유형보다 훨씬 오래 지속될 것으로 예상됩니다. 또한 MLC의 허용 오차는 훨씬 엄격한 반면 SLC에서는 이러한 문제를 처리할 필요가 없거나 적어도 그러한 오류에 대해 훨씬 더 관대합니다.
- MLC - 다단계 장치
- SLC - 단일 레벨 장치

MLC의 문제점은 주어진 셀이 여러 값을 저장할 수 있고 비트가 본질적으로 물리적인 +5V나 0V가 아닌 전압을 사용하여 쌓이기 때문에 동일한 양의 경우 SLC보다 잠재적인 실패율이 훨씬 더 높아질 수 있다는 것입니다.

기대 수명

하드웨어 지속 시간과 관련된 몇 가지 문제를 논의하는 이 링크를 찾았습니다. 제목은 다음과 같습니다.SSD 이해 – SLC와 MLC.

SLC

최선의 추정에 따르면 SLC SSD의 평균 수명은 대부분의 경우 49~149년입니다. Memoright 테스트를 통해 128Gb SSD의 쓰기 수명이 200년 이상이며 하루 평균 100Gb를 쓸 수 있음을 확인할 수 있습니다.

다층 커패시터

이것이 MLC 디자인이 부족한 부분입니다. 아직 아무것도 출판되지 않았습니다. MLC가 어떤 종류의 기대 수명을 보장하는지 실제로 연구한 사람은 아무도 없으며 단지 그 수명이 상당히 낮아질 것이라는 것뿐입니다. 몇 가지 다른 의견을 받았는데 SLC 디자인의 수명은 평균 10대 1입니다. 보수적으로 추측하면 각 제조업체의 컨트롤러 내 "웨어 레벨링 알고리즘"의 발전에 따라 대부분의 수명 추정치는 7~10년 사이가 될 것입니다.

비교하다

쓰기 주기별로 비교하자면, SLC의 수명은 100,000회의 전체 쓰기 주기인 반면, MLC의 수명은 10,000회의 쓰기 주기입니다. 이는 사용된 "웨어 레벨링"의 설계에 따라 크게 증가할 수 있습니다.

Question 2

테스트에는 많은 문제가 있습니다. 일부는 모호하고 일부는 그렇지 않습니다. 그것은 또한 당신의 목표에 달려 있습니다. 두 가지 미묘하고 모호한 질문은 다음과 같습니다.

쓰고 있는 동일한 영역에서 읽지 않고, 읽기 테스트가 작동하고 아무 작업도 수행하지 않습니다(컨트롤러가 방해 수정을 읽지 않는 한, 이 경우 페이지가 다른 곳으로 이동되었지만 여전히 오류가 발생할 수 있음). 발생) 테스트에 영향을 미치지 않습니다).
컨트롤러가 불량 블록에 대한 읽기/쓰기를 감지하고 보고한다고 가정합니다(대개는 보장되지 않음). 데이터를 쓰고 다시 읽은 다음 보장된 검사를 비교해야 합니다.

그러나 이는 현학적이라고 할 수 있다. 더 심각하게:

이를 사용하여 플래시에 결함이 있는 페이지를 표시할 수 없습니다 badblocks. 모든 결함 감지 및 후속 페이지 매핑은 운영 체제에 투명하게 컨트롤러에 의해 수행됩니다. 드라이브가 이를 지원하는 경우 SMART에서 일부 정보를 얻을 수 있습니다(지원하는 SD 카드가 없는 것으로 알고 있으며 이를 지원하는 고급 썸 드라이브가 있을 수도 있습니다).
테스트에서 이전 TRIM 명령, 테스트 중 드라이브의 사용 가능/사용 상태 및 예약된 공간을 고려하지 않기 때문에 웨어 레벨링이 복잡합니다.

웨어 레벨링:가장 큰 문제는 마모 레벨링이 테스트의 주요 변수라는 것입니다. 이는 일반적으로 컨트롤러에서 발생하며 어떤 경우에도 직접 장치 조회 + 읽기/쓰기가 투명합니다. 귀하의 예에서는 실제로 웨어 레벨링 상태를 알지 못합니다(특히 최근에 무료 블록에 TRIM 명령이 실행되었습니까?)...

장치의 동적 마모 평준화(거의 모든 소비자급 저장 장치에 있음)의 경우 어떤 상태에도 있을 수 있습니다. 극단적인 경우에는 사용 가능으로 표시된 페이지가 없으므로 컨트롤러가 작업해야 하는 유일한 페이지는 다음과 같습니다. 해당 공간에 있는 항목을 예약하세요(있는 경우). 있는 경우 참고하시기 바랍니다.예장치에 예약된 공간이 있습니다.~ 할 것이다보장된 페이지 쓰기가 실패하기 시작하기 전에 완전한 실패가 발생해야 합니다(남은 여유 공간으로 표시된 다른 페이지가 없다고 가정). 다른 극단적인 경우에는 모든 페이지가 무료로 표시되며, 이 경우 이론적으로모든쓰기 오류가 표시되기 전에 장치의 페이지가 실패합니다.

정적 마모 평준화(SSD에는 있는 경향이 있고 SD 카드에는 없는 경향이 있으며 썸드라이브에는 다양함)의 경우 장치의 모든 페이지를 반복적으로 쓰는 것 외에는 실제로 방법이 없습니다.

...즉, 알 수 없고 확실히 제어할 수 없는 웨어 레벨링 세부 사항이 있습니다. 특히 동적 웨어 레벨링을 사용할지 여부, 정적 웨어 레벨링을 사용할지 여부, 장치에 예약된 공간의 양 등이 있습니다. 마모 평준화용(드라이버(또는 일부 경우 M-Systems의 이전 DiskOnChip과 같은 드라이버)에 표시되지 않도록 제어).

SLC/MLC:SLC와 MLC의 경우 이는 예상할 수 있는 한계에 매우 직접적인 영향을 미치지만 일반적인 마모 평준화 절차와 테스트 절차는 둘 다 동일합니다. 페이지당 100,000회 이상의 주기 제한을 주장하는 모든 플래시 드라이브는 SLC일 가능성이 높지만(간단한 절충안은 SLC = 내구성, MLC = 밀도), 많은 공급업체에서는 자사 장치가 SLC인지 MLC인지 공개하지 않으므로 가격이 더 저렴합니다. 소비자 제품.

은닉처:캐싱에 관해서는 약간 확실하지 않습니다. OS 수준에서 일반적인 상황에서는 물론 fsync/fdatasync가 데이터가 실제로 기록된다는 것을 보장하지 않습니다. 그러나 이 경우 이동식 드라이브는 일반적으로 일반적인 사용 패턴에 맞게 설계되었기 때문에 그렇다고 가정하는 것이 안전하다고 생각합니다(또는 적어도 컨트롤러가 그렇게 하기로 약속했습니다. 즉, 쓰기가 캐시에 의해 삼켜지지 않을 것입니다). "제거"”(제거 > 동기화)를 수행한 다음 제거합니다(전원 끄기). 확실히 알 수는 없지만, 경험에 근거한 추측에 따르면 특히 쓰기->동기화->읽기에서 동기화 보장 쓰기가 확실히 발생한다고 가정하는 것이 안전합니다(이후에 드라이브를 꺼내지 않으면 드라이브를 신뢰할 수 없게 됩니다). 팝업에서 실행할 수 있는 "sync" 이외의 명령은 없습니다.

컨트롤러에서는 무엇이든 가능하지만 위의 가정에는 컨트롤러가 최소한 동기화 후 데이터 손실 위험을 초래할 만큼 "복잡한" 가정을 하지 않는다는 가정도 포함됩니다. 동일한 데이터를 덮어쓰는 경우(제한된 범위 내에서) 컨트롤러는 쓰기를 버퍼링하고 그룹화하거나 데이터를 쓰지 않을 수 있습니다. 아래 프로그램에서는 두 개의 서로 다른 데이터 청크를 번갈아 가며 다시 읽기 전에 동기화를 수행합니다. 특히 합리적인 컨트롤러 캐싱 메커니즘을 중단합니다. 물론 아직 보장할 수 없고 알 방법도 없지만 이러한 장치의 일반적인 사용과 합리적/공통 캐싱 메커니즘을 기반으로 합리적인 가정을 할 수 있습니다.

시험:

불행하게도 사실은 당신이 그렇지 않다면알다장치가 공간을 예약하지 않고 정적 평준화를 수행하지 않기 때문에 특정 페이지에 대한 루프 제한을 명시적으로 테스트하는 것은 불가능합니다. 그러나 얻을 수 있는 가장 가까운 방법은 다음과 같습니다(정적 마모 레벨링이 없다고 가정).

이것첫 번째당신이 해야 할 일은 카드 전체를 데이터로 채우는 것뿐입니다.이는 중요하며 원래 테스트에서 남겨진 주요 변수입니다.이렇게 하면 예약된 공간(액세스할 수 없음) 외에도 사용된 블록을 최대한 많이 표시합니다. 단일 파티션을 사용하면 장치의 특정 영역에만 영향을 주기 때문에 전체 장치를 사용하고 있습니다(이 경우 장치의 모든 데이터가 삭제됨).

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

진행률 표시줄 유형인 경우:

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

편집: 4MB 지우기 블록이 있는 카드의 경우 더 빠른 쓰기를 위해 다음을 시도하십시오.

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

O_DIRECT다음으로, 그림에서 가능한 한 많은 운영 체제 버퍼와 캐시를 활용하고 ( O_SYNC아마도 편집증적이고 중복된 사용 fsync()) 제거하고 이론적으로는 컨트롤러에 직접 쓰고 다음을 기다리는 아래와 같은 루핑 테스트 프로그램을 작성할 수 있습니다. 작업이 완료되었음을 보고합니다.

#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;

    }

}

의 경우 O_DIRECT버퍼가 올바르게 정렬되어야 합니다. 일반적으로 512바이트 경계면 충분합니다. 다음 명령을 사용하여 컴파일할 수 있습니다.

g++ -O0 test.cpp -o test

필요한 경우 추가하십시오 -D_POSIX_C_SOURCE=200112L.

그런 다음 위에서 설명한 대로 장치가 완전히 채워지면 밤새 실행되도록 둡니다.

./test /dev/sdb

512바이트의 정렬된 쓰기가 가능하므로 전체 페이지를 지우고 다시 쓸 수 있습니다. 더 큰 블록 크기를 사용하면 테스트 속도를 크게 높일 수 있지만 구체적인 결과를 얻는 것은 복잡해집니다.

나는 현재 어제 보도에서 발견한 다소 낡아 보이는 4GB PNY 썸 드라이브를 테스트하고 있습니다.http://www3.pny.com/4GB-Micro-Sleek-Attach---Purple-P2990C418.aspx).

위 프로그램은 기본적으로 제한된 버전이므로 badblocks예약된 공간이 모두 소진될 때까지 오류가 표시되지 않습니다. 따라서 위 프로세스는 평균적으로 실패할 것으로 예상됩니다(반복당 1페이지 쓰기).예약된 페이지 수* 쓰기 주기 제한반복(다시 말하지만 마모 레벨링이 주요 변수입니다). 불행하게도 썸 드라이브와 SD 카드는 일반적으로 예약된 공간의 양을 보고하는 SMART를 지원하지 않습니다.

그런데 이 테스트의 목적에 따라 fsyncvs는 수행 중인 블록 장치 쓰기에 영향을 주지 않습니다. fdatasync당신의 open()패턴이 중요합니다.

기술적인 세부 사항이 궁금하신 경우 SD 카드의 내부 작동에 대해 알고 싶은 모든 내용은 다음과 같습니다.https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

편집하다:바이트 및 페이지:이러한 유형의 테스트에서는 바이트보다는 페이지 측면에서 사물을 생각하는 것이 중요합니다. 반대로 하면 매우 오해를 불러일으킬 수 있습니다. 예를 들어 SanDisk 8GB SD에서 /sys/classes/mmc_host/mmc?/mmc?:????/preferred_erase_size컨트롤러에 따른 페이지 크기(접근 가능)는 전체 4MB입니다. 16MB를 쓰고(4MB 경계에 맞춰 정렬됨) 4페이지를 지우고 씁니다. 그러나 서로 4MB 오프셋으로 4개의 단일 바이트를 쓰면 4페이지도 삭제/쓰기됩니다.

따라서 "16MB 쓰기로 테스트했습니다"라고 말하는 것은 "4바이트 쓰기로 테스트했습니다"와 같은 마모량이므로 정확하지 않습니다. 좀 더 정확히 말하자면, "4페이지 작성을 테스트했습니다"입니다.

Answer

테스트에는 많은 문제가 있습니다. 일부는 모호하고 일부는 그렇지 않습니다. 그것은 또한 당신의 목표에 달려 있습니다. 두 가지 미묘하고 모호한 질문은 다음과 같습니다.

쓰고 있는 동일한 영역에서 읽지 않고, 읽기 테스트가 작동하고 아무 작업도 수행하지 않습니다(컨트롤러가 방해 수정을 읽지 않는 한, 이 경우 페이지가 다른 곳으로 이동되었지만 여전히 오류가 발생할 수 있음). 발생) 테스트에 영향을 미치지 않습니다).
컨트롤러가 불량 블록에 대한 읽기/쓰기를 감지하고 보고한다고 가정합니다(대개는 보장되지 않음). 데이터를 쓰고 다시 읽은 다음 보장된 검사를 비교해야 합니다.

그러나 이는 현학적이라고 할 수 있다. 더 심각하게:

이를 사용하여 플래시에 결함이 있는 페이지를 표시할 수 없습니다 badblocks. 모든 결함 감지 및 후속 페이지 매핑은 운영 체제에 투명하게 컨트롤러에 의해 수행됩니다. 드라이브가 이를 지원하는 경우 SMART에서 일부 정보를 얻을 수 있습니다(지원하는 SD 카드가 없는 것으로 알고 있으며 이를 지원하는 고급 썸 드라이브가 있을 수도 있습니다).
테스트에서 이전 TRIM 명령, 테스트 중 드라이브의 사용 가능/사용 상태 및 예약된 공간을 고려하지 않기 때문에 웨어 레벨링이 복잡합니다.

웨어 레벨링:가장 큰 문제는 마모 레벨링이 테스트의 주요 변수라는 것입니다. 이는 일반적으로 컨트롤러에서 발생하며 어떤 경우에도 직접 장치 조회 + 읽기/쓰기가 투명합니다. 귀하의 예에서는 실제로 웨어 레벨링 상태를 알지 못합니다(특히 최근에 무료 블록에 TRIM 명령이 실행되었습니까?)...

장치의 동적 마모 평준화(거의 모든 소비자급 저장 장치에 있음)의 경우 어떤 상태에도 있을 수 있습니다. 극단적인 경우에는 사용 가능으로 표시된 페이지가 없으므로 컨트롤러가 작업해야 하는 유일한 페이지는 다음과 같습니다. 해당 공간에 있는 항목을 예약하세요(있는 경우). 있는 경우 참고하시기 바랍니다.예장치에 예약된 공간이 있습니다.~ 할 것이다보장된 페이지 쓰기가 실패하기 시작하기 전에 완전한 실패가 발생해야 합니다(남은 여유 공간으로 표시된 다른 페이지가 없다고 가정). 다른 극단적인 경우에는 모든 페이지가 무료로 표시되며, 이 경우 이론적으로모든쓰기 오류가 표시되기 전에 장치의 페이지가 실패합니다.

정적 마모 평준화(SSD에는 있는 경향이 있고 SD 카드에는 없는 경향이 있으며 썸드라이브에는 다양함)의 경우 장치의 모든 페이지를 반복적으로 쓰는 것 외에는 실제로 방법이 없습니다.

...즉, 알 수 없고 확실히 제어할 수 없는 웨어 레벨링 세부 사항이 있습니다. 특히 동적 웨어 레벨링을 사용할지 여부, 정적 웨어 레벨링을 사용할지 여부, 장치에 예약된 공간의 양 등이 있습니다. 마모 평준화용(드라이버(또는 일부 경우 M-Systems의 이전 DiskOnChip과 같은 드라이버)에 표시되지 않도록 제어).

SLC/MLC:SLC와 MLC의 경우 이는 예상할 수 있는 한계에 매우 직접적인 영향을 미치지만 일반적인 마모 평준화 절차와 테스트 절차는 둘 다 동일합니다. 페이지당 100,000회 이상의 주기 제한을 주장하는 모든 플래시 드라이브는 SLC일 가능성이 높지만(간단한 절충안은 SLC = 내구성, MLC = 밀도), 많은 공급업체에서는 자사 장치가 SLC인지 MLC인지 공개하지 않으므로 가격이 더 저렴합니다. 소비자 제품.

은닉처:캐싱에 관해서는 약간 확실하지 않습니다. OS 수준에서 일반적인 상황에서는 물론 fsync/fdatasync가 데이터가 실제로 기록된다는 것을 보장하지 않습니다. 그러나 이 경우 이동식 드라이브는 일반적으로 일반적인 사용 패턴에 맞게 설계되었기 때문에 그렇다고 가정하는 것이 안전하다고 생각합니다(또는 적어도 컨트롤러가 그렇게 하기로 약속했습니다. 즉, 쓰기가 캐시에 의해 삼켜지지 않을 것입니다). "제거"”(제거 > 동기화)를 수행한 다음 제거합니다(전원 끄기). 확실히 알 수는 없지만, 경험에 근거한 추측에 따르면 특히 쓰기->동기화->읽기에서 동기화 보장 쓰기가 확실히 발생한다고 가정하는 것이 안전합니다(이후에 드라이브를 꺼내지 않으면 드라이브를 신뢰할 수 없게 됩니다). 팝업에서 실행할 수 있는 "sync" 이외의 명령은 없습니다.

컨트롤러에서는 무엇이든 가능하지만 위의 가정에는 컨트롤러가 최소한 동기화 후 데이터 손실 위험을 초래할 만큼 "복잡한" 가정을 하지 않는다는 가정도 포함됩니다. 동일한 데이터를 덮어쓰는 경우(제한된 범위 내에서) 컨트롤러는 쓰기를 버퍼링하고 그룹화하거나 데이터를 쓰지 않을 수 있습니다. 아래 프로그램에서는 두 개의 서로 다른 데이터 청크를 번갈아 가며 다시 읽기 전에 동기화를 수행합니다. 특히 합리적인 컨트롤러 캐싱 메커니즘을 중단합니다. 물론 아직 보장할 수 없고 알 방법도 없지만 이러한 장치의 일반적인 사용과 합리적/공통 캐싱 메커니즘을 기반으로 합리적인 가정을 할 수 있습니다.

시험:

불행하게도 사실은 당신이 그렇지 않다면알다장치가 공간을 예약하지 않고 정적 평준화를 수행하지 않기 때문에 특정 페이지에 대한 루프 제한을 명시적으로 테스트하는 것은 불가능합니다. 그러나 얻을 수 있는 가장 가까운 방법은 다음과 같습니다(정적 마모 레벨링이 없다고 가정).

이것첫 번째당신이 해야 할 일은 카드 전체를 데이터로 채우는 것뿐입니다.이는 중요하며 원래 테스트에서 남겨진 주요 변수입니다.이렇게 하면 예약된 공간(액세스할 수 없음) 외에도 사용된 블록을 최대한 많이 표시합니다. 단일 파티션을 사용하면 장치의 특정 영역에만 영향을 주기 때문에 전체 장치를 사용하고 있습니다(이 경우 장치의 모든 데이터가 삭제됨).

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

진행률 표시줄 유형인 경우:

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

편집: 4MB 지우기 블록이 있는 카드의 경우 더 빠른 쓰기를 위해 다음을 시도하십시오.

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

O_DIRECT다음으로, 그림에서 가능한 한 많은 운영 체제 버퍼와 캐시를 활용하고 ( O_SYNC아마도 편집증적이고 중복된 사용 fsync()) 제거하고 이론적으로는 컨트롤러에 직접 쓰고 다음을 기다리는 아래와 같은 루핑 테스트 프로그램을 작성할 수 있습니다. 작업이 완료되었음을 보고합니다.

#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;

    }

}

의 경우 O_DIRECT버퍼가 올바르게 정렬되어야 합니다. 일반적으로 512바이트 경계면 충분합니다. 다음 명령을 사용하여 컴파일할 수 있습니다.

g++ -O0 test.cpp -o test

필요한 경우 추가하십시오 -D_POSIX_C_SOURCE=200112L.

그런 다음 위에서 설명한 대로 장치가 완전히 채워지면 밤새 실행되도록 둡니다.

./test /dev/sdb

512바이트의 정렬된 쓰기가 가능하므로 전체 페이지를 지우고 다시 쓸 수 있습니다. 더 큰 블록 크기를 사용하면 테스트 속도를 크게 높일 수 있지만 구체적인 결과를 얻는 것은 복잡해집니다.

나는 현재 어제 보도에서 발견한 다소 낡아 보이는 4GB PNY 썸 드라이브를 테스트하고 있습니다.http://www3.pny.com/4GB-Micro-Sleek-Attach---Purple-P2990C418.aspx).

위 프로그램은 기본적으로 제한된 버전이므로 badblocks예약된 공간이 모두 소진될 때까지 오류가 표시되지 않습니다. 따라서 위 프로세스는 평균적으로 실패할 것으로 예상됩니다(반복당 1페이지 쓰기).예약된 페이지 수* 쓰기 주기 제한반복(다시 말하지만 마모 레벨링이 주요 변수입니다). 불행하게도 썸 드라이브와 SD 카드는 일반적으로 예약된 공간의 양을 보고하는 SMART를 지원하지 않습니다.

그런데 이 테스트의 목적에 따라 fsyncvs는 수행 중인 블록 장치 쓰기에 영향을 주지 않습니다. fdatasync당신의 open()패턴이 중요합니다.

기술적인 세부 사항이 궁금하신 경우 SD 카드의 내부 작동에 대해 알고 싶은 모든 내용은 다음과 같습니다.https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

편집하다:바이트 및 페이지:이러한 유형의 테스트에서는 바이트보다는 페이지 측면에서 사물을 생각하는 것이 중요합니다. 반대로 하면 매우 오해를 불러일으킬 수 있습니다. 예를 들어 SanDisk 8GB SD에서 /sys/classes/mmc_host/mmc?/mmc?:????/preferred_erase_size컨트롤러에 따른 페이지 크기(접근 가능)는 전체 4MB입니다. 16MB를 쓰고(4MB 경계에 맞춰 정렬됨) 4페이지를 지우고 씁니다. 그러나 서로 4MB 오프셋으로 4개의 단일 바이트를 쓰면 4페이지도 삭제/쓰기됩니다.

따라서 "16MB 쓰기로 테스트했습니다"라고 말하는 것은 "4바이트 쓰기로 테스트했습니다"와 같은 마모량이므로 정확하지 않습니다. 좀 더 정확히 말하자면, "4페이지 작성을 테스트했습니다"입니다.

Question 3

slm의 답변에 몇 가지 요점을 추가하면 SSD가 재생할 수 있으므로 "멍청한"SD 카드보다 SSD에 더 적합합니다.많은데이터에 대한 더 더러운 트릭(예: 중복 제거):

장치 시작 부분에 64KB를 쓰고 있습니다. 이 자체에는 두 가지 문제가 있습니다.
1. 플래시 셀의 삭제 블록 크기는 일반적으로 16KB를 초과합니다(128~512KB 범위일 가능성이 더 높음). 이는 최소한 이 크기의 캐시가 필요하다는 것을 의미합니다. 그래서 64KB를 쓰는 것만으로는 충분하지 않은 것 같습니다.
2. 저가형("비엔터프라이즈" 읽기) 솔루션의 경우(저는 SSD보다 SD/CF 카드를 더 선호합니다) 제조업체는 다음과 같은 이유로 장치의 시작 부분을 나머지 부분보다 내마모성이 더 높게 만들도록 선택할 수 있습니다. 중요한 구조 - 장치의 단일 파티션에 있는 파티션 테이블과 FAT(대부분의 메모리 카드가 이 설정을 사용함)가 여기에 있습니다. 따라서 테스트 카드의 시작 부분이 편향될 수 있습니다.
fdatasync()데이터가 물리적 미디어에 기록된다는 보장은 없습니다(비록 운영 체제의 제어 하에 수행하는 것이 가장 좋지만). 매뉴얼 페이지를 참조하세요.

통화 차단장치가 보고할 때까지전송 완료

외부 전원이 없을 때 플래시에 캐시된 데이터를 쓸 수 있는 에너지를 제공할 수 있는 작은 커패시터가 있다는 것이 밝혀져도 별로 놀라지 않을 것입니다.

어떤 경우든 카드에 캐시가 있다고 가정합니다(참조:SU에 관한 귀하의 질문에 대한 나의 답변), 64KB를 쓰고 (와 fdatasync()) 동기화하는 것은 이 목적에 충분히 설득력이 없어 보입니다. "전원 백업"이 없더라도 펌웨어는 여전히 안전하지 않을 수 있으며 예상보다 조금 더 오랫동안 데이터가 기록되지 않은 상태로 남아 있을 수 있습니다(일반적인 사용에서는 문제가 발생하지 않기 때문입니다).
새 블록을 쓰기 전에 데이터를 읽고 비교하여 실제로 유효한지 확인하는 것이 좋습니다(편집증이 있는 경우 지워진 버퍼에서 읽으십시오).

Answer

slm의 답변에 몇 가지 요점을 추가하면 SSD가 재생할 수 있으므로 "멍청한"SD 카드보다 SSD에 더 적합합니다.많은데이터에 대한 더 더러운 트릭(예: 중복 제거):

장치 시작 부분에 64KB를 쓰고 있습니다. 이 자체에는 두 가지 문제가 있습니다.
1. 플래시 셀의 삭제 블록 크기는 일반적으로 16KB를 초과합니다(128~512KB 범위일 가능성이 더 높음). 이는 최소한 이 크기의 캐시가 필요하다는 것을 의미합니다. 그래서 64KB를 쓰는 것만으로는 충분하지 않은 것 같습니다.
2. 저가형("비엔터프라이즈" 읽기) 솔루션의 경우(저는 SSD보다 SD/CF 카드를 더 선호합니다) 제조업체는 다음과 같은 이유로 장치의 시작 부분을 나머지 부분보다 내마모성이 더 높게 만들도록 선택할 수 있습니다. 중요한 구조 - 장치의 단일 파티션에 있는 파티션 테이블과 FAT(대부분의 메모리 카드가 이 설정을 사용함)가 여기에 있습니다. 따라서 테스트 카드의 시작 부분이 편향될 수 있습니다.
fdatasync()데이터가 물리적 미디어에 기록된다는 보장은 없습니다(비록 운영 체제의 제어 하에 수행하는 것이 가장 좋지만). 매뉴얼 페이지를 참조하세요.

통화 차단장치가 보고할 때까지전송 완료

외부 전원이 없을 때 플래시에 캐시된 데이터를 쓸 수 있는 에너지를 제공할 수 있는 작은 커패시터가 있다는 것이 밝혀져도 별로 놀라지 않을 것입니다.

어떤 경우든 카드에 캐시가 있다고 가정합니다(참조:SU에 관한 귀하의 질문에 대한 나의 답변), 64KB를 쓰고 (와 fdatasync()) 동기화하는 것은 이 목적에 충분히 설득력이 없어 보입니다. "전원 백업"이 없더라도 펌웨어는 여전히 안전하지 않을 수 있으며 예상보다 조금 더 오랫동안 데이터가 기록되지 않은 상태로 남아 있을 수 있습니다(일반적인 사용에서는 문제가 발생하지 않기 때문입니다).
새 블록을 쓰기 전에 데이터를 읽고 비교하여 실제로 유효한지 확인하는 것이 좋습니다(편집증이 있는 경우 지워진 버퍼에서 읽으십시오).

Question 4

Peterph의 답변은 가능한 캐싱 문제에 대해 더 깊이 생각하게 만들었습니다. 조금 조사한 후에도 SD 카드 중 일부 또는 전체가 이 기능을 수행하는지 확실하지 않지만 가능하다고 생각합니다.

그러나 캐시가 삭제 블록보다 큰 데이터를 건드릴 것이라고는 생각하지 않습니다. 확실히 하기 위해 64kB 대신 16MB 청크를 사용하여 테스트를 반복했습니다. 이는 4GB 카드 전체 크기의 1/250입니다. 이를 10,000번 수행하는 데 약 8시간이 걸립니다. 웨어 레벨링이 부하를 분산시키려고 하면 각 물리적 블록이 40번 사용된다는 의미입니다.

많지는 않지만 테스트의 원래 의도는웨어 레벨링의 효율성 입증동일한(명백한) 위치에 적당한 양의 데이터를 반복적으로 기록한다고 해서 카드가 쉽게 손상될 수는 없습니다. IMO 이전 64kB 테스트는 실제일 수 있지만 16MB 테스트는 실제여야 합니다. 시스템이 데이터를 하드웨어로 플러시했으며 하드웨어는 오류 없이 쓰기를 보고했습니다. 이것이 사기라면 카드는 쓸모가 없으며 테스트 대상인 주 저장소 외에는 어디에서도 16MB를 캐시할 수 없습니다.

10,000회 쓰기(쓰기당 16MB)이면 저가형 브랜드 카드(값: $5 CDN)에서도 적당한 양의 데이터를 연중무휴로 쓰는 rw 루트 파일 시스템을 실행하기에 충분한 증거가 될 것입니다.카드는 합리적인 시간이 지나도 마모되지 않습니다. 만일은 27년인데 카드는 아직 멀쩡해요...

이보다 더 자질구레한 시스템을 개발하기 위해 돈을 받았다면 카드가 얼마나 오래 지속되는지 확인하기 위해 최소한 몇 가지 테스트를 수행하고 싶습니다.할 수 있는마지막. 내 직감으로는 이와 같이 낮은 쓰기 속도가 최대 속도로 계속해서 쓰는 데 몇 주, 몇 달 또는 몇 년이 걸릴 수 있다는 것입니다(온라인에서 이러한 비교 테스트가 많지 않다는 사실은 실제로 이것이 매우 긴 것).

카드가 아직 괜찮은지 확인하는 것과 관련하여 더 이상 badblocks기본 구성을 사용하는 것이 적절하지 않다고 생각합니다. 대신에 나는 이렇게 했습니다:

badblocks -v -w -b 524288 -c 8

이는 512kB 블록을 8회 반복하여 테스트하는 것을 의미합니다(= 4MB). 이것은 파괴적인 읽기 및 쓰기 테스트이므로 연속 루프에서 사용하면 내 홈브루 테스트처럼 장치에 스트레스를 줄 수 있습니다.

또한 그 위에 파일 시스템을 생성하고 2GB 파일로 복사한 다음 diff해당 파일을 원본과 비교한 다음 (파일이 .iso이므로) 이미지로 마운트하고 그 안의 파일 시스템을 탐색했습니다.

결국 카드는 여전히 괜찮습니다. 이것은 예상할 수 있습니다...

;) ;)

Answer

Peterph의 답변은 가능한 캐싱 문제에 대해 더 깊이 생각하게 만들었습니다. 조금 조사한 후에도 SD 카드 중 일부 또는 전체가 이 기능을 수행하는지 확실하지 않지만 가능하다고 생각합니다.

그러나 캐시가 삭제 블록보다 큰 데이터를 건드릴 것이라고는 생각하지 않습니다. 확실히 하기 위해 64kB 대신 16MB 청크를 사용하여 테스트를 반복했습니다. 이는 4GB 카드 전체 크기의 1/250입니다. 이를 10,000번 수행하는 데 약 8시간이 걸립니다. 웨어 레벨링이 부하를 분산시키려고 하면 각 물리적 블록이 40번 사용된다는 의미입니다.

많지는 않지만 테스트의 원래 의도는웨어 레벨링의 효율성 입증동일한(명백한) 위치에 적당한 양의 데이터를 반복적으로 기록한다고 해서 카드가 쉽게 손상될 수는 없습니다. IMO 이전 64kB 테스트는 실제일 수 있지만 16MB 테스트는 실제여야 합니다. 시스템이 데이터를 하드웨어로 플러시했으며 하드웨어는 오류 없이 쓰기를 보고했습니다. 이것이 사기라면 카드는 쓸모가 없으며 테스트 대상인 주 저장소 외에는 어디에서도 16MB를 캐시할 수 없습니다.

10,000회 쓰기(쓰기당 16MB)이면 저가형 브랜드 카드(값: $5 CDN)에서도 적당한 양의 데이터를 연중무휴로 쓰는 rw 루트 파일 시스템을 실행하기에 충분한 증거가 될 것입니다.카드는 합리적인 시간이 지나도 마모되지 않습니다. 만일은 27년인데 카드는 아직 멀쩡해요...

이보다 더 자질구레한 시스템을 개발하기 위해 돈을 받았다면 카드가 얼마나 오래 지속되는지 확인하기 위해 최소한 몇 가지 테스트를 수행하고 싶습니다.할 수 있는마지막. 내 직감으로는 이와 같이 낮은 쓰기 속도가 최대 속도로 계속해서 쓰는 데 몇 주, 몇 달 또는 몇 년이 걸릴 수 있다는 것입니다(온라인에서 이러한 비교 테스트가 많지 않다는 사실은 실제로 이것이 매우 긴 것).

카드가 아직 괜찮은지 확인하는 것과 관련하여 더 이상 badblocks기본 구성을 사용하는 것이 적절하지 않다고 생각합니다. 대신에 나는 이렇게 했습니다:

badblocks -v -w -b 524288 -c 8

이는 512kB 블록을 8회 반복하여 테스트하는 것을 의미합니다(= 4MB). 이것은 파괴적인 읽기 및 쓰기 테스트이므로 연속 루프에서 사용하면 내 홈브루 테스트처럼 장치에 스트레스를 줄 수 있습니다.

또한 그 위에 파일 시스템을 생성하고 2GB 파일로 복사한 다음 diff해당 파일을 원본과 비교한 다음 (파일이 .iso이므로) 이미지로 마운트하고 그 안의 파일 시스템을 탐색했습니다.

결국 카드는 여전히 괜찮습니다. 이것은 예상할 수 있습니다...

;) ;)

답변1

기대 수명

SLC

다층 커패시터

비교하다

답변2

답변3

답변4

;) ;)

관련 정보