Недавно я настроил свой первый программный рейд с помощью mdadm, и после добавления дополнительных дисков в рейд я не могу изменить размер файловой системы до полного размера рейда. Я создал единую файловую систему (~ 16 ТБ) на / dev / md0 с помощью:
mkfs.ext4 -v -b 4096 -t huge -E stride=128,stripe-width=256 /dev/md0
Затем я мучительно ждал пару дней, пока все данные из старого рейда скопируются в новый рейд; Я переместил диски и увеличил рейд, а затем, наконец, я:
resize2fs -p /dev/md0
Что сообщает мне, что
resize2fs 1.42 (29-Nov-2011)
resize2fs: /dev/md0: The combination of flex_bg and !resize_inode features is not supported by resize2fs
Мне не хватает понимания того, для чего именно предназначены эти две функции или почему комбинация проблематична, поэтому вопреки моему здравому смыслу я попытался добавить resize_inode:
tune2fs -O +resize_inode /dev/md0
Но меня сбили:
Setting filesystem feature 'resize_inode' not supported.
И я недостаточно храбр, чтобы попытаться удалить flex_bg, поскольку я действительно не хочу делать ничего, что могло бы подвергнуть мои данные риску. Я запускаю Ubuntu 12.04 с ядром 3.5.1:
Linux critter 3.5.1-030501-generic #201208091310 SMP Thu Aug 9 17:11:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Я снова протестировал resize2fs с v1.42.5 (последний доступный выпуск), но безрезультатно. Итак, чтобы внести ясность, мой вопрос: как я могу изменить размер этой файловой системы ext4 до размера рейда (желательно, не воссоздавая ее)?
Изменить: вот некоторая информация о файловой системе, которая может быть полезна.
tune2fs -l /dev/md0
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name: <none>
Last mounted on: /media/Bigger
Filesystem UUID: baecfa03-74c1-42ad-8e19-3b823f05f502
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 274700288
Block count: 4395202560
Reserved block count: 219760128
Free blocks: 247712956
Free inodes: 274636266
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 2048
Inode blocks per group: 128
RAID stride: 128
RAID stripe width: 768
Flex block group size: 16
Filesystem created: Fri Aug 17 02:54:50 2012
Last mount time: Mon Aug 20 02:21:51 2012
Last write time: Mon Aug 20 02:25:07 2012
Mount count: 3
Maximum mount count: -1
Last checked: Fri Aug 17 02:54:50 2012
Check interval: 0 (<none>)
Lifetime writes: 16 TB
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
Default directory hash: half_md4
Directory Hash Seed: b357ba49-60b1-4c55-837f-a70c8285a8f5
Journal backup: inode blocks
Chida - я ранее находил те же самые URL-адреса, но по опыту знал, что ext4 будет обрабатывать более 16 ТБ с обновленным ядром и инструментами. Но все равно не работало.
Наконец-то я получил ответ от список рассылки linux-ext4 - в команда mkfs.ext4 Я использовал борковку. Я перепутал -t и -T. Он должен был читать:
mkfs.ext4 -v -b 4096 -t ext4 -T huge -E stride=128,stripe-width=256 /dev/md0
А потом, как мне сказали, он включил resize_inode и работал, как ожидалось.
Спасибо за вашу помощь.
Это может вам помочь - http://www.spinics.net/lists/linux-ext4/msg27511.html
Прежде чем что-либо делать, делайте резервные копии, так как то, что вы делаете, с ext4 кажется очень рискованным.
Посмотри это -- https://ext4.wiki.kernel.org/index.php/Ext4_Howto
WARNING: It is NOT recommended to resize the inodes using resize2fs with
e2fsprogs 1.41.0 or later, as this is known to corrupt some filesystems.
До 16 ТБ кажется приемлемым с 64-битной файловой системой ext4, но состояние инструментов, похоже, постоянно меняется. Это очень хорошее чтение - http://blog.ronnyegner-consulting.de/2011/08/18/ext4-and-the-16-tb-limit-now-solved/
Если вы не услышите здесь от разработчика файловой системы ext4, вы можете задать этот вопрос в списках рассылки ext4.
Я знаю, что это старый, но просто для того, чтобы кто-то прочитал это в будущем ...
Вflex_bg является (относительно новой) функцией, которая позволяет файловой системе более гибко делиться на «группы блоков». Традиционно он делится на группы блоков равного заранее определенного размера. Преимущество flex_bg состоит в том, что большая группа виртуальных блоков позволит, например, собрать большую таблицу inode, и тогда запись большого количества файлов может происходить быстрее, так как не нужно будет искать место в другой группе блоков.
В resize_inode - это пространство, заранее выделенное для случая, когда вы, возможно, захотите изменить размер файловой системы в будущем. В основном используется для пытаться чтобы предотвратить необходимость физического перемещения таблицы inode.
В resize_inode занимает немного места и позволяет более плавно и быстро изменять размер файловой системы, и flex_bg снимает ограничения на количество inode (количество файлов / каталогов) и повышает производительность.
Печально то, что mkfs, вероятно, не был достаточно мощным, чтобы иметь возможность изменить эту функцию в файловой системе к моменту публикации вопроса, и может по-прежнему испытывать проблемы с некоторыми функциями. Но изменив те не должна повредить вашу файловую систему, пока она здорова. Так всегда бегать fsck -f /dev/SD... прежде чем пытаться изменить такие функции, и тогда все готово.