LVM cache. Кэширование тонкого пула.

Брось каку. LVM cache самый днищный из всех кэшей.

Какой не днищенский? Нужно закэшировать lvm не разбирая vg/thin, там объём данных большой. Если б с нуля делал, то zfs заюзал бы.

Попробуй «–cachemode writeback»

Чтоб потерять данные когда ssd откажет? Не, не надо.

У меня впечатление, что lvcache работает только на prealocated lvm, но это не точно.

–cachemode writeback

Чтоб потерять данные когда ssd откажет? Не, не надо.

Режим «writethrough» не имеет смысла как кешировние, вообще. Это какой-то кривой недо raid1/mirror.

Режим «writethrough» не имеет смысла как кешировние, вообще.

writethrough - кэш на чтение, writeback - кэш на чтение и запись. Мне на запись не надо.
Читаем чего red hat пишет:

 cachemode argument is set to writethrough, which indicates that a write is considered complete only when it has been stored in both the cache pool logical volume and on the origin logical volume. 

writethrough - кэш на чтение

Нет. Это кеш на чтение только того, что записалось в кеш.

На коротоком промежутке это не имеет смысла, потому что всё будет закешировано самими ядром и файловой системой, и будет читаться оттуда.

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

Нет. Это кеш на чтение только того, что записалось в кеш.

Что значит нет? Я тоже самое написал ))

На коротоком промежутке это не имеет смысла, потому что всё будет закешировано самими ядром и файловой системой, и будет читаться оттуда. На долгом промежутке - это тоже имеет мало смысла. Кеш - это про оперативные данные, которые используются здесь и сейчас.

Я в курсе что такое кэш и как он работает. На zfs l2arc даёт заметный буст на чтение, ессесно после разогрева. Lvcache writethrough аналог l2arc, lvcache writeback = l2arc+zil. Вобщем теория и практика данного вопроса мне известна, хочу послушать использующих lvcache на тонких томах.

Lvcache writethrough аналог l2arc

Нет. LVM не кеширует (не записывает) читаемые данные в кеш.

Шапка много чего пишет.

Про lvm cache лучше забудь. С ним легко поймать проблем на свою пятую точку. Баг-трекер соврать не даст.

Нет. LVM не кеширует (не записывает) читаемые данные в кеш.

Именно это writethrough кэш и делает - кладёт читаемые данные в кэш.

Про lvm cache лучше забудь. С ним легко поймать проблем.

Нельзя поймать проблем. Отвал writethrough-lvcache на горячую не повреждает данные и может быть удалён штатными средствами.

Именно это writethrough кэш и делает - кладёт читаемые данные в кэш.

Сказочник, выкладывай пруфы.

И жду объяснения почему, если это так, ты создал эту тему?

Я сюда пришёл не анонимусов развлекать, а получить ответ на вопросы. Так что с троллингом переместись в другую ветку, а за тем как работает writethrough-кэш обратись к манам, у редхэта есть хороший, там всё написано. До свидания.

за тем как работает writethrough-кэш обратись к манам, у редхэта есть хороший, там всё написано

И где там написано, что в кеш пишется, когда читается?

Если у шапки все хорошо расписано, то не лучше ли там искать ответы?

У редхэта не описана практика применения lvcache на thin-томах.

В своё время на хер свалился я с кеширования в lvm (ощущение что это не работает, не покидало меня ни разу). Перешёл на zfs, а в некоторых местах загнал и l2arc в кеш последовательного чтения даже.

У редхэта не описана практика применения lvcache

А где описано у рЭдхЕта, как использовать lvmcache как read cache?

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html...

Я бы даже не занимался этим онанизмом, но 50Тб данных...

у рЭдхЕта

Это с рязанским или новгородским акцентом?

у рЭдхЕта

Это с рязанским или новгородским акцентом?

А это?

У редхэта

А это?
У редхэта

Именно так это звучит на инглише.

Не в состоянии перейти по ссылке?

Это консольный аналог поиска слова «read» на веб-странице. Мой консольный вариант хотя бы что-то находит, а вот графический браузер - нет.

Я вижу что это. Ты все статьи так читаешь?

У редхэта Именно так это звучит на инглише.

:)

Может редхет, или рэдхэт? Или все таки рьедхъет?

Извини за флуд. Я тут распробовал дедупликацию на zfs :) Крутая штука, если уметь её готовить. Сливаю на это добро бекапы от баз данных, на zfs прямо. Сжатие+dedup ух, бомбически)

Ты все статьи так читаешь?

Ты, давай, показывай использование как read cache. А не учи читать как ты, когда мерещится то, чего нет.

распробовал дедупликацию на zfs

Сколько ОЗУ на 1Тб кушает?

Надо техразделы закрывать от анонимного компоста, иначе придётся в толксах технические темы заводить.

Обсуждение модерации и унижение собеседника в техразделе.

У меня на локалхосте подложен кэш под пул, субъективно эффект есть, по мере чтения кэш заполняется.

Когда были созданы тонкие тома (до или после присоединения кеша) пофиг, для кэша весь пул - тупо блочное устройство.

Из минусов: нельзя увеличить тонкий пул не отключая кэш (по крайней мере не на федоре).

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

Из минусов: нельзя увеличить тонкий пул не отключая кэш (по крайней мере не на федоре).

В моём случае тонкий пул сделан на весь VG и на нём (VG/thin) уже тонкие тома VG/thin/tomX. Добавление/удаление тонких томов на тонком пуле VG/thin отключения кэша не требует.

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

Не все анонимы плохие

Что полезного, конкретно в этой ветке, написал анон?
Я только вчера вечером узнал, что maxcom реализовал очень нужную фичу Изменения на форуме: автор топика может запретить анонимные комментарии
Непременно буду использовать.

А что выдаёт dmsetup status?

UPD. И какая версия ядра?

Пока на стенде развлекаюсь, чтоб не сломать прод.

# dmsetup status
vg--tiny-lv_cache_cdata: 0 20971520 linear 
vg--tiny-lv_cache_cmeta: 0 2097152 linear 
vg--tiny-tom3: 0 104857600 thin 59968512 104857599
vg--tiny-thin-tpool: 0 976273408 thin-pool 3 5508/30720 294116/1906784 - rw discard_passdown queue_if_no_space - 1024 
vg--tiny-thin_tdata: 0 976273408 cache 8 516/262144 128 61631/163840 233999 288547 376223 1049023 0 0 0 3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 smq 0 rw - 
vg--tiny-tom2: 0 52428800 thin 22994432 22994431
vg--tiny-thin_tmeta: 0 245760 linear 
vg--tiny-tom1: 0 209715200 thin 67624448 209715199
vg--tiny-thin_tdata_corig: 0 976273408 linear 
vg--tiny-thin: 0 976273408 linear

Linux tiny-srv 5.3.0-26-generic

# lvs -a -o +devices
  Unknown feature in status: 8 516/262144 128 61631/163840 233999 288547 376223 1049023 0 0 0 3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 smq 0 rw - 
  Unknown feature in status: 8 516/262144 128 61631/163840 233999 288547 376223 1049023 0 0 0 3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 smq 0 rw - 
  LV                 VG      Attr       LSize   Pool       Origin             Data%  Meta%  Move Log Cpy%Sync Convert Devices            
  [lv_cache]         vg-tiny Cwi---C---  10,00g                               37,62  0,20            0,00             lv_cache_cdata(0)  
  [lv_cache_cdata]   vg-tiny Cwi-ao----  10,00g                                                                       /dev/sdc1(0)       
  [lv_cache_cmeta]   vg-tiny ewi-ao----   1,00g                                                                       /dev/sdc1(2560)    
  [lvol0_pmspare]    vg-tiny ewi-------   1,00g                                                                       /dev/sdc1(2816)    
  thin               vg-tiny twi-aotz-- 465,52g                               15,42  17,93                            thin_tdata(0)      
  [thin_tdata]       vg-tiny Cwi-aoC--- 465,52g [lv_cache] [thin_tdata_corig] 37,62  0,20            0,00             thin_tdata_corig(0)
  [thin_tdata_corig] vg-tiny owi-aoC--- 465,52g                                                                       /dev/sdb1(30)      
  [thin_tmeta]       vg-tiny ewi-ao---- 120,00m                                                                       /dev/sdb1(119204)  
  tom1               vg-tiny Vwi-a-tz-- 100,00g thin                          32,25                                                      
  tom2               vg-tiny Vwi-a-tz--  25,00g thin                          43,86                                                      
  tom3               vg-tiny Vwi-a-tz--  50,00g thin                          57,19

Я видишь… Я буратина хитрая. Тебе мои цифры ничего не скажут. Я включаю дедупликацию только там, где она уместна. - То есть именно в этом томе и ни в каких иных. 600 мегабайт у меня в памяти. Dedeup ratio 3.34, всего у меня на разных томах где имеет смысл включать это, занято: 437 гиг. Но, у меня ещё компрессия lz4 (только она годна для дедупликации, имей ввиду), сжимает в 4ре раза. Итого, считай я в 12 раз сократил места, я так полагаю. Если умножить dedup ratio на компресс ратио