Verifikasi dukungan TRIM dengan BtrFS pada SSD

Kami sedang mencari untuk menggunakan BtrFS pada array disk SSD dan saya telah diminta untuk memverifikasi bahwa BtrFS sebenarnya melakukan operasi TRIM setelah menghapus file. Sejauh ini saya belum dapat memverifikasi bahwa perintah TRIM dikirim ke disk.

Saya tahu BtrFS tidak dianggap sebagai produksi siap, tetapi kami menyukai tepi perdarahan, oleh karena itu saya mengujinya. Servernya adalah Ubuntu 11.04 server 64-bit rilis (mkfs.btrfs versi 0.19). Saya telah menginstal kernel Linux 3.0.0 karena changelog BtrFS menyatakan bahwa TRIM massal tidak tersedia di kernel yang dikirimkan bersama Ubuntu 11.04 (2.6.38).

Inilah metodologi pengujian saya (awalnya diadopsi dari http://andyduffell.com/techblog/?p=852 , dengan modifikasi agar berfungsi dengan BtrFS):

• TRIM disk secara manual sebelum memulai: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
• Verifikasi drive itu TRIM'd: ./sectors.pl |grep + | tee sectors-$(date +%s)
• Mempartisi drive: fdisk /dev/sda
• Buat sistem file: mkfs.btrfs /dev/sda1
• Meningkat: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
• Buat file: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
• Pastikan file ada di disk: ./sectors.pl | tee sectors-$(date +%s)
• Hapus file uji: rm /mnt/testfile
• Lihat bahwa file pengujian TRIM dari disk: ./sectors.pl | tee sectors-$(date +%s)
• Verifikasi blok TRIM'd: diffdua sectors-*file terbaru

Pada titik ini, verifikasi pra-hapus dan pasca-hapus masih menunjukkan blok-blok disk yang sama sedang digunakan. Saya seharusnya melihat pengurangan jumlah blok yang digunakan. Menunggu satu jam (kalau-kalau perlu waktu agar perintah TRIM dikeluarkan) setelah file uji dihapus masih menunjukkan blok yang sama digunakan.

Saya juga telah mencoba memasang dengan -o ssd,discardopsi - opsi, tetapi itu tampaknya tidak membantu sama sekali.

Partisi yang dibuat dari fdiskatas (saya menjaga partisi kecil agar verifikasi dapat berjalan lebih cepat):

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.plSkrip saya (saya tahu ini tidak efisien, tetapi menyelesaikan pekerjaan):

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

Apakah metodologi pengujian saya cacat? Apakah saya melewatkan sesuatu di sini?

Terima kasih untuk bantuannya.

Jadi setelah beberapa hari mengerjakan ini, saya bisa menunjukkan bahwa BtrFS memang menggunakan TRIM. Saya tidak berhasil menjalankan TRIM di server tempat kami akan menggunakan SSD ini. Namun, ketika pengujian menggunakan drive yang sama dicolokkan ke laptop, tes berhasil.

Perangkat keras yang digunakan untuk semua pengujian ini:

• SSD penting m4 512GB
• HP DL160se G6
• LSI LSISAS9200-8e HBA
• kandang SAS generik
• Laptop Dell XPS m1210

Setelah banyak upaya gagal memverifikasi BtrFS di server, saya memutuskan untuk mencoba tes yang sama menggunakan laptop lama (menghapus lapisan kartu RAID). Upaya awal pengujian ini menggunakan Ext4 dan BtrFS pada laptop gagal (data tidak TRIM).

Saya kemudian memutakhirkan firmware drive SSD dari versi 0001 (seperti dikirim keluar dari kotak) ke versi 0009. Pengujian diulangi dengan Ext4 dan BtrFS dan kedua sistem file berhasil MEMPERPANJANG data.

Untuk memastikan perintah TRIM punya waktu untuk berjalan, saya melakukan rm /mnt/testfile && sync && sleep 120sebelum melakukan validasi.

Satu hal yang perlu diperhatikan jika Anda mencoba tes yang sama: SSD telah menghapus blok tempat mereka beroperasi (saya tidak tahu ukuran blok penghapusan m4 yang penting). Ketika sistem file mengirimkan perintah TRIM ke drive, drive hanya akan menghapus blok lengkap; jika perintah TRIM ditentukan untuk sebagian blok, blok itu tidak akan TRIM karena sisa data yang valid dalam blok hapus.

Jadi untuk menunjukkan apa yang saya bicarakan (output dari sectors.plskrip di atas). Ini dengan file uji pada SSD. Periode adalah sektor yang hanya mengandung nol. Plus memiliki satu atau lebih byte yang bukan nol.

File uji pada drive:

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

File uji dihapus dari drive (setelah a sync && sleep 120):

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

Tampaknya sektor pertama dan terakhir dari file berada dalam blok hapus yang berbeda dari sisa file. Karena itu beberapa sektor tidak tersentuh.

Formulir takeaway ini: beberapa instruksi pengujian Ext4 TRIM meminta pengguna untuk hanya memverifikasi bahwa sektor pertama adalah TRIM dari file. Penguji harus melihat sebagian besar file tes untuk benar-benar melihat apakah TRIM berhasil atau tidak.

Sekarang untuk mencari tahu mengapa mengeluarkan perintah TRIM secara manual yang dikirim ke SSD melalui kerja kartu RAID tetapi perintah TRIM otomatis untuk tidak ...

Berdasarkan apa yang saya baca, mungkin ada kesalahan dalam metodologi Anda.

Anda mengasumsikan bahwa TRIM akan menghasilkan SSD Anda dengan mem-blok-blokkan blok-blok yang telah dihapus. Namun hal ini sering tidak terjadi.

Itu hanya jika SSD mengimplementasikan TRIM sehingga nol blok yang dibuang. Anda dapat memeriksa apakah perangkat setidaknya cukup tahu untuk melaporkan discard_zeroes_data:

cat / sys / block / sda / queue / discard_zeroes_data

Juga, bahkan jika SSD tidak nol, mungkin perlu waktu - baik setelah discard selesai - agar SSD benar-benar nol blok (ini berlaku untuk beberapa SSD berkualitas lebih rendah).

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

BTW Saya sedang mencari cara yang dapat diandalkan untuk memverifikasi TRIM dan belum menemukannya. Saya ingin tahu jika ada yang menemukan jalan.

Berikut ini adalah metodologi pengujian untuk 10.10 dan EXT4. Mungkin itu akan membantu.

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

Oh dan saya pikir Anda perlu membuang parameter pada fstab mount. Tidak yakin apakah param SSD diperlukan karena saya pikir seharusnya mendeteksi SSD secara otomatis.

Untuk btrf Anda memerlukan discardopsi untuk mengaktifkan dukungan TRIM.

Tes yang sangat sederhana namun berfungsi untuk TRIM fungsional ada di sini: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2

Beberapa hal yang perlu dipikirkan (untuk membantu menjawab pertanyaan "apakah saya kehilangan sesuatu?"):

• apa sebenarnya / dev / sda? satu SSD? atau (hardware?) RAID array SSD?

• jika yang terakhir maka apa jenis RAID controller?

• dan apakah pengontrol serangan Anda mendukung TRIM?

dan akhirnya,

• apakah metode pengujian Anda memberi Anda hasil yang Anda harapkan jika Anda memformat / dev / sda1 dengan sesuatu selain btrfs?

Hampir semua SSD dengan antarmuka SATA menjalankan semacam sistem file struktur log yang benar-benar tersembunyi dari Anda. Perintah 'trim' SATA memberi tahu perangkat bahwa blok tidak lagi digunakan dan bahwa filesystem struktur log yang mendasarinya dapat mem-flashnya / jika / blok hapus yang sesuai (yang mungkin jauh lebih besar) / hanya / berisi blok yang ditandai dengan trim.

Saya belum membaca dokumen standar, yang ada di sini: http://t13.org/Documents/MinutesDefault.aspx?keyword=trim , tapi saya tidak yakin apakah ada jaminan tingkat standar yang dapat Anda lakukan lihat hasil dari perintah trim. Jika Anda dapat melihat sesuatu berubah, seperti beberapa byte pertama yang nol pada awal blok hapus, saya tidak berpikir ada jaminan ini berlaku di perangkat yang berbeda atau bahkan mungkin versi firmware.

Jika Anda berpikir tentang cara abstraksi diimplementasikan, seharusnya dimungkinkan untuk membuat hasil dari perintah trim benar-benar tidak terlihat oleh yang baru saja membaca / menulis blok. Lebih jauh lagi mungkin sulit untuk mengetahui blok mana yang berada dalam blok hapus yang sama, karena hanya layer terjemahan flash yang tahu itu dan mungkin telah menyusunnya kembali secara logis.

Mungkin ada perintah SATA (perintah OEM mungkin?) Untuk mengambil metadata yang terkait dengan lapisan terjemahan flash SSD?