Мой вопрос касается производительности файловой системы томов EXT4 относительно размера. У нас есть NAS под управлением любой произвольной платформы Linux. NAS имеет (12) дисков по 4 ТБ в аппаратном массиве RAID 6 с LVM, что дает примерно 40 ТБ доступного хранилища. NAS - это файловый сервер (netatalk и samba). Когда хранилище исчерпается, мы подключим пассивные блоки расширения SAS.
Мои вопросы:
Параноик во мне, истерзанный годами опыта и не доверяющий недавним улучшениям, не нравится идея единого большого тома EXT4 для того, что звучит как неструктурированное обслуживание файлов. EXT4, вероятно, достаточно хорош для этой задачи в последних ядрах, но он по-прежнему пахнет файловой системой EXT. Режимы отказа с ними нехорошие и ... я им не доверяю.
Годами я бы пошел на xfs если это вообще возможно, поскольку он разработан для огромного масштаба, а недавние улучшения устранили множество проблем с производительностью inode, которыми он был известен в прошлом (очевидно, я доверяю улучшениям в файловых системах, которые мне нравятся). И он не fsck, и даже не утверждает, что это нужно. Что приятно, поскольку для поиска тома EXT4 40 ТБ потребуется очень долгое время, и это время, которое засчитывается в счет бюджета времени простоя.
zfs или btrfs тем не менее, путь в будущее. Поддержка в ядрах пока не полностью предприимчива (или лицензирована), хотя btrfs действительно близок к тому, чтобы заслужить эту награду. Если вы готовы иметь дело с, возможно, еще не пуленепробиваемой новизной, пуленепробиваемость должна появиться в будущих обновлениях ядра, и вам не придется иметь дело с изменением вашей файловой системы. Кроме того, к ним не совсем подходит концепция «нескольких томов», поскольку сама FS создает подтома.
Оптимальные размеры объема
Для «неструктурированного обслуживания файлов» ваш коэффициент масштабирования, вероятно, будет зависеть от размера ваших каталогов. Когда-то давно 64К файлов / подкаталогов в каталоге были очень плохими для файловых систем EXT, но это было исправлено. В то же время количество inodes в системе могло вызвать большие проблемы с масштабированием (8 миллионов файлов, не так хорошо работали в некоторых файловых системах).
Большинство из них уже спроектировано. Даже ext4, который мне не особо нравится, может работать с десятками миллионов файлов. Это будет быстро? Эх, зависит от того, что вы экономите.
Рекомендации по резервному копированию / восстановлению
То, о чем никто не думает. Что вы для этого делаете? Вы полагаетесь только на снимки LVM и RAID, как-то экспортируете полные копии (tar на ленту) или выполняете периодическую синхронизацию с удаленной системой через rsync или что-то в этом роде? То, что вы делаете, повлияет на выбор вашей файловой системы.
XFS предоставляет вам xfsdump, который является очень хорошей утилитой для резервного копирования файловых систем XFS. Это лучше и быстрее, чем tar поскольку он хранит fs-структуры напрямую в архиве, где tar должен создавать абстракции posix, которые замедляют его.
На магнитных носителях файловые системы на основе экстентов лучше справляются с резервным копированием, поскольку они лучше избегают фрагментации. Xfsdump позволяет обойти некоторые проблемы с фрагментами благодаря встроенным инструментам. Как правило, производительность inode будет проблемой для стилей резервного копирования, ориентированных на все файлы (tar и rsync).