Friday, 1 November 2013

Сборка resize2fs из комплекта e2fsprogs

Зачем? Для работы ploop на OpenVZ/CentOS 5. Для CentOS 6 в репозитории OpenVZ поставляется спец пакетик с обновленной (относительно системы) версией resize2fs:
rpm -ql e2fsprogs-resize2fs-static-1.42.3-3.el6.1.ovz.x86_64
/usr/libexec/resize2fs
Слинкован он при этом статически, без внешних зависимостей:
ldd /usr/libexec/resize2fs
linux-vdso.so.1 =>  (0x00007fff29eec000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f9fb7bee000)
libc.so.6 => /lib/libc.so.6 (0x00007f9fb785b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9fb7e15000)

Попробуем сделать тоже самое, но для OpenVZ на CentOS 5:
yum install -y gcc make
cd /usr/src
wget -Oe2fsprogs-1.42.3.tar.gz 'http://downloads.sourceforge.net/project/e2fsprogs/e2fsprogs/v1.42.3/e2fsprogs-1.42.3.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fe2fsprogs%2Ffiles%2Fe2fsprogs%2Fv1.42.3%2F&ts=1383316431&use_mirror=citylan'
tar -xf e2fsprogs-1.42.3.tar.gz
cd e2fsprogs-1.42.3/
./configure --prefix=/opt/e2fsprogs  --disable-debugfs --disable-defrag --disable-imager
make install

В итоге в папочке /opt/e2fsprogs мы обнаружим статически слинкованный resize2fs:
ldd /opt/e2fsprogs/sbin/resize2fs
linux-vdso.so.1 =>  (0x00007fff7ad85000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003201800000)
libc.so.6 => /lib64/libc.so.6 (0x0000003201000000)
/lib64/ld-linux-x86-64.so.2 (0x0000003200c00000)
Который можно закинуть на CentOS 5 ноду, чтобы добиться корректной работы ploop на CentOS 5.

Ради теста перекинул на другую машину и все заработало на ура:
./resize2fs
resize2fs 1.42.3 (14-May-2012)
Usage: ./resize2fs [-d debug_flags] [-f] [-F] [-M] [-P] [-p] device [new_size]

Но итог всей затеи - ploop на CentOS 5 не особо удачный:
This filesystem will be automatically checked every 23 mounts or
180 days, whichever comes first.  Use tune4fs -c or -i to override.
tune2fs 1.39 (29-May-2006)
tune2fs: Filesystem has unsupported feature(s) while trying to open /dev/ploop26472p1
Couldn't find valid filesystem superblock.
Error in run_prg_rc (util.c:289): Command tune2fs -ouser_xattr,acl /dev/ploop26472p1  exited with code 1
Unmounting device /dev/ploop26472
Failed to create image: Error in run_prg_rc (util.c:289): Command tune2fs -ouser_xattr,acl /dev/ploop26472p1  exited with code 1 [24]
Destroying container private area: /vz/private/7777
Creation of container private area failed
Надо менять в ploop вызовы tune2fs на tune4fs, так как в CentOS 5 пакеты и тулзы для экст2/3 и экст4 - отдельные.

12 comments:

  1. Здравствуйте. Судя по посту у вас используется ploop. Не натыкались на подобную проблему?

    ReplyDelete
    Replies
    1. День добрый!

      Нет, не натыкались, несмотря на очень большое число машин в продакшене.

      Вы уверены, что виновата не битая память/битый сам пл себе диск?

      Delete
    2. Тестировали на разных серверах с CentOS 6.4 и последним OpenVZ ядром и утилитами. Ошибка видна только если принудительно проверить раздел с /vz. Если просто перезагрузить сервер, то ошибку не покажет.

      Причем ошибки появятся если просто запустить и затем остановить контейнер с ploop. Мне кажется все дело в том, что ploop работает с ext4 напрямую в обход VFS.

      Delete
    3. Если чисто воспроизводится на актуальных ядрах, то прямая дорога на bugzilla.openvz.org, это очень и очень серьезно.

      Delete
  2. Уже зарепортили - ссылка в первом комментарии.

    ReplyDelete
  3. Уже зарепортили - ссылка в первом комментарии.

    ReplyDelete
    Replies
    1. А версию ядра/vzctl/ploop и конфигурацию, которой создается контейнер? А также tune2fs -l файловой системы, куда кладется контейнер. Мы попробуем воспроизвести у себя и если что отпишемся в баге.

      Delete
    2. # rpm -q vzkernel vzctl ploop
      vzkernel-2.6.32-042stab081.5.x86_64
      vzkernel-2.6.32-042stab081.8.x86_64
      vzctl-4.6-1.x86_64
      ploop-1.9-1.x86_64

      # uname -r
      2.6.32-042stab081.5

      # tune2fs -l /dev/VolGroup00/openvz
      tune2fs 1.41.12 (17-May-2010)
      Filesystem volume name:
      Last mounted on: /vz
      Filesystem UUID: fbe52007-1436-44ed-923a-3153ea4e8e3a
      Filesystem magic number: 0xEF53
      Filesystem revision #: 1 (dynamic)
      Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
      Filesystem flags: signed_directory_hash
      Default mount options: (none)
      Filesystem state: clean
      Errors behavior: Continue
      Filesystem OS type: Linux
      Inode count: 26869760
      Block count: 107479040
      Reserved block count: 5373952
      Free blocks: 98577450
      Free inodes: 25854847
      First block: 0
      Block size: 4096
      Fragment size: 4096
      Reserved GDT blocks: 998
      Blocks per group: 32768
      Fragments per group: 32768
      Inodes per group: 8192
      Inode blocks per group: 512
      RAID stride: 128
      RAID stripe width: 256
      Flex block group size: 16
      Filesystem created: Wed Oct 23 15:29:43 2013
      Last mount time: Fri Oct 25 12:07:31 2013
      Last write time: Fri Oct 25 12:07:31 2013
      Mount count: 1
      Maximum mount count: -1
      Last checked: Fri Oct 25 12:00:47 2013
      Check interval: 0 ()
      Lifetime writes: 127 GB
      Reserved blocks uid: 0 (user root)
      Reserved blocks gid: 0 (group root)
      First inode: 11
      Inode size: 256
      Required extra isize: 28
      Desired extra isize: 28
      Journal inode: 8
      First orphan inode: 6688926
      Default directory hash: half_md4
      Directory Hash Seed: ee1e49bf-b3fe-4f78-adac-bc28053d2b72
      Journal backup: inode blocks

      # vzctl create 1000 --ostemplate debian-6.0-i386-aitoc --layout ploop --diskspace 20g --config unlimited

      debian-6.0-i386-aitoc - немного кастомизированный template на базе этого.

      Delete
    3. Наш инженер отписался в тикете, у нас не вопроизвелось.

      + у меня большие подозрения, что в Вашем случае виновата виртуализация (ведь /dev/vdb1 - виртульный, а диск вы показываете - LVM), а не ploop сам по себе.

      Delete
    4. Стоп. Какой /dev/vdb1? У меня обычный сервер в роли hardware node для OpenVZ. Раздел под /vz это ext4 поверх LVM тома, который на RAID5 из SSD. Ошибки на хосте, а не в контейнере. Возможно я изначально неверно выразился.

      До внутренностей контейнеров у нас тестирование не дошло, раз на ноде не все чисто.

      Delete
    5. Читайте тикет - баг подтвердили, можно ждать фикса в скором будущем.

      А про виртульные машины зашла речь потому что у Вас в выдаче указано /dev/vdbX, в выдаче fsck.

      Delete
    6. Да, мой промах. Коллега тестил баг на другой конфигурации и зарепортил данные из виртуалки.

      Delete

Note: only a member of this blog may post a comment.