SSD의 BtrFS를 통한 TRIM 지원 확인


21

우리는 SSD 디스크 어레이에서 BtrFS를 사용하려고하고 있으며 파일을 삭제할 때 BtrFS가 실제로 TRIM 작업을 수행하는지 확인하라는 요청을 받았습니다. 지금까지 TRIM 명령이 디스크로 전송되었는지 확인할 수 없었습니다.

BtrFS는 생산 준비가 된 것으로 간주되지 않지만 우리는 최첨단을 좋아하므로 테스트하고 있습니다. 서버는 Ubuntu 11.04 서버 64 비트 릴리스 (mkfs.btrfs 버전 0.19)입니다. BtrFS 변경 로그 에 Ubuntu 11.04 (2.6.38)와 함께 제공된 커널에서 대량 TRIM을 사용할 수 없다는 내용 이 표시되어 Linux 3.0.0 커널을 설치했습니다 .

내 테스트 방법론은 다음과 같습니다 ( BtrFS와 함께 작동하도록 수정 된 http://andyduffell.com/techblog/?p=852 ) :

  • 시작하기 전에 디스크를 수동으로 트리밍하십시오. for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
  • 드라이브가 트림되었는지 확인하십시오. ./sectors.pl |grep + | tee sectors-$(date +%s)
  • 드라이브를 분할하십시오 : fdisk /dev/sda
  • 파일 시스템을 만듭니다. mkfs.btrfs /dev/sda1
  • 산: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
  • 파일을 작성하십시오. dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
  • 파일이 디스크에 있는지 확인하십시오. ./sectors.pl | tee sectors-$(date +%s)
  • 테스트 파일을 삭제하십시오. rm /mnt/testfile
  • 테스트 파일이 디스크에서 TRIM되었는지 확인하십시오. ./sectors.pl | tee sectors-$(date +%s)
  • TRIM'd 블록 확인 : diff가장 최근의 두 sectors-*파일

이 시점에서 사전 삭제 및 사후 삭제 확인에는 여전히 사용중인 동일한 디스크 블록이 표시됩니다. 대신 사용 블록 수가 줄어드는 것을 볼 수 있습니다. 테스트 파일이 삭제 된 후 1 시간을 기다리면 (TRIM 명령이 발행되는 데 시간이 걸리는 경우) 여전히 사용중인 블록이 동일하게 표시됩니다.

나는 또한 -o ssd,discard옵션으로 마운트를 시도했지만 전혀 도움이되지 않는 것 같습니다.

fdisk위에서 만든 파티션 (확인을 더 빨리 진행할 수 있도록 파티션을 작게 유지) :

root@ubuntu:~# fdisk -l -u /dev/sda

Disk /dev/sda: 512.1 GB, 512110190592 bytes
255 heads, 63 sectors/track, 62260 cylinders, total 1000215216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x6bb7542b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63      546209      273073+  83  Linux

sectors.pl스크립트 (이것은 비효율적이라는 것을 알고 있지만 작업을 완료합니다) :

#!/usr/bin/perl -w

use strict;

my $device = '/dev/sda';
my $start = 0;
my $limit = 655360;

foreach ($start..$limit) {
    printf "\n%6d ", $_ if !($_ % 50);
    my @sector = `/sbin/hdparm --read-sector $_ $device`;
    my $status = '.';
    foreach my $line (@sector) {
            chomp $line;
            next if $line eq '';
            next if $line =~ /$device/;
            next if $line =~ /^reading sector/;
            if ($line !~ /0000 0000 0000 0000 0000 0000 0000 0000/) {
                    $status = '+';
            }
    }
    print $status;
}
print "\n";

테스트 방법론에 결함이 있습니까? 여기에 뭔가 빠졌습니까?

도와 주셔서 감사합니다.


1
실제로, 당신은 수정의 일을 알고 나는 전적으로 가장자리 물건을 출혈 테스트를 지원하지만 그냥 알다시피, 지금의로, btrfs를은으로 fsck를 가지고 있지 않습니다 btrfs.wiki.kernel.org/index.php/Main_Page를 - 그래서 그냥 조심해
Matt Simmons

@Matt-누락 된 fsck에 대한 좋은 지적입니다. 내 이해는 fsck의 첫 번째 버전이 향후 몇 주 안에 배송 될 것이므로 이것을 프로덕션으로 옮기는 시점까지 다룰 것입니다. 또한 데이터 사본이 여러 개 있으므로 사본을 하나 잃으면 복원 할 사본이 두 개 이상 있습니다. 그러나 나는 이것이 대체 할 수없는 데이터를 가진 사람들을위한 파일 시스템이 아니라는 것에 완전히 동의합니다.
Shane Meyers

1
아마도 아무것도 변경하지는 않지만 sync파일을 rmming 한 후에도 실행 해보십시오.
zebediah49

sync파일을 제거한 후 실행을 시도했지만 결과는 여전히 동일 하다고 말하고 싶습니다 . 주말이 끝나고 사무실로 돌아 왔을 때 다시 확인하겠습니다.
Shane Meyers

최첨단을 신경 쓰지 않는다면 zfsonlinux.org 를 고려 습니까? 리눅스를위한 네이티브 (즉, 커널에서 퓨즈가 아닌) ZFS. 그들은 공식적인 "릴리스"에 가까우며 RC를 사용할 수 있습니다 (우분투를위한 PPA 포함 – 데비안을위한 재구성도 쉬움)
cas

답변:


4

그래서 며칠 동안이 작업을 한 후 BtrFS가 TRIM을 사용한다는 것을 보여줄 수있었습니다. 이 SSD를 배포 할 서버에서 TRIM 작업을 성공적으로 수행 할 수 없었습니다. 그러나 랩톱에 연결된 동일한 드라이브를 사용하여 테스트하면 테스트에 성공합니다.

이 모든 테스트에 사용되는 하드웨어 :

  • Crucial m4 SSD 512GB
  • HP DL160se G6
  • LSI LSISAS9200-8e HBA
  • 일반 SAS 인클로저
  • Dell XPS m1210 노트북

서버에서 BtrFS를 검증하려는 시도가 많이 실패한 후, 오래된 랩톱을 사용하여 동일한 테스트를 시도하기로 결정했습니다 (RAID 카드 계층 제거). 랩톱에서 Ext4와 BtrFS를 모두 사용하여이 테스트를 처음 시도하면 실패합니다 (데이터는 TRIM되지 않음)

그런 다음 SSD 드라이브 펌웨어를 버전 0001 (기본 제공)에서 버전 0009로 업그레이드했습니다. 테스트는 Ext4 및 BtrFS로 반복되었으며 두 파일 시스템 모두 데이터를 성공적으로 트리밍했습니다.

TRIM 명령을 실행할 시간을 확보하기 위해 rm /mnt/testfile && sync && sleep 120유효성 검사를 수행하기 전에 수행했습니다.

동일한 테스트를 시도하는 경우 한 가지 유의할 사항 : SSD에는 작동하는 지우기 블록이 있습니다 (Crucial m4 지우기 블록의 크기를 모릅니다). 파일 시스템이 TRIM 명령을 드라이브로 보내면 드라이브는 완전한 블록 만 지 웁니다. TRIM 명령이 블록의 일부에 대해 지정된 경우, 해당 블록은 지우기 블록 내에 남아있는 유효한 데이터로 인해 TRIM되지 않습니다.

그래서 내가 말하고있는 것을 보여주기 위해 ( sectors.pl위 의 스크립트 출력 ). 이것은 SSD의 테스트 파일과 함께 제공됩니다. 마침표는 0 만 포함하는 섹터입니다. 플러스에는 하나 이상의 0이 아닌 바이트가 있습니다.

드라이브의 테스트 파일 :

24600 .......................................+++++++++++
24650 ++++++++++++++++++++++++++++++++++++++++++++++++++
24700 ++++++++++++++++++++++++++++++++++++++++++++++++++
    -- cut --
34750 ++++++++++++++++++++++++++++++++++++++++++++++++++
34800 ++++++++++++++++++++++++++++++++++++++++++++++++++
34850 +++++++++++++++++++++++++++++.....................

드라이브에서 테스트 파일이 삭제되었습니다 (a 이후 sync && sleep 120).

24600 .......................................+..........
24650 ..................................................
24700 ..................................................
    -- cut --
34750 ..................................................
34800 ..................................................
34850 ......................+++++++.....................

파일의 첫 번째 섹터와 마지막 섹터가 나머지 파일과 다른 지우기 블록 내에있는 것 같습니다. 따라서 일부 섹터는 그대로 유지되었습니다.

테이크 아웃 형식 : 일부 Ext4 TRIM 테스트 지침은 사용자에게 첫 번째 섹터가 파일에서 TRIM되었는지 확인하도록 요청합니다. 테스터는 테스트 파일의 더 큰 부분을보고 TRIM의 성공 여부를 실제로 확인해야합니다.

이제 RAID 카드 작동을 통해 SSD에 수동으로 발행 된 TRIM 명령이 전송되었지만 자동 TRIM 명령이 작동하지 않는 이유는 무엇입니까?


나는 모든 HW RAID가 트림 명령을 먹었다 고 생각했다. 반면에 최신 드라이브를 사용하면 TRIM의 중요성이 점점 줄어 듭니다.
로널드 포톨

4

내가 읽은 내용에 따라 방법론에 결함이있을 수 있습니다.

TRIM이 SSD가 삭제 된 블록을 0으로 만든다고 가정합니다. 그러나 이것은 종종 그렇지 않습니다.

SSD가 TRIM을 구현하여 폐기 된 블록을 0으로 만드는 경우에만 해당됩니다. 장치가 최소한 ignore_zeroes_data를보고 할만큼 충분히 알고 있는지 확인할 수 있습니다.

고양이 / sys / block / sda / queue / discard_zeroes_data

또한 SSD가 0이더라도 폐기가 완료된 후 SSD가 실제로 블록을 0으로 만드는 데 시간이 걸릴 수 있습니다 (품질이 낮은 SSD의 경우도 마찬가지 임).

http://www.redhat.com/archives/linux-lvm/2011-April/msg00048.html

BTW TRIM을 검증 할 수있는 신뢰할만한 방법을 찾고 있었지만 아직 찾지 못했습니다. 누군가 길을 찾으면 알고 싶습니다.


3

다음은 10.10 및 EXT4에 대한 테스트 방법입니다. 아마 도움이 될 것입니다.

/ubuntu/18903/how-to-enable-trim

아, 그리고 나는 fstab 마운트에 폐기 매개 변수가 필요하다고 생각합니다. SSD를 자동 감지해야한다고 생각하기 때문에 SSD 매개 변수가 필요한지 확실하지 않습니다.


2
Ext4 SSD 검증 지침을 따르려고 시도했지만 다른 파일 시스템과 비교하여 BtrFS 작동 방식의 차이로 인해 작동하지 않습니다. 따라서 내가 만든 워크 플로. ssd마운트 옵션을 사용하여 BtrFS가 자동 감지해야하더라도 SSD 관련 코드를 사용하도록했습니다. 나는 또한 discard(위에서 언급했듯이) 사용하려고 시도했지만 도움이되지 않았습니다.
Shane Meyers

오 잘 샷 가치 :)
데이브 Veffer

1

btrfs의 경우 discardTRIM 지원을 활성화하는 옵션 이 필요합니다 .

기능성 TRIM에 대한 매우 간단하지만 작동하는 테스트는 다음과 같습니다. http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2


1
위에서 언급했듯이 discard옵션과 옵션으로 테스트를 시도했습니다 ssd. BtrFS 문서에는 ssd옵션이 많이 언급되어 있으므로 테스트에 중점을 두었지만 어느 옵션도 예상하지 못한 결과를 가져 왔습니다. TRIM을 테스트하는 방법을 보여주는 대부분의 웹 페이지는 Ext4 등을위한 것입니다. 파일 시스템 디자인의 차이로 인해 이러한 방법을 사용하여 BtrFS를 테스트 할 수 없습니다.
Shane Meyers

hdparm --fibmapFS에 구애받지 않습니다. 주어진 LBA 주소에서 블록 중 하나 그것의 발신, btrfs를, XFS, JFS 여부 ..., 제로 아웃되지 않거나 ssd옵션은 트림에 대한 무관하다, 예를 들어, 메일 링리스트 btrfs를에이 토론을 참조하십시오 mail-archive.com/linux-btrfs를 @ vger.kernel.org / msg10932.html .
Paweł Brodacki 님이

사용을 시도 hdparm --fibmap했지만 BtrFS에서 작동하지 않습니다. wiper.sh README (hdparm과 함께 배포)를 보면 "FIEMAP / FIBMAP ioctl () 호출은 btrfs 파일 시스템에서 사용될 때 완전히 안전하지 않다"고 명시 적으로 명시되어 있습니다. 그래서 hdparm이 나왔습니다. 테스트가 훨씬 쉬워지기 때문에 너무 나쁩니다. ssd문서가 옵션의 유용성에 대해 명확 하지 않기 때문에 옵션이 TRIM과 아무런 관련 이 없다는 것을 몰랐 습니다.
Shane Meyers

ioctl에 대한 추가 정보를 주셔서 감사합니다. 몰랐습니다. 추가 정보를 요청하는 가장 좋은 장소는 btrfs 메일 링리스트 일 수 있다고 생각합니다. 거기에서 직접 정보를 얻을 수 있습니다.
Paweł Brodacki

1

고려해야 할 사항 ( '내가 뭔가 빠졌습니까?'질문에 대한 답변을 제공하기 위해) :

  • 정확히 / dev / sda는 무엇입니까? 단일 SSD? 또는 SSD의 (하드웨어?) RAID 어레이?

  • 후자의 경우 어떤 종류의 RAID 컨트롤러입니까?

  • 레이드 컨트롤러가 TRIM을 지원합니까?

그리고 마지막으로,

  • 테스트 방법으로 / dev / sda1을 btrfs 이외의 형식으로 포맷하면 예상 한 결과를 얻을 수 있습니까?

1

SATA 인터페이스가있는 거의 모든 SSD는 완전히 숨겨져있는 일종의 로그 구조 파일 시스템을 실행합니다. SATA 'trim'명령은 장치에 블록이 더 이상 사용되지 않고 기본 로그 구조 파일 시스템이 해당 지우개 블록 (실제로 더 클 수 있음)을 / if / 플래시 할 수 있음을 나타냅니다.

http://t13.org/Documents/MinutesDefault.aspx?keyword=trim 표준 문서를 읽지 못했지만 표준 수준의 보증이 있는지 확실하지 않습니다. 트림 명령의 결과를 참조하십시오. 지우기 블록의 시작 부분에서 처음 몇 바이트가 0으로 바뀌는 것과 같은 변경 사항이 있으면 다른 장치 또는 펌웨어 버전에 적용 할 수있는 보장이 없다고 생각합니다.

추상화가 구현되는 방식에 대해 생각하면 블록 읽기 / 쓰기 명령만으로 trim 명령의 결과를 완전히 볼 수 없게 될 수 있습니다. 또한 플래시 트랜 슬 레이션 레이어 만이이를 알고 논리적으로 재정렬했을 수 있기 때문에 어떤 블록이 동일한 소거 블록에 있는지 알기가 어려울 수 있습니다.

아마도 SSD 플래시 변환 계층과 관련된 메타 데이터를 가져 오는 SATA 명령 (OEM 명령?)이 있습니까?

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.