LINUX.ORG.RU
ФорумAdmin

вопрос по lvm и raid

 ,


0

3

Решил разобраться с lvm и raid, а так же их совместное применение. Но вот смотрю/читаю и часто возникает вопрос. В чем сакральная разница между mkfs /dev/mdX и mkfs /dev/sdXY (где sdXY входит в mdX).

На лвм в этом плане более понятна эта абстракция, я добавляю N дисков в группу и потом создаю логический том и на нем файловую систему. Хотя опять же, а если я сделал раздел на /dev/sda1, потом туда накатил файлову систему, потом его добавил в PV, VG и создал логический том, то фс, созданная ранее, будет «не видна»? Объясните «для чайника», пожалуйста

Сырые устройства /dev/sdXY, входящие в рейд, на себе хранят об этом рейде метаданные. Так что прямое воздействие в обход /dev/mdXX закончится плохо.

realloc ★★★★
()

Самое главное — не пытайся использовать фичу LVM «зеркалирование RAID1». Это когда создаёшь зеркалированный LV, но зеркало, типа, «совместимо с RAID1». Дефолтный режим создания зеркалированного тома сейчас, между прочим.

Так вот: после нескольких дней траха на этих праздниках с разными версиями ядра, я таки выяснил, что поддержка этой херни в ядре не работала НИКОГДА. Начиная, блин, с 2011 года, когда оно появилось в версии 3.1. То есть, ты можешь такой том создать, отформатировать — и всё будет работать. До перезагрузки. При перезагрузке ты получишь в логах какую-нибудь херню типа «invalid ioctl»/«bad magic» и том откажется активироваться даже если ты попытаешься создать его вручную через dmsetup.

С 2011, КАРЛ! Пять долбаных лет! И всем насрать.

Единственные версии ядра, в которых это работает — это какие-то из последних 3.xx и 4.0. Там была багофича, при которой md не отваливался с ошибкой при попытке чтения метаданных (которые, насколько я понял, ему вообще не нужны — этим должен заниматься LVM-бэкенд), что позволяло dm-raid таки взлететь и нормально работать. Потом этот баг исправили и всё вернулось в исходное состояние.

Вообще, вся эта подсистема MD/DM/RAID в ядре — это капец. Абсолютно непрозрачный кусок говна. Разобраться невозможно, концов не найдёшь. Подозреваю, что и кернел-девелоперы разобраться там ни хера не могут. Так и живём.

(Но, блин, пять лет, ПЯТЬ! Я понимаю, может, зеркалированием именно логических томов, а не дисков целиком, мало кто пользуется. Но, блин, где гарантия, что какая-нибудь такая же херня не творится в сетевой подсистеме, например? Или в функциях шифрования?)

alegz ★★★★
()
Ответ на: комментарий от alegz

не пытайся использовать фичу LVM «зеркалирование RAID1». Это когда создаёшь зеркалированный LV, но зеркало, типа, «совместимо с RAID1».

Это ты о какой именно конфигурации говоришь? Кто на ком лежит?

Дефолтный режим создания зеркалированного тома сейчас, между прочим.

Дефолтный - где?

nbw ★★★
()
Ответ на: комментарий от nbw

Логический том может быть отзеркален на уровне LVM, на разные физические тома. Первоначально у LVM был свой собственный метод зеркалирования (--type=mirror), с некоторых пор добавили «RAID-совместимый» (--type=raid1) (позже и прочие там — raid5, 10 и т.д.) Тогда же сделали его дефолтным вместо mirror. Например, при «lvconvert -m1» без указания типа создаётся именно он.

alegz ★★★★
()
Ответ на: комментарий от alegz

Так вот: после нескольких дней траха на этих праздниках с разными версиями ядра, я таки выяснил, что поддержка этой херни в ядре не работала НИКОГДА. Начиная, блин, с 2011 года, когда оно появилось в версии 3.1

Да ладно. Можно ссылку на тикет в багтрекере ядра?

Может ты проглядел какой-нибудь важный requirements, вроде «не использовать для корневой ФС» или «не использовать вместе с systemd» ?

router ★★★★★
()
Ответ на: комментарий от alegz
$ sudo lvdisplay -m /dev/vg1/home
  --- Logical volume ---
  LV Path                /dev/vg1/home
  LV Name                home
  VG Name                vg1
  LV UUID                E3SBeI-byBZ-WkkH-niFN-cv2f-o8bp-JvY8mB
  LV Write Access        read/write
  LV Creation host, time debian, 2014-07-03 20:56:53 +0300
  LV Status              available
  # open                 1
  LV Size                20.00 GiB
  Current LE             5120
  Mirrored volumes       2               <<<<<<
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:17
   
  --- Segments ---
  Logical extents 0 to 5119:
    Type		raid1          <<<<<<<<<<<<
    Monitoring		monitored
    Raid Data LV 0
      Logical volume	home_rimage_0
      Logical extents	0 to 5119
    Raid Data LV 1
      Logical volume	home_rimage_1
      Logical extents	0 to 5119
    Raid Metadata LV 0	home_rmeta_0
    Raid Metadata LV 1	home_rmeta_1

Все работает нормально и давно.

anonymous
()
Ответ на: комментарий от nbw

можно делать разные типы рейда, для разных lv, кроме того alegz врет, нет никаких проблем с lvm-рейд

anonymous
()
Ответ на: комментарий от router

На досуге погугли фразу «systemd separate /usr»

Можешь привести реальный пример использования «separate /usr»? (Не сферически-вакуумный вида «этого требует наш особый жутко секретный программный комплекс» или «а вот просто потому, что я хочу иметь возможность так делать»).

nbw ★★★
()
Последнее исправление: nbw (всего исправлений: 2)
Ответ на: комментарий от router

Да ладно. Можно ссылку на тикет в багтрекере ядра?

https://bugzilla.kernel.org/show_bug.cgi?id=100491

Поправка: oops-ов в последних версиях нет, но и работы тоже. Вот репорт из дебиановского багтрекера, там ближе к теме:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804629

«не использовать вместе с systemd»

Для инита не использую. sysvinit + systemd-shim (Debian)

alegz ★★★★
()
Последнее исправление: alegz (всего исправлений: 1)
Ответ на: комментарий от router

Все эти репорты, кстати — после исправления упомянутой багофичи в 4.1. До того то ли всё работало, то ли никто не пользовался. Склоняюсь к последнему, потому что инфы в интернетах ноль. Я сам тоже нарвался после выхода 4.1, но вот когда перевел том на raid1 — не помню, до этого был mirror. Видимо, как раз в период, когда всё работало — какие-то из последних версий 3.xx или 4.0.

alegz ★★★★
()
Ответ на: комментарий от anonymous

debian jessy standard kernel 3.16

Если версия ядра 3.16.7-cktXX, где XX <= 16, то обновись (последняя в stable 3.16.7-ckt20). Тебя ждёт сюрприз в виде коммита b97e9257, который туда притащили из апстрима. Исправление той самой багофичи.

alegz ★★★★
()
Ответ на: комментарий от anonymous

если вдруг запорешь каким-либо образом корень, можно перегрузиться в резервный и все исправить

Если чувак «каким-либо образом запарывает корень» (эт как? Чо с ним делать надо такого, с корнем? Отдаёт каким-то психическим заболеванием), то он, наверное, таким же образом «запарывает» и /usr. Пример незащитан.

nbw ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.