https://opennet.dev/openforum/vsluhforumID13/1022.html Доброй консоли.<br>Есть способ, описанный подробно в статье habr.com <br>https://habr.com/ru/post/492834/. Я эту статью грызу, кусаю, лижу, курю и тщетно. Думаю до посинения, без просветления. Сжальтесь, пожалуйста.<br>Вот райд. Один pv, один vg, 1,2Тб. Хочу его нарезать, кусочек под кэш сюда, кусочек под кэш туда, вот тут почта, а этому lxc, а этот под облако. А вот эти два под тесты. Вот выше в статье все получается. Моя же Центось хочет работать с "реальными" девайсами, и кушать lvs-cache, как новый pv не желает категорически. А как кэшировать hdd, если целый рэйд очень жирно, а lvs кэширющего устройства должен быть в одной группе томов кэшируемого? Как Чайфы + Жванецкий,"Ээ?эй есть ещё сдесь хоть кто-то, умнее меняяяя??" Буду очень признателен.<br> https://opennet.dev/openforum/vsluhforumID13/1022.html#5 Sat, 04 Mar 2023 08:46:59 GMT &gt;[оверквотинг удален]<br>&gt;&gt; В этом случае выбирать backing store для lv можно через pvmove или <br>&gt;&gt; offset-ы. И, тогда, можно будет кэшировать и юзать thin в любой <br>&gt;&gt; комбинациив с одним pv.<br>&gt;&gt; Но, никакой практической пользы в этом подходе нет. Это сложно и не <br>&gt;&gt; недежно. Так что, не советую) <br>&gt; Спасибо. Я потом прочитал интересные заметки у amarao404 про деградацию mdadm raid <br>&gt; ssd. И пустил 4 ssd в простой линейный vgs без raid, <br>&gt; c созданиеm lvm-thin кэшированных на nvme. В целом полученным результатом доволен, <br>&gt; и прежде всего пониманием что сделал и куда бежать, если что <br>&gt; :-) <br><br>Ник у Вас подозрительно похож на автора статьи. Моё почтение, если так. Коммент выше - мой, но забыл залогиниться. Жду обещанного продолжения, про миграцию в геораспределенных кластерах.<br> https://opennet.dev/openforum/vsluhforumID13/1022.html#4 Sat, 04 Mar 2023 08:39:41 GMT &gt;[оверквотинг удален]<br>&gt;&gt; эти PV.<br>&gt; На самом деле, такое тоже возможно, но, это, скорее, для совсем уж <br>&gt; ценителей искусства. Можно сделать JBOD из SSD + HDD. SSD в <br>&gt; начале, HDD в конце. Из этого JBOD сделать pv, a на <br>&gt; нем vg.<br>&gt; В этом случае выбирать backing store для lv можно через pvmove или <br>&gt; offset-ы. И, тогда, можно будет кэшировать и юзать thin в любой <br>&gt; комбинациив с одним pv.<br>&gt; Но, никакой практической пользы в этом подходе нет. Это сложно и не <br>&gt; недежно. Так что, не советую) <br><br>Спасибо. Я потом прочитал интересные заметки у amarao404 про деградацию mdadm raid ssd. И пустил 4 ssd в простой линейный vgs без raid, c созданиеm lvm-thin кэшированных на nvme. В целом полученным результатом доволен, и прежде всего пониманием что сделал и куда бежать, если что :-)<br> https://opennet.dev/openforum/vsluhforumID13/1022.html#3 Sat, 04 Mar 2023 08:16:19 GMT &gt; "Один pv" значит никакого тебе кэширования средствами LVM. Перечитай статью и посчитай <br>&gt; сколько раз вызывается pvcreate. Особенно на чём именно и почему создаются <br>&gt; эти PV.<br><br>На самом деле, такое тоже возможно, но, это, скорее, для совсем уж ценителей искусства. Можно сделать JBOD из SSD + HDD. SSD в начале, HDD в конце. Из этого JBOD сделать pv, a на нем vg.<br>В этом случае выбирать backing store для lv можно через pvmove или offset-ы. И, тогда, можно будет кэшировать и юзать thin в любой комбинациив с одним pv.<br><br>Но, никакой практической пользы в этом подходе нет. Это сложно и не недежно. Так что, не советую)<br> https://opennet.dev/openforum/vsluhforumID13/1022.html#2 Thu, 17 Nov 2022 16:37:59 GMT &gt;&gt; https://habr.com/ru/post/492834/. Я эту статью грызу, кусаю, лижу, курю и тщетно. Думаю <br>&gt; А вообще что-либо с RAID1 - так себе идея, ибо тормоза. Есть <br>&gt; приличная замена - https://linuxhint.com/configure-zfs-cache-high-speed-io/ <br><br>Спасибо, я перечитывал. И пересчитывал. Автор умудрился разрезать raid6 на кусочки, и эти кусочки произвольно складывать в новые pv, выиграв в iops, и бэкапах, и в лабораторных стендах. <br>egrep '#pvcreate' lvm-matreshki.txt <br>#pvcreate /dev/md0<br>#pvcreate /dev/md2<br>#pvcreate --metadatasize 64m /dev/md3<br>#####pvcreate /dev/root/cache<br>#####pvcreate /dev/data/cache<br>#####pvcreate /dev/root/images<br>#pvcreate /dev/cache/cachedata<br>А я неприятно упёрся в потолок понимания текста на русском. <br>С фряхи я начинал, и кое-что про неё помню. Уважаю безмерно. Но мне не tank нужен, а вертолёт. А вертолёты это души сгоревших танков :-)<br>Ладно, спасибо. Пойду по пути где я понимаю, разберу на диски, разобью на разделы и уже с ними буду экспериментировать.<br> https://opennet.dev/openforum/vsluhforumID13/1022.html#1 Wed, 16 Nov 2022 15:20:20 GMT &gt; https://habr.com/ru/post/492834/. Я эту статью грызу, кусаю, лижу, курю и тщетно. Думаю <br>&gt; до посинения, без просветления. Сжальтесь, пожалуйста.<br>&gt; Вот райд. Один pv, один vg, 1,2Тб. Хочу его нарезать, кусочек под <br><br>"Один pv" значит никакого тебе кэширования средствами LVM. Перечитай статью и посчитай сколько раз вызывается pvcreate. Особенно на чём именно и почему создаются эти PV.<br><br>А вообще что-либо с RAID1 - так себе идея, ибо тормоза. Есть приличная замена - https://linuxhint.com/configure-zfs-cache-high-speed-io/<br><br>Только учти, что /boot и /root на ZFS в Linux лучше не совать - не всегда загрузишься.<br>