SSD'deki BtrFS ile TRIM desteğini doğrulayın


21

BtrFS'yi bir dizi SSD disk üzerinde kullanmak istiyoruz ve BtrFS'nin aslında bir dosyayı silerken TRIM işlemleri gerçekleştirdiğini doğrulamam istendi. Şimdiye kadar TRIM komutunun disklere gönderildiğini doğrulayamadım.

BtrFS'nin üretime hazır sayılmadığını biliyorum, ancak kanama kenarını seviyoruz, bu yüzden test ediyorum. Sunucu Ubuntu 11.04 sunucusu 64 bit sürümüdür (mkfs.btrfs versiyon 0.19). BtrFS changelog , toplu TRIM’in Ubuntu 11.04 (2.6.38) ile birlikte gelen çekirdeğe uygun olmadığını belirttiği için Linux 3.0.0 çekirdeğini kurdum.

İşte benim test metodolojim (başlangıçta http://andyduffell.com/techblog/?p=852 adresinden BtrFS ile çalışacak değişiklikler ile benimsendi):

  • Başlamadan önce diskleri elle TRIM: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
  • Sürücünün TRIM'd olduğunu doğrulayın: ./sectors.pl |grep + | tee sectors-$(date +%s)
  • Sürücüyü bölümleyin: fdisk /dev/sda
  • Dosya sistemini yapın: mkfs.btrfs /dev/sda1
  • monte: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
  • Bir dosya oluşturun: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
  • Dosyanın diskte olduğunu doğrulayın: ./sectors.pl | tee sectors-$(date +%s)
  • Test dosyasını silin: rm /mnt/testfile
  • Test dosyasının diskten TRIM'd olduğunu görün: ./sectors.pl | tee sectors-$(date +%s)
  • TRIM'd bloklarını doğrulayın: diffen son iki sectors-*dosya

Bu noktada, silme öncesi ve silme doğrulamaları hala kullanılan disk bloklarını göstermektedir. Bunun yerine kullanımda blok sayısında bir azalma görmeliyim. Test dosyasının silinmesinden bir saat sonra (TRIM komutunun vermesi biraz zaman alabilir) test silindikten sonra hala kullanılan blokların aynı olduğu görülüyor.

Ayrıca -o ssd,discardseçeneklerle montaj yapmayı da denedim , ancak bu hiç de yardımcı olmuyor.

fdiskYukarıdan oluşturulan bölüm (bölümü daha küçük tutacağım, böylece doğrulama daha hızlı olabilir):

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

Benim sectors.plkomut dosyası (bu verimsiz olduğunu biliyorum ama bu iş bitmiş olur):

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

Test metodolojim hatalı mı? Burada bir şey mi eksik?

Yardım için teşekkürler.


1
Son derece kanayan şeyleri test etmeyi tamamen destekliyorum, ama bildiğiniz gibi, şu an itibariyle, btrfs aslında bir şeyleri düzelten bir fsck'e sahip değil. sadece buna dikkat et.
Matt Simmons

@Matt - Kayıp fsck ile ilgili iyi bir nokta. Anladığım kadarıyla, bir fsck’in ilk versiyonunun önümüzdeki birkaç hafta içinde gönderilmesi gerekiyor, bu yüzden bunu üretime taşıdığımız zaman kapsanmalıyız. Ek olarak, verilerimizin birden fazla kopyası olacak, bu nedenle bir kopyasını kaybedersek, geri yüklenecek en az iki kopya daha olacak. Ancak, şu an için yeri doldurulamaz veriye sahip kişilerin dosya sistemi olmadığına tamamen katılıyorum.
Shane Meyers

1
Muhtemelen hiçbir şeyi değiştirmeyecek, ancak syncdosyayı sıkıştırdıktan sonra çalıştırmayı deneyebilirsiniz .
zebediah49

Bir syncdosyayı kaldırdıktan sonra çalıştırmayı denediğimi ve sonuçların hala aynı olduğunu söylemek istiyorum . Haftasonu bittikten sonra ofise döndüğümde iki kez kontrol edeceğim.
Shane Meyers

kanamayı önemsemiyorsanız , zfsonlinux.org adresini düşündünüz mü? doğal (yani çekirdekte, sigortada değil) linux için ZFS. Onlar resmi bir "serbest bırakılması" için konum yakın ve (- kolay yeterince çok debian için yeniden Ubuntu için bir PPA dahil) kullanılabilir RCS var
cas

Yanıtlar:


4

Bu yüzden birkaç gün çalıştıktan sonra, BtrFS'nin TRIM kullandığını gösterebildim. Bu SSD'leri dağıtacağımız sunucuda TRIM çalışmasını başarılı bir şekilde yapamadım. Ancak, bir dizüstü bilgisayara bağlı aynı sürücüyü kullanarak test yaparken, testler başarılı olur.

Bu testlerin tümü için kullanılan donanım:

  • Çok önemli m4 SSD 512GB
  • HP DL160se G6
  • LSI LSISAS9200-8e HBA
  • genel SAS muhafazası
  • Dell XPS m1210 dizüstü bilgisayar

Sunucuda BtrFS'yi doğrulama konusunda yapılan başarısız denemelerden sonra, aynı testi eski bir dizüstü bilgisayar kullanarak denemeye karar verdim (RAID kart katmanını kaldırın). Dizüstü bilgisayarda hem Ext4 hem de BtrFS kullanılarak yapılan bu testin ilk girişimleri başarısız oluyor (veriler TRIM'deydi).

Daha sonra SSD sürücü donanım yazılımını 0001 sürümünden (kutudan çıkarıldığı gibi) 0009 sürümüne yükselttim. Testler Ext4 ve BtrFS ile tekrarlandı ve her iki dosya sistemi de verileri başarıyla TRIM'deydi.

TRIM komutunun çalıştırılması gereken zamanı sağlamak için rm /mnt/testfile && sync && sleep 120doğrulama yapmadan önce bir tane yaptım .

Aynı testi deniyorsanız dikkat etmeniz gereken bir şey: SSD'lerin üzerinde çalıştıkları blokları siliyorlar (Crucial m4 silme bloklarının boyutunu bilmiyorum). Dosya sistemi TRIM komutunu sürücüye gönderdiğinde, sürücü yalnızca tam bir bloğu siler; TRIM komutu bir bloğun bir kısmı için belirtilirse, bu blok, silme bloğunda kalan geçerli verilerden dolayı TRIM'd olmayacak.

Bu yüzden neden bahsettiğimi göstermek için ( sectors.plyukarıdaki betiğin çıktısı ). Bu SSD'deki test dosyasında. Dönemler, yalnızca sıfır içeren sektörlerdir. Artılar, bir veya daha fazla sıfır olmayan bayta sahiptir.

Sürücüdeki test dosyası:

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

Sınama dosyası sürücüden silindi (a'dan sonra sync && sleep 120):

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

Dosyanın ilk ve son bölümlerinin dosyanın geri kalanından farklı bir silme blokları içinde olduğu görülüyor. Bu nedenle bazı sektörlere dokunulmadı.

Bunun bir paket servisi vardır: Bazı Ext4 TRIM test talimatları, kullanıcıdan yalnızca ilk sektörün dosyadan TRIM'düğünü doğrulamasını ister. Test cihazı, TRIM'in başarılı olup olmadığını gerçekten görmek için test dosyasının daha büyük bir bölümünü görüntülemelidir.

Şimdi neden SSD'ye RAID kart ile gönderilen TRIM komutlarının manuel olarak verildiğini, ancak otomatik TRIM komutlarının…


Tüm HW RAID'in trim komutlarını yediğini, işlerin yavaşça değiştiğini görmek güzel olduğunu düşündüm. Öte yandan, iyi modern sürüşlerle TRIM daha az ve çok önemli.
Ronald Pottol

4

Ne okuduğuma dayanarak, metodolojisinde bir kusur olabilir.

TRIM’in SSD’nizin silinen blokları sıfırlamasıyla sonuçlanacağını varsayıyorsunuz. Ancak bu genellikle durum böyle değil.

Bu sadece SSD atılan blokları sıfırlayacak şekilde TRIM uygularsa geçerlidir. Aygıtın en azından discard_zeroes_data'yı bildirecek kadar bilgili olup olmadığını kontrol edebilirsiniz:

cat / sys / block / sda / kuyruk / discard_zeroes_data

Ayrıca, SSD sıfır olsa bile, atma işlemi tamamlandıktan hemen sonra - SSD'nin blokları gerçekten sıfırlaması biraz zaman alabilir (bu, daha düşük kaliteli SSD'ler için geçerlidir).

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

BTW TRIM'i doğrulamak için güvenilir bir yol arıyordum ancak henüz bulamadım. Birisi bir yol bulursa bilmek isterim.


3

İşte 10.10 ve EXT4 için test metodolojisi. Belki yardımcı olur.

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

Oh ve bence fstab dağı üzerindeki atma parametresine ihtiyacınız var. SSD paramuna ihtiyaç olup olmadığından emin değilim çünkü SSD'yi otomatik olarak algılaması gerektiğini düşünüyorum.


2
Ext4 SSD doğrulama talimatlarını izlemeye çalıştım, ancak BtrFS'nin diğer dosya sistemlerine kıyasla çalışma şeklindeki farklılıklar nedeniyle çalışmaz. Bu yüzden iş akışı geldi. ssdBtrFS'nin SSD'ye özgü kodunu otomatik algılaması gerekse de kullandığını bilmesini sağlamak için mount seçeneğini kullandım. Ayrıca discard(yukarıda belirtildiği gibi) kullanmayı denedim ve yardımcı olmadı.
Shane Meyers

Oh iyi. Bir atışa değer :)
Dave Veffer

1

Btrfs discardiçin TRIM desteğini etkinleştirme seçeneğine ihtiyacınız vardır .

İşlevsel TRIM için çok basit ama çalışma testi burada: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2


1
Yukarıda belirttiğim gibi, testimi hem discardseçenek hem de seçenek ile denedim ssd. BtrFS dokümanları ssdseçeneklerden çok bahsettiler , bu yüzden testlerimi oraya odakladım, ancak hiçbir seçenek beklediğim sonuçlarla sonuçlanmadı. TRIM'in nasıl test edileceğini gösteren çoğu web sayfası Ext4 ve benzeri içindir. BtrFS, dosya sisteminin tasarımındaki farklılık nedeniyle bu metodolojiler kullanılarak test edilemez.
Shane Meyers

hdparm --fibmapFS agnostiğidir. Verilen LBA adresindeki bir blok ya sıfırlanmış ya da değil, extN, btrfs, xfs, jfs ... ssdseçeneğinin trim ile alakasız olup olmadığı, örneğin btrfs posta listesinde bu tartışmaya bakınız: mail-archive.com/linux-btrfs @ vger.kernel.org / msg10932.html .
Paweł Brodacki

Kullanmayı denedim hdparm --fibmapama BtrFS'de çalışmıyor. Wiper.sh README dosyasına bakarsanız (hdparm ile birlikte dağıtılır), açıkça "FIEMAP / FIBMAP ioctl () çağrılarının btrfs dosya sisteminde kullanıldığında tamamen güvenli olmadığını" belirtir. Yani hdparm çıktı, bu testin çok daha kolay geçmesini sağlayacak kadar kötü. ssdSeçeneğin TRIM ile hiçbir ilgisi olmadığını bilmiyordum çünkü dokümanlar seçeneğin kullanışlılığı konusunda çok net değildi.
Shane Meyers

İoctls hakkında ek bilgi için teşekkür ederim, ben bilmiyordum. Ek bilgi istemek için en iyi yer btrfs posta listesi olabilir. Oradan ilk elden bilgi alacaksınız.
Paweł Brodacki

1

Düşünecek bazı şeyler ("Bir şeyi mi eksik?" Sorunuzu yanıtlamanıza yardımcı olmak için)

  • tam olarak / dev / sda nedir? tek bir SSD? veya bir (donanım?) RAID SSD dizisi?

  • ikincisi ne tür bir RAID denetleyicisine?

  • ve baskın denetleyiciniz TRIM'i destekliyor mu?

ve sonunda,

  • / dev / sda1'i btrfs dışında bir şeyle biçimlendirirseniz test yönteminiz size beklediğiniz sonuçları veriyor mu?

1

Neredeyse bir SATA arayüzüne sahip tüm SSD'ler, sizden tamamen gizlenmiş bir tür günlük yapı dosya sistemi çalıştırmaktadır. SATA 'trim' komutu cihaza bloğun artık kullanılmadığını ve altta yatan log yapı dosya sisteminin / if / if / karşılık gelen silme bloğunu (büyük ölçüde daha büyük olabilir) / sadece / trim ile işaretlenmiş blokları içerdiğini gösterebilir.

Burada bulunan standart dokümanları okumamıştım: http://t13.org/Documents/MinutesDefault.aspx?keyword=trim , ancak yapabileceğiniz herhangi bir standart seviye garantisi olup olmadığından emin değilim. Bir trim komutunun sonuçlarını görün. Bir şeylerin değişebileceğini görüyorsanız, ilk birkaç byte'ın bir silme bloğunun başında sıfırlandığı gibi, bunun farklı cihazlar veya hatta donanım yazılımı sürümü için geçerli bir garanti olduğunu sanmıyorum.

Soyutlamanın nasıl uygulanabileceğini düşünüyorsanız, trim komutunun sonucunu sadece okuma / yazma bloklarına göre görünmez kılmak mümkün olmalıdır. Ayrıca, hangi blokların aynı silme bloğunda olduğunu söylemek zor olabilir, çünkü yalnızca flaş çeviri katmanı bunu bilmek zorunda ve bunları mantıksal olarak yeniden sıralamış olabilir.

Belki de SSD'lerin flash çeviri katmanına ilişkin meta verileri almak için bir SATA komutu (belki de OEM komutu?) Vardır?

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.