Czy można uzyskać SSD TRIM (odrzucić) działający na oprogramowaniu RAID ext4 + LVM + w systemie Linux?

Używamy RAID1 + 0 z md w Linuksie (obecnie 2.6.37), aby utworzyć urządzenie md, następnie używamy LVM do zarządzania woluminami na urządzeniu, a następnie używamy ext4 jako naszego systemu plików w grupach woluminów LVM.

Z dyskami SSD jako napędami chcielibyśmy, aby polecenia TRIM propagowały się przez warstwy (ext4 -> LVM -> md -> SSD) do urządzeń.

Wygląda na to, że do najnowszych jąder 2.6.3x dodano wiele nowych funkcji TRIM związanych z dyskami SSD, w tym o wiele większy zasięg scenariuszy Device Mapper, ale nadal nie wydaje się, aby można było poprawnie kaskadować.

Czy to już możliwe? Jeśli tak to jak? Jeśli nie, czy poczyniono jakieś postępy?

Niemożliwe, ponieważ Linux Soft RAID nie obsługuje (jeszcze?).

UPD. : Dzięki Wodin za poinformowanie mnie - według lkml.org/lkml/2012/3/11/261 to funkcjonalny został dodany zaproponował niedawno. proponowane ! = jednak zaakceptowane .

Od wersji 2.6.37 powinien być obecny ( źródło ) . Jądro nie robi tego w tle, proces odrzucania bloków jest obecnie zaprojektowany do uruchamiania na żądanie (skrypt cron!). Obsługa DM-crypt jeszcze nie istnieje.

13 stycznia 2011 r. Łatka została połączona z dm-raid1.c o treści:

dm raid1: support discard

Enable discard support in the DM mirror target.
Also change an existing use of 'bvec' to 'addr' in the union.

Nie jestem w 100%, ale myślę, że to jest okno łączenia dla wersji 2.6.38.

EXT4 dodało wsparcie jakiś czas temu, podobnie jak LVM. RAID to jedyny klucz, który nie ma wsparcia. Wydaje się, że od 13.01.2011 dodano obsługę. Poszukaj go w 2.6.38, a może 2.6.39.

Czas mijał, a obsługa TRIM jest zdecydowanie zawarta w jądrze 3.7 . Zatwierdzenie dla RAID10 brzmi :

To sprawia, że ​​md raid 10 obsługuje TRIM. Jeśli jeden dysk obsługuje odrzucanie, a drugi nie, lub jeden ma discard_zero_data, a drugi nie, może istnieć niespójność między danymi z takich dysków. Ale to nie powinno mieć znaczenia, odrzucone dane są bezużyteczne. To doda jednak dodatkową kopię podczas przebudowy.

Mdtrim może wymagać więcej pracy:

Cyberax-mdtrim-0a40e8d# ./mdtrim.py -m /dev/md4 -s /home
Scratch directory is /home, trimmer file size is 0 GB 790 MB
Found slave sdc2 on /dev/sdc with MD offset 0 and partition offset 249856
Creating trimmer file
252,2: device not found in /dev
Traceback (most recent call last):
  File "./mdtrim.py", line 120, in <module>
    if lines[2].find("assuming %d byte sectors" % sector_size) == -1:
IndexError: list index out of range

Możesz użyć mojego skryptu MDTRIM ( https://github.com/Cyberax/mdtrim/ ) do TRIM pustego miejsca w macierzach RAID poziomu ext4 / 3 poziomu 1. Rozpoczynamy go okresowo od crona i działa świetnie dla nas.

Dodanie obsługi innych poziomów RAID jest możliwe, ale nie mam na to czasu (ani nie potrzebuję).

Jak sugerowano tutaj Możesz użyć

lsblk -D

w celu sprawdzenia, czy urządzenia blokujące przechodzą przez polecenia odrzucania.

Zauważ też, że sekcja urządzenia w lvm.conf zawiera opcję issue_discards. Widzieć

man 5 lvm.conf

po więcej informacji.