Зачем? Для работы ploop на OpenVZ/CentOS 5. Для CentOS 6 в репозитории OpenVZ поставляется спец пакетик с обновленной (относительно системы) версией resize2fs:
Попробуем сделать тоже самое, но для OpenVZ на CentOS 5:
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.
Ради теста перекинул на другую машину и все заработало на ура:
Но итог всей затеи - 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Надо менять в ploop вызовы tune2fs на tune4fs, так как в CentOS 5 пакеты и тулзы для экст2/3 и экст4 - отдельные.
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. Не натыкались на подобную проблему?
ReplyDeleteДень добрый!
DeleteНет, не натыкались, несмотря на очень большое число машин в продакшене.
Вы уверены, что виновата не битая память/битый сам пл себе диск?
Тестировали на разных серверах с CentOS 6.4 и последним OpenVZ ядром и утилитами. Ошибка видна только если принудительно проверить раздел с /vz. Если просто перезагрузить сервер, то ошибку не покажет.
DeleteПричем ошибки появятся если просто запустить и затем остановить контейнер с ploop. Мне кажется все дело в том, что ploop работает с ext4 напрямую в обход VFS.
Если чисто воспроизводится на актуальных ядрах, то прямая дорога на bugzilla.openvz.org, это очень и очень серьезно.
DeleteУже зарепортили - ссылка в первом комментарии.
ReplyDeleteУже зарепортили - ссылка в первом комментарии.
ReplyDeleteА версию ядра/vzctl/ploop и конфигурацию, которой создается контейнер? А также tune2fs -l файловой системы, куда кладется контейнер. Мы попробуем воспроизвести у себя и если что отпишемся в баге.
Delete# rpm -q vzkernel vzctl ploop
Deletevzkernel-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+ у меня большие подозрения, что в Вашем случае виновата виртуализация (ведь /dev/vdb1 - виртульный, а диск вы показываете - LVM), а не ploop сам по себе.
Стоп. Какой /dev/vdb1? У меня обычный сервер в роли hardware node для OpenVZ. Раздел под /vz это ext4 поверх LVM тома, который на RAID5 из SSD. Ошибки на хосте, а не в контейнере. Возможно я изначально неверно выразился.
DeleteДо внутренностей контейнеров у нас тестирование не дошло, раз на ноде не все чисто.
Читайте тикет - баг подтвердили, можно ждать фикса в скором будущем.
DeleteА про виртульные машины зашла речь потому что у Вас в выдаче указано /dev/vdbX, в выдаче fsck.
Да, мой промах. Коллега тестил баг на другой конфигурации и зарепортил данные из виртуалки.
Delete