Как лучше сделать кеширование на SSD?

Я для кэша использую LVM, потому что оно не дает выстрелить в ногу и при этом по сути просто обертка над dm-cache. Минусы: кэшировать можно только отдельные LV и ресайзить их можно только после отключения кэша, ну и всякие мелочи типа такого.

Сейчас сделал для теста раздел btrfs поверх lvm чтобы там образы виртуалок хранить. Тестирую как хорошо будет работать со сжатием и дедупликацией.

ZFS не предлагать, там TRIM нет.

Ну с LVM его по сути тоже нет.

Сейчас сделал для теста раздел btrfs поверх lvm чтобы там образы виртуалок хранить.

Это очень, очень плохая идея http://www.ilsistemista.net/index.php/virtualization/47-zfs-btrfs-xfs-ext4-an...

Ну и через сколько месяцев в случае LVM твердотельник выйдет из строя? Насколько вообще TRIM необходим в 2016 году?

У меня вопрос в тему всем. Допустим, есть LVM cache на SSD (writethrough, не writeback). На HDD есть EFI-раздел + криптоконтейнер, в криптоконтейнере есть LVM, поверх LVM - файловые системы и своп.

Если накроется SSD, можно ли просто так взять и отнести его в магазин, сдать по гарантии? Если на SSD не было криптоконтейнера dm-crypt, сможет ли кто-то теоретически что-то конфиденциальное увести?

Или нужно на SSD делать криптоконтейнер на весь диск, а поверх него - уже LVM cache writethrough?

Почему он должен выйти из строя? Максимум что будет - это деградация скорости записи. Ну и LVM таки может discard'ить свободные экстенты, не выделенные под LV.

Почему он должен выйти из строя

1. Рассогласование зарядов затворов транзисторов в ячейках. Ячейки будут становиться read-only.

2. Плохая изоляция заряда.

3. Влияние повышенных температур.

4. Возможность повреждения данных в соседних ячейках NAND при чтении. Стопиццот чтений ячейки подряд без перезаписи может повредить ее и соседние.

5. К постоянно работающему компу это не относится, но если SSD отключить и положить на полочку на три недельки, данных во многих ячейках может не стать.

SSD сейчас - гнилая технология, годится только под LVM cache, имхо. Имеет смысл брать SSD с большим сроком гарантии и регулярно сдавать обратно в магазин, покупая новые на вырученные деньги.

И какое отношение LVM имеет ко всему этому?

А я вот просто жесткими дисками пользуюсь. Один на NTFS, другой на ext4 со свапом. Всё работает прекрасно.

Быть может, тебе лучше подождать появления на рынке нормальных, долговечных ССД за недорого, а заодно и полноценной изкоробочной поддержки оных в линуксе, и перестать над собой издеваться?

Btrfs на HDD не советую.

Но он будет с файловой системой. Или я не смогу его использовать?

А COW выключать кто будет?

Я бы выбрал размещение горячих данных на SSD, без каких-либо кэшей. Их не так много, чтобы городить лишние слои.

Насколько вообще TRIM необходим в 2016 году?

Настолько, насколько был нужен всегда (и будет нужен всегда). Прошивка собирается без libastral и понятия не имеет, какие блоки нужно регулярно переписывать на новые места, а какие могут этим самым новым местом послужить «просто так».

Но работоспособность системы при отключении SSD — одна из главных моих целей.

SSD сейчас - гнилая технология, годится только под LVM cache, имхо.

И вот ты сейчас такой взял и привёл репрезентативную статистику смертей SSD. Нести ахинею-то все горазды.

Но работоспособность системы при отключении SSD — одна из главных моих целей.

Хреновая цель. Больше ничего не могу сказать.

Зачем?

В смысле 'зачем'? А если SSD того? У меня это уже было, не хочу чтобы после этого ОС превратилась в тыкву и надо было 3 часа танцевать с бекапами.

Нормальную схему в прошлом треде предложил ещё: накатить btrfs на ssd и раз в сутки и после каждого обновления делать btrfs send корня и хомяка на hdd. В случае чего просто загрузитесь с hdd и будете работать дальше.

а что за тред был, где ssd дохнут как мухи ?

посмотри в документации на свою материнку,
возможно там есть что-то типа интел смарт кэш..
какая-то технология кеширования,

https://ru.wikipedia.org/wiki/Smart_Response_Technology
оно?

бъемом от 20 до 64 Gb

А У меня 120

btrfs поверх lvm

гипербессмысленное действо

как хорошо будет работать со сжатием и дедупликацией.

не будет

Голосую за 3) и, наверное 5) тые пункты. У меня вот +обычный нотХДД за два дня разогрелся- ещё на шесть градусов (тепло становится), даже чересчур?

Идея ниочем. Как уже сказали, btrfs с LVM — очень плохая идея. Кроме того, зачем городить еще один слой? Если ты параноик и у тебя много денег, делай RAID1 из SSDшек, если ты параноик и нищий, то делай бэкапы (особенно если у тебя на SSD только система). Собственно, бэкапы придуманы в том числе для того, чтобы восстановить данные при выходе из строя носителя.

Хочу напомнить, что жесткие диски (особенно современные) тоже выходят из строя, в том числе без предупреждения от смарта.

LVM привлекает возможность сделать нативно кеш

а нужен ли он этот кэш? каков профит? как влияет на количество операций ввода/вывода? что будет с кэшем по потере питания? например тестил я writeback на рейдах iops-ы растут, а линейная скорость просаживается по сравнению с write, кто вам сказал что отложенная запись это гуд? кэш а-ля writethrough - писать сразу в два места, а смысл?

Смысл — более быстрое чтение

Умножаю плохость идеи с btrfs на lvm.

Хотя, ТС славится своим наркоманством, так что вряд ли его это остановит.

это только в том случае если будет постоянное обращение к данным из кэша, т.е. это только под конкретную задачу

Лол. А я и не собирался ставить btrfs на LVM. Я выбираю из двух.

а нужен ли он этот кэш? каков профит?

Тестил на рабочей машине flashcache и b-cache. Профит заметен особенно при сборке крупных проектов да и вообще при частых операциях записи/чтения, тем более что хард у меня был не самый быстрый. Такую штуку проще всего рассматривать как персистентный файловый кеш большого объёма, т.е. при заполнении кеша профита нет, но когда в него попали все часто используемые данные все становится значительно шустрее, более того его состояние сохраняется между перезагрузками, т.е. при следующем включении система будет шустрее сразу со старта.

Нет, трим не работает, если фс на LVM, проверенно опытным путем.

пичал. А в лвм есть замена функционалу TRIM?

Вот вики арча говорит, что можно включить
https://wiki.archlinux.org/index.php/Solid_State_Drives_(Русский)#.D0.92.D0.B...

А можно схему опыта? А то все источники утверждают, что все работает из коробки, а если еще и issue_discards = 1 поставить, то и lvreduce/lvremove будет тримить освободившееся место.

Ну там же написано, что

As such it does not seem to be required for «regular» TRIM requests (file deletions inside a filesystem) to be functional.

Трим будет работать только для свободных экстентов в пуле LVM, не для блоков фс.

ssd и lvm (комментарий)

Ясно. Я просто это предложение на английском не очень понял. И что теперь делать?

Не то предложение скопипастил, там должно быть первое из синего блока.

А в этом говорится что issue_discards не требуется для обычного трима. Хотя у меня с ним, что без, трим не работал.

А вы проверяли трим без LVM? Может, у вас SSD неправильный и трим вовсе не поддерживает. И да, lsblk -D покажите.

SSD - Samsung 840 evo, насколько помню, он поддерживает трим. Без LVM не проверял.

lsblk -D /dev/sdb
NAME                DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sdb                        0      512B       2G         0
├─sdb1                     0      512B       2G         0
├─sdb2                     0      512B       2G         0
├─sdb3                     0      512B       2G         0
├─sdb4                     0      512B       2G         0
├─sdb5                     0      512B       2G         0
├─sdb6                     0      512B       2G         0
└─sdb7                     0      512B       2G         0
  ├─lvm1-root              0      512B       2G         0
  ├─lvm1-home              0      512B       2G         0
  └─lvm1-containers        0      512B       2G         0

Ну так у вас (на уровне блок-девайса) TRIM работает, если еще discard в fstab есть, то и на уровне ФС работает. А нули в hdparm быть вовсе не обязаны:

There are different types of TRIM defined by SATA Words 69 and 169 returned from an ATA IDENTIFY DEVICE command:

• Non-deterministic TRIM: Each read command to the Logical block address (LBA) after a TRIM may return different data.

• Deterministic TRIM (DRAT): All read commands to the LBA after a TRIM shall return the same data, or become determinate.

• Deterministic Read Zero after TRIM (RZAT): All read commands to the LBA after a TRIM shall return zero.

https://en.wikipedia.org/wiki/Trim_(computing)#ATA

интел смарт кэш..

Софтовое проприетарное вендовое говно.

Короче, остановился на варианте с btrfs. Сейчас на HHD установлю генту, а потом, как установлю, на работающей системе попробую настроить кеш.

Btrfs на HDD? Ну удачи))

а что не то?

Btrfs - ФС, основанная на Copy-on-write. То есть, в ней высокая фрагментация by design. Советую готовиться к дико харатящему харду и тормозам.

*тарахтящему

Ну так CoW, насколько я знаю, можно выключить или включить автоматическую дефрагментацию.
http://forum.ubuntu.ru/index.php?topic=269710.0 тут вон тестирование показывает, что производительность довольно хорошая.