Xác minh hỗ trợ TRIM với BtrFS trên SSD


21

Chúng tôi đang xem xét sử dụng BtrFS trên một loạt các ổ đĩa SSD và tôi đã được yêu cầu xác minh rằng BtrFS trên thực tế thực hiện các hoạt động TRIM khi xóa một tệp. Cho đến nay tôi không thể xác minh rằng lệnh TRIM được gửi đến các đĩa.

Tôi biết BtrFS không được coi là sẵn sàng sản xuất, nhưng chúng tôi thích lợi thế, vì vậy tôi đang thử nghiệm nó. Máy chủ là Ubuntu 11.04 máy chủ phát hành 64 bit (mkfs.btrfs phiên bản 0.19). Tôi đã cài đặt kernel Linux 3.0.0 vì thay đổi BtrFS nói rằng TRIM số lượng lớn không có sẵn trong kernel được gửi cùng với Ubuntu 11.04 (2.6,38).

Đây là phương pháp thử nghiệm của tôi (ban đầu được áp dụng từ http://andyduffell.com/techblog/?p=852 , với các sửa đổi để hoạt động với BtrFS):

  • TRIM thủ công các đĩa trước khi bắt đầu: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
  • Xác minh ổ đĩa là TRIM'd: ./sectors.pl |grep + | tee sectors-$(date +%s)
  • Phân vùng ổ đĩa: fdisk /dev/sda
  • Tạo hệ thống tập tin: mkfs.btrfs /dev/sda1
  • Núi: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
  • Tạo một tệp: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
  • Xác nhận tệp nằm trên đĩa: ./sectors.pl | tee sectors-$(date +%s)
  • Xóa tệp kiểm tra: rm /mnt/testfile
  • Xem tệp thử nghiệm là TRIM'd từ đĩa: ./sectors.pl | tee sectors-$(date +%s)
  • Xác minh các khối TRIM: diffhai sectors-*tệp gần đây nhất

Tại thời điểm này, các xác minh trước khi xóa và xóa bài vẫn hiển thị cùng một khối đĩa đang sử dụng. Thay vào đó tôi sẽ thấy giảm số lượng khối sử dụng. Đợi một giờ (trong trường hợp phải mất một lúc để lệnh TRIM được ban hành) sau khi tệp thử nghiệm bị xóa vẫn hiển thị các khối tương tự đang sử dụng.

Tôi cũng đã thử gắn kết với các -o ssd,discardtùy chọn, nhưng điều đó dường như không giúp được gì cả.

Phân vùng được tạo từ fdiskphía trên (Tôi giữ phân vùng nhỏ để xác minh có thể nhanh hơn):

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.plKịch bản của tôi (tôi biết điều này không hiệu quả, nhưng nó hoàn thành công việc):

#!/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";

Là phương pháp thử nghiệm của tôi là thiếu sót? Am i thiếu cái gì ở đây?

Cảm ơn đã giúp đỡ.


1
Tôi hoàn toàn hỗ trợ kiểm tra những thứ khó chịu, nhưng chỉ để bạn biết, ngay bây giờ, btrfs không có một fsck mà thực sự, bạn biết, đã sửa những thứ: btrfs.wiki.kernel.org/index.php/Main_Page - vì vậy chỉ cần coi chừng đó
Matt Simmons

@Matt - Điểm hay về fsck còn thiếu. Sự hiểu biết của tôi là phiên bản đầu tiên của một fsck sẽ xuất xưởng trong vài tuần tới, vì vậy chúng tôi sẽ được bảo vệ theo thời gian chúng tôi chuyển sản phẩm này sang sản xuất. Ngoài ra, chúng tôi sẽ có nhiều bản sao dữ liệu của mình, vì vậy nếu chúng tôi mất một bản sao, chúng tôi sẽ có ít nhất hai bản sao để khôi phục. Nhưng tôi hoàn toàn đồng ý rằng đây không phải là hệ thống tệp cho những người có dữ liệu không thể thay thế cho đến bây giờ.
Shane Meyers

1
Có lẽ sẽ không thay đổi bất cứ điều gì, nhưng bạn cũng có thể thử chạy một syncsau khi lục lại tệp.
zebediah49

Tôi muốn nói rằng tôi đã thử chạy một synctệp sau khi xóa tệp và kết quả vẫn như vậy. Tôi sẽ kiểm tra lại xem mặc dù khi tôi trở lại văn phòng sau khi cuối tuần kết thúc.
Shane Meyers

Nếu bạn không bận tâm đến việc chảy máu, bạn đã xem xét zfsonlinux.org chưa? ZFS riêng (tức là trong kernel, không phải cầu chì) cho linux. chúng gần với một "bản phát hành" chính thức và có sẵn RC (bao gồm cả PPA cho Ubuntu - đủ dễ dàng để xây dựng lại cho debian)
cas

Câu trả lời:


4

Vì vậy, sau nhiều ngày làm việc về điều này, tôi đã có thể chứng minh rằng BtrFS sử dụng TRIM. Tôi không thể thực hiện thành công TRIM trên máy chủ mà chúng tôi sẽ triển khai các SSD này. Tuy nhiên, khi kiểm tra bằng cách sử dụng cùng một ổ đĩa cắm vào máy tính xách tay, các thử nghiệm đã thành công.

Phần cứng được sử dụng cho tất cả các thử nghiệm này:

  • SSD cực kỳ quan trọng 512GB
  • HP DL160se G6
  • LSI LSISAS9200-8e HBA
  • bao vây chung chung
  • Máy tính xách tay Dell XPS m1210

Sau nhiều lần thất bại trong việc xác minh BtrFS trên máy chủ, tôi đã quyết định thử kiểm tra tương tự bằng máy tính xách tay cũ (loại bỏ lớp thẻ RAID). Những lần thử đầu tiên của thử nghiệm này bằng cả Ext4 và BtrFS trên máy tính xách tay đều thất bại (dữ liệu không phải TRIM'd).

Sau đó, tôi đã nâng cấp phần sụn ổ SSD từ phiên bản 0001 (khi được vận chuyển ra khỏi hộp) lên phiên bản 0009. Các thử nghiệm được lặp lại với Ext4 và BtrFS và cả hai hệ thống tệp đều TRIM dữ liệu thành công.

Để đảm bảo lệnh TRIM có thời gian chạy, tôi đã rm /mnt/testfile && sync && sleep 120thực hiện trước khi thực hiện xác nhận.

Một điều cần lưu ý nếu bạn đang thử cùng một bài kiểm tra này: SSD có các khối xóa mà chúng hoạt động (Tôi không biết kích thước của các khối xóa Crucial m4). Khi hệ thống tệp gửi lệnh TRIM đến ổ đĩa, ổ đĩa sẽ chỉ xóa một khối hoàn chỉnh; nếu lệnh TRIM được chỉ định cho một phần của khối, khối đó sẽ không phải là TRIM do dữ liệu hợp lệ còn lại trong khối xóa.

Vì vậy, để chứng minh những gì tôi đang nói về (đầu ra của sectors.plkịch bản ở trên). Đây là với tệp thử nghiệm trên SSD. Thời kỳ là các lĩnh vực chỉ chứa số không. Điểm cộng có một hoặc nhiều byte khác không.

Kiểm tra tập tin trên ổ đĩa:

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

Kiểm tra tệp đã bị xóa khỏi ổ đĩa (sau một sync && sleep 120):

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

Dường như các khu vực đầu tiên và cuối cùng của tệp nằm trong một khối xóa khác với phần còn lại của tệp. Do đó, một số lĩnh vực đã bị ảnh hưởng.

Một hình thức mang đi này: một số hướng dẫn kiểm tra Ext4 TRIM yêu cầu người dùng chỉ xác minh rằng khu vực đầu tiên là TRIM'd từ tệp. Người kiểm tra nên xem một phần lớn hơn của tệp kiểm tra để thực sự xem liệu TRIM có thành công hay không.

Bây giờ để tìm hiểu lý do tại sao các lệnh TRIM được phát thủ công được gửi đến SSD thông qua thẻ RAID hoạt động nhưng các lệnh TRIM tự động để không ...


Tôi nghĩ rằng tất cả các RAID RAID đều ăn các lệnh trim, thật tuyệt khi thấy mọi thứ đang dần thay đổi. Mặt khác, với các ổ đĩa hiện đại tốt, TRIM ngày càng ít vấn đề.
Ronald Pottol

4

Dựa trên những gì tôi đã đọc, có thể có một lỗ hổng trong phương pháp của bạn.

Bạn đang giả định rằng TRIM sẽ dẫn đến việc SSD của bạn hủy bỏ các khối đã bị xóa. Tuy nhiên điều này thường không phải là trường hợp.

Đó chỉ là khi SSD thực hiện TRIM để nó thay đổi các khối bị loại bỏ. Bạn có thể kiểm tra xem thiết bị ít nhất có đủ biết để báo cáo Discard_zeroes_data hay không:

mèo / sys / khối / sda / queue / Discard_zeroes_data

Ngoài ra, ngay cả khi SSD không hoạt động, có thể sẽ mất một thời gian - ngay sau khi loại bỏ hoàn thành - để SSD thực sự bằng 0 khối (điều này đúng với một số SSD chất lượng kém hơn).

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

BTW Tôi đang tìm kiếm một cách đáng tin cậy để xác minh TRIM và chưa tìm thấy một cách nào. Tôi muốn biết nếu có ai tìm được đường.


3

Đây là phương pháp thử nghiệm cho 10.10 và EXT4. Có lẽ nó sẽ giúp.

https://askubfox.com/questions/18903/how-to-enable-trim

Ồ và tôi nghĩ rằng bạn cần thông số loại bỏ trên mount fstab. Không chắc chắn nếu SSD param là cần thiết vì tôi nghĩ nó sẽ tự động phát hiện SSD.


2
Tôi đã cố làm theo hướng dẫn xác minh SSD Ext4, nhưng chúng không hoạt động do sự khác biệt trong cách BtrFS hoạt động so với các hệ thống tệp khác. Do đó quy trình làm việc tôi đã đưa ra. Tôi đã sử dụng ssdtùy chọn gắn kết để đảm bảo rằng BtrFS biết sử dụng mã dành riêng cho SSD của mình mặc dù nó sẽ tự động phát hiện. Tôi cũng đã thử sử dụng discard(như đã lưu ý ở trên) và nó không có ích.
Shane Meyers

Ồ tốt Đáng để bắn :)
Dave Veffer

1

Đối với btrfs, bạn cần discardtùy chọn để bật hỗ trợ TRIM.

Một thử nghiệm rất đơn giản nhưng hiệu quả đối với TRIM chức năng có tại đây: http ://tech Hành lý.com / article / eneac_and_testing_ssd_trim_support_under_linux/2


1
Như tôi đã đề cập ở trên, tôi đã thử kiểm tra của mình với cả discardtùy chọn và ssdtùy chọn. Các tài liệu BtrFS đề cập đến ssdtùy chọn rất nhiều, vì vậy tôi đã tập trung thử nghiệm của mình ở đó, nhưng không có tùy chọn nào dẫn đến kết quả mà tôi mong đợi. Hầu hết các trang web chỉ ra cách kiểm tra TRIM đều dành cho Ext4 và tương tự. BtrFS không thể được kiểm tra bằng các phương pháp đó do sự khác biệt trong thiết kế của hệ thống tệp.
Shane Meyers

hdparm --fibmaplà bất khả tri của FS. Một khối tại địa chỉ LBA đã cho là không có hoặc không, cho dù đó là tùy chọn extN, btrfs, xfs, jfs ... ssdkhông liên quan để cắt, xem ví dụ như cuộc thảo luận này về danh sách gửi thư của btrfs : mail-archive.com/linux-btrfs @ vger.kernel.org / dir10932.html .
Paweł Brodacki

Tôi đã thử sử dụng hdparm --fibmapnhưng nó không hoạt động trên BtrFS. Nếu bạn nhìn vào wiper.sh README (được phân phối cùng với hdparm), họ nói rõ rằng "các cuộc gọi FIEMAP / FIBMAP ioctl () hoàn toàn không an toàn khi được sử dụng trên hệ thống tập tin btrfs." Vì vậy, hdparm đã hết, điều này quá tệ vì điều này sẽ giúp việc kiểm tra dễ dàng hơn rất nhiều. Tôi không biết rằng ssdtùy chọn này không liên quan gì đến TRIM vì các tài liệu không rõ ràng về tính hữu ích của tùy chọn.
Shane Meyers

Cảm ơn bạn đã biết thêm thông tin về ioctls, tôi không biết điều đó. Tôi nghĩ rằng nơi tốt nhất để yêu cầu thêm thông tin có thể là danh sách gửi thư btrfs. Bạn sẽ nhận được thông tin trực tiếp từ đó.
Paweł Brodacki

1

Một số điều cần suy nghĩ (để giúp trả lời câu hỏi "tôi có thiếu điều gì không?"):

  • chính xác là gì / dev / sda? một ổ SSD? hoặc một mảng RAID (phần cứng?) của SSD?

  • Nếu sau này thì loại điều khiển RAID nào?

  • và bộ điều khiển đột kích của bạn có hỗ trợ TRIM không?

và cuối cùng,

  • phương pháp thử nghiệm của bạn có cung cấp cho bạn kết quả mà bạn mong đợi nếu bạn định dạng / dev / sda1 với một cái gì đó không phải là btrfs không?

1

Hầu như tất cả các ổ SSD có giao diện SATA đều chạy một số loại hệ thống tệp cấu trúc nhật ký hoàn toàn bị ẩn khỏi bạn. Lệnh 'trim' cho thiết bị biết rằng khối không còn được sử dụng nữa và hệ thống tệp cấu trúc nhật ký cơ bản có thể flash nó / if / khối xóa tương ứng (có thể lớn hơn đáng kể) / chỉ / chứa các khối được đánh dấu bằng trim.

Tôi chưa đọc các tài liệu tiêu chuẩn ở đây: http://t13.org/Document/MinutesDefault.aspx?keyword=trim , nhưng tôi không chắc có sự đảm bảo nào ở cấp độ tiêu chuẩn mà bạn có thể xem kết quả của một lệnh trim. Nếu bạn có thể thấy điều gì đó thay đổi, như một vài byte đầu tiên bị xóa khi bắt đầu khối xóa, tôi không nghĩ có bất kỳ sự bảo đảm nào có thể áp dụng trên các thiết bị khác nhau hoặc thậm chí là phiên bản phần sụn.

Nếu bạn nghĩ về cách thức trừu tượng có thể được thực hiện, có thể làm cho kết quả của lệnh trim hoàn toàn vô hình đối với khối chỉ đọc / ghi. Hơn nữa, thật khó để biết khối nào nằm trong cùng một khối xóa, vì chỉ có lớp dịch flash phải biết điều đó và có thể đã sắp xếp lại chúng một cách hợp lý.

Có lẽ có một lệnh SATA (có lẽ là lệnh OEM?) Để tìm nạp siêu dữ liệu liên quan đến lớp dịch flash của SSD?

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.