ตรวจสอบการรองรับ TRIM ด้วย BtrFS บน SSD


21

เรากำลังมองหาการใช้ BtrFS ในอาร์เรย์ของดิสก์ SSD และฉันถูกขอให้ตรวจสอบว่า BtrFS นั้นจริงแล้วทำการดำเนินการ TRIM เมื่อทำการลบไฟล์ จนถึงตอนนี้ฉันไม่สามารถตรวจสอบได้ว่าคำสั่ง TRIM ถูกส่งไปยังดิสก์

ฉันรู้ว่า BtrFS นั้นยังไม่พร้อมสำหรับการผลิต แต่เราชอบขอบเลือดที่ไหลออกดังนั้นฉันจึงทำการทดสอบ เซิร์ฟเวอร์คือเซิร์ฟเวอร์ Ubuntu 11.04 ที่วางจำหน่าย 64 บิต (mkfs.btrfs รุ่น 0.19) ฉันได้ติดตั้งเคอร์เนล Linux 3.0.0 เนื่องจากBtrFS changelogระบุว่า TRIM จำนวนมากไม่สามารถใช้ได้ในเคอร์เนลที่จัดส่งมาพร้อมกับ Ubuntu 11.04 (2.6.38)

นี่คือวิธีการทดสอบของฉัน (เริ่มแรกนำมาจากhttp://andyduffell.com/techblog/?p=852ด้วยการแก้ไขเพื่อทำงานกับ BtrFS):

  • ตัดแผ่นดิสก์ด้วยตนเองก่อนเริ่ม: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
  • ตรวจสอบว่าไดรฟ์เป็น TRIM'd: ./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'd จากดิสก์: ./sectors.pl | tee sectors-$(date +%s)
  • ตรวจสอบการบล็อก TRIM: diffสองsectors-*ไฟล์ล่าสุด

ณ จุดนี้การตรวจสอบการลบล่วงหน้าและโพสต์การลบจะยังคงแสดงบล็อกดิสก์ที่ใช้งานอยู่ ฉันควรเห็นการลดลงของจำนวนบล็อกการใช้งานแทน รอหนึ่งชั่วโมง (ในกรณีที่ใช้เวลาสักครู่สำหรับคำสั่ง 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 ควรจัดส่งภายในไม่กี่สัปดาห์ข้างหน้าดังนั้นเราควรได้รับการคุ้มครองจากเวลาที่เราย้ายสิ่งนี้ไปผลิต นอกจากนี้เราจะมีสำเนาของข้อมูลหลายชุดดังนั้นหากเราทำสำเนาหนึ่งชุดเรามีอีกสองชุดที่จะเรียกคืน แต่ฉันยอมรับอย่างเต็มที่ว่านี่ไม่ใช่ระบบไฟล์สำหรับผู้ที่มีข้อมูลที่ไม่สามารถถูกแทนที่ได้ในตอนนี้
เชนเมเยอร์ส

1
อาจจะไม่เปลี่ยนแปลงอะไรเลย แต่คุณก็อาจลองรันsyncไฟล์ rmming
zebediah49

ฉันต้องการจะบอกว่าฉันพยายามเรียกใช้syncหลังจากลบไฟล์และผลลัพธ์ยังคงเหมือนเดิม ฉันจะตรวจสอบอีกครั้งว่าเมื่อฉันกลับมาที่ออฟฟิศหลังจากวันหยุดสุดสัปดาห์สิ้นสุดลง
เชนเมเยอร์ส

หากคุณไม่คำนึงถึงขอบเลือดออกคุณได้พิจารณาzfsonlinux.orgหรือไม่ native (เช่นในเคอร์เนล, ไม่รวมฟิวส์) ZFS สำหรับ linux พวกเขากำลังใกล้กับอย่างเป็นทางการ "ปล่อย" และมี RCs ใช้ได้ (รวมถึงสัญญาซื้อขายไฟฟ้าสำหรับอูบุนตู - พอเรื่องง่ายที่จะสร้างสำหรับเดเบียนเกินไป)
CAS

คำตอบ:


4

ดังนั้นหลังจากผ่านไปหลายวันฉันก็สามารถแสดงให้เห็นว่า BtrFS ใช้ TRIM ฉันไม่สามารถให้ TRIM ทำงานบนเซิร์ฟเวอร์ที่เราจะปรับใช้ SSD เหล่านี้ให้สำเร็จ อย่างไรก็ตามเมื่อการทดสอบโดยใช้ไดรฟ์เดียวกันเสียบเข้ากับแล็ปท็อปการทดสอบจะสำเร็จ

ฮาร์ดแวร์ที่ใช้สำหรับการทดสอบทั้งหมดนี้:

  • Crucial m4 SSD 512GB
  • HP DL160se G6
  • LSI LSISAS9200-8e HBA
  • SAS ตู้ทั่วไป
  • แล็ปท็อป Dell XPS m1210

หลังจากความพยายามที่ล้มเหลวหลายครั้งในการตรวจสอบ BtrFS บนเซิร์ฟเวอร์ฉันตัดสินใจลองทดสอบเดียวกันโดยใช้แล็ปท็อปเครื่องเก่า (ลบเลเยอร์การ์ด RAID) ความพยายามเริ่มต้นของการทดสอบนี้โดยใช้ทั้ง Ext4 และ BtrFS บนแล็ปท็อปล้มเหลว (ข้อมูลไม่ใช่ TRIM'd)

ฉันอัพเกรดเฟิร์มแวร์ไดรฟ์ SSD จากรุ่น 0001 (ตามที่ส่งออกมาจากกล่อง) เป็นเวอร์ชัน 0009 การทดสอบซ้ำกับ Ext4 และ BtrFS และระบบไฟล์ทั้งสองประสบความสำเร็จในการตัดข้อมูล

เพื่อให้แน่ใจว่าคำสั่ง TRIM มีเวลาในการรันฉันทำrm /mnt/testfile && sync && sleep 120ก่อนดำเนินการตรวจสอบความถูกต้อง

สิ่งหนึ่งที่ควรทราบหากคุณกำลังพยายามทดสอบแบบเดียวกันนี้: SSD มีการลบบล็อกที่ทำงานอยู่ (ฉันไม่รู้ขนาดของบล็อกการลบ Crucial m4) เมื่อระบบไฟล์ส่งคำสั่ง TRIM ไปที่ไดรฟ์ไดรฟ์จะลบเฉพาะบล็อกทั้งหมด หากระบุคำสั่ง TRIM สำหรับส่วนของบล็อกบล็อกนั้นจะไม่เป็น TRIM เนื่องจากข้อมูลที่ถูกต้องที่เหลืออยู่ภายในบล็อกลบ

ดังนั้นเพื่อแสดงสิ่งที่ฉันกำลังพูดถึง (ผลลัพธ์ของsectors.plสคริปต์ด้านบน) นี่คือกับไฟล์ทดสอบบน SSD ช่วงเวลาเป็นภาคที่มีค่าศูนย์ ข้อดีมีอย่างน้อยหนึ่งไบต์ที่ไม่เป็นศูนย์

ทดสอบไฟล์ในไดรฟ์:

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

ลบไฟล์ทดสอบจากไดรฟ์ (หลัง a sync && sleep 120):

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

ปรากฏว่าภาคแรกและภาคสุดท้ายของไฟล์อยู่ในบล็อกการลบที่แตกต่างจากส่วนที่เหลือของไฟล์ ดังนั้นบางภาคถูกทิ้งไว้ไม่มีใครแตะต้อง

แบบฟอร์ม Takeaway นี้: คำแนะนำในการทดสอบ Ext4 TRIM บางคำสั่งให้ผู้ใช้ยืนยันว่าภาคแรกนั้นเป็น TRIM จากไฟล์ ผู้ทดสอบควรดูไฟล์ทดสอบส่วนใหญ่เพื่อดูว่า TRIM ประสบความสำเร็จหรือไม่

ทีนี้มาดูกันว่าทำไมคำสั่ง TRIM ที่ออกมาด้วยตนเองที่ส่งไปยัง SSD ผ่านการทำงานของการ์ด RAID แต่คำสั่ง TRIM อัตโนมัติไม่ ...


ฉันคิดว่าคำสั่งตัดแต่ง HW RAID ทั้งหมดกินดีที่เห็นว่าสิ่งต่าง ๆ กำลังเปลี่ยนแปลงอย่างช้าๆ ในทางตรงกันข้ามกับไดรฟ์ที่ทันสมัยดี TRIM มีความสำคัญน้อยลง
Ronald Pottol

4

ขึ้นอยู่กับสิ่งที่ฉันอ่านอาจมีข้อบกพร่องในวิธีการของคุณ

คุณกำลังสมมติว่า TRIM จะส่งผลให้ SSD ของคุณเป็นศูนย์บล็อกที่ถูกลบไปแล้ว อย่างไรก็ตามนี่ไม่ใช่กรณี

นั่นคือถ้า SSD ใช้ TRIM เพื่อให้เป็นศูนย์บล็อกที่ถูกทิ้ง คุณสามารถตรวจสอบว่าอุปกรณ์อย่างน้อยรู้เพียงพอที่จะรายงาน discard_zeroes_data:

cat / sys / block / sda / queue / discard_zeroes_data

นอกจากนี้แม้ว่า SSD จะมีค่าเป็นศูนย์ แต่อาจใช้เวลาสักครู่ - หลังจากที่ยกเลิกไปแล้ว - เพื่อให้ SSD เป็นศูนย์บล็อก (จริง ๆ แล้วเป็น 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(ดังที่ระบุไว้ด้านบน) และมันก็ไม่ได้ช่วยอะไร
เชนเมเยอร์ส

โอ้ดี คุ้มค่ากับการยิง :)
Dave Veffer

1

สำหรับ btrfs คุณต้องการdiscardตัวเลือกเพื่อเปิดใช้งานการสนับสนุน TRIM

การทดสอบที่ใช้งานง่าย แต่ใช้งานได้ของ TRIM อยู่ที่นี่: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2


1
ดังที่ได้กล่าวไว้ข้างต้นฉันลองทดสอบด้วยdiscardตัวเลือกและssdตัวเลือก เอกสาร BtrFS พูดถึงssdตัวเลือกมากมายดังนั้นฉันจึงมุ่งเน้นการทดสอบที่นั่น แต่ไม่มีตัวเลือกใดที่ทำให้ได้ผลลัพธ์ตามที่คาดหวัง หน้าเว็บส่วนใหญ่ที่แสดงวิธีทดสอบ TRIM สำหรับ Ext4 และหน้าตาที่คล้ายคลึงกัน BtrFS ไม่สามารถทดสอบโดยใช้วิธีการเหล่านั้นเนื่องจากความแตกต่างในการออกแบบระบบไฟล์
เชนเมเยอร์ส

hdparm --fibmapFS ไม่เชื่อเรื่องพระเจ้า บล็อกที่ที่อยู่ LBA ที่ระบุเป็นศูนย์หรือไม่ว่าจะเป็นตัวเลือก extN, btrfs, xfs, jfs ... ssdนั้นไม่เกี่ยวข้องกับการตัดแต่งให้ดูเช่นการสนทนานี้ในรายการส่งจดหมายของ btrfs : mail-archive.com/linux-btrfs @
Paweł Brodacki

ฉันลองใช้hdparm --fibmapแต่มันใช้ไม่ได้กับ BtrFS หากคุณดูที่ wiper.sh README (กระจายอยู่ข้าง hdparm) พวกเขาจะระบุอย่างชัดเจนว่าการเรียก "FIEMAP / FIBMAP ioctl () ไม่ปลอดภัยอย่างสมบูรณ์เมื่อใช้กับระบบไฟล์ btrfs" ดังนั้น hdparm หมดซึ่งแย่เกินไปเพราะจะทำให้การทดสอบง่ายขึ้นมาก ฉันไม่ทราบว่าssdตัวเลือกไม่มีส่วนเกี่ยวข้องกับ TRIM เนื่องจากเอกสารไม่ชัดเจนเกี่ยวกับประโยชน์ของตัวเลือก
เชนเมเยอร์ส

ขอบคุณสำหรับข้อมูลเพิ่มเติมเกี่ยวกับ ioctls ฉันไม่รู้ ฉันคิดว่าสถานที่ที่ดีที่สุดในการขอข้อมูลเพิ่มเติมอาจเป็นรายชื่อรับเมล btrfs คุณจะได้รับข้อมูลโดยตรงจากที่นั่น
Paweł Brodacki

1

บางสิ่งที่ต้องคิด (เพื่อช่วยตอบคำถาม "ฉันทำอะไรหายไป?"):

  • / dev / sda คืออะไรกันแน่? SSD เดี่ยวหรือไม่ หรืออาเรย์ RAID ของ SSD (หรือฮาร์ดแวร์)

  • ถ้าอย่างหลังแล้วคอนโทรลเลอร์ RAID ชนิดใด

  • และคอนโทรลเลอร์คอนโทรลเลอร์ของคุณรองรับ TRIM ได้หรือไม่

และในที่สุดก็,

  • วิธีการทดสอบของคุณให้ผลลัพธ์ที่คุณคาดหวังหากคุณฟอร์แมต / dev / sda1 กับสิ่งอื่นที่ไม่ใช่ btrfs หรือไม่?

1

SSD ทุกตัวที่มีอินเตอร์เฟส SATA ใช้ระบบไฟล์โครงสร้างบันทึกบางชนิดที่ซ่อนอยู่อย่างสมบูรณ์จากคุณ คำสั่ง SATA 'trim' บอกอุปกรณ์ว่าไม่มีการใช้งานบล็อกอีกต่อไปและระบบไฟล์โครงสร้างบันทึกพื้นฐานสามารถแฟลช / ถ้า / บล็อกการลบที่สอดคล้องกัน

ฉันยังไม่ได้อ่านเอกสารมาตรฐานซึ่งอยู่ที่นี่: http://t13.org/Documents/MinutesDefault.aspx?keyword=trimแต่ฉันไม่แน่ใจว่ามีการรับประกันระดับมาตรฐานที่คุณสามารถทำได้หรือไม่ เห็นผลลัพธ์ของคำสั่ง trim หากคุณเห็นการเปลี่ยนแปลงบางอย่างเช่นสองสามไบต์แรกที่ถูกปล่อยออกมาเป็นศูนย์ในช่วงเริ่มต้นของการลบบล็อกฉันไม่คิดว่าจะมีการรับประกันใด ๆ ซึ่งสามารถใช้ได้กับอุปกรณ์ที่แตกต่างกันหรือแม้กระทั่งเวอร์ชั่นเฟิร์มแวร์

หากคุณคิดเกี่ยวกับวิธีการนำนามธรรมมาใช้ควรเป็นไปได้ที่จะทำให้ผลลัพธ์ของคำสั่งตัดแต่งมองไม่เห็นอย่างสมบูรณ์สำหรับบล็อกอ่าน / เขียนเพียงอย่างเดียว นอกจากนี้อาจเป็นการยากที่จะบอกว่าบล็อกใดอยู่ในบล็อกลบเดียวกันเนื่องจากมีเพียงเลเยอร์การแปลแฟลชเท่านั้นที่ต้องรู้และอาจจัดลำดับใหม่อย่างมีเหตุผล

อาจมีคำสั่ง SATA (อาจเป็นคำสั่ง OEM?) สำหรับการดึงข้อมูลเมตาที่เกี่ยวข้องกับเลเยอร์การแปลแฟลชของ SSD หรือไม่

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.