LINUX.ORG.RU
Форум — Talks  

XFS vs EXT4 на разделе в ~ 5000GB под CentOS 6.4/RHEL 6.4 x86-64

 , , hugefs, ,


0

1

Кто-нибудь активно использовал XFS на разделах подобного размера?

Под активностью подразумевается создание файлов от 100KB до 100MB в количестве до 100 тысяч в сутки, а то и больше.

Файлы могут иногда удаляться.

У меня лично на CentOS 5.x на XFS один раз бесследно исчезла директория с несколькими файлами и подкаталогами размером в 100GB - до сих пор страшно боюсь её использовать (mtime директории уровнем выше был неизменным, доступ был только у меня, т.е. unlink произошёл из-за ошибки FS, а не из-за ручного удаления - разработчик XFS по SSH зашёл на машину, поковырялся и сказал, что необъяснимые вещи происходят).

★★★★★

был бы не ты, ярый ненавистник линукса, можно было бы обсудить.

sdio ★★★★★
()

У меня XFS сыпалась и на более простых юзкейсах (сидбокс).

pekmop1024 ★★★★★
()

xfs — не продакшен fs. Я её тестами убивал что на lucid что на precise. Под линухом единственная рабочая fs это ext4.

Reset ★★★★★
()

Несколько лет на зад года 3 использовал resierfs на помойке 5ТБ, типично забитой под завязку, с активной движухой разножирных файлов. Сбои бывали по внешним причинам и всегда решались fsck. Возможно, просто везение, но эту фс много где любил использовать. Правда, по последним данным, недавно тот сервак физически издох контроллером рейда, дальнейшую судьбу пока не знаю.
А с ext4 и xfs как-то проблемы бывали на ровном месте.

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

2) zfs
1) нормальный дистр

огласите весь список пожалуйста.

onon ★★★
()
Ответ на: комментарий от Reset 
# df -h -F xfs
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg004-lvol1 907G  610G  297G  68% /sasdata
/dev/mapper/vg007-lvol1 302G  171G  132G  57% /sigdata/sigarc
/dev/mapper/vg008-lvol1 403G  302G  101G  75% /sigdata/sigdata
/dev/mapper/vg002-lvol1 101G  8.3G   93G   9% /sas
/dev/mapper/vg003-lvol1 504G  316G  188G  63% /saswork
/dev/mapper/vg001-lvol1 856G  627G  230G  74% /sashome
/dev/mapper/vgsig4_clone-lvol0 202G   78G  124G  39% /clone_sigdata4
/dev/mapper/vgsig4_2-lvol0     202G   86G  116G  43% /sigdata/sigdata4
/dev/mapper/vgsig1_1-lvol0     504G  171G  333G  34% /sigdata/sigdata1

RHEL6.x, 128G RAM, 2 года активной нагрузки.
сейчас: load average: 29.13, 29.00, 29.00

проблем с фс нет

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

Я не говорил, что без перезагрузок. Имею в виду, что актуальность ядра поддерживаю самостоятельно.

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

Сидбокс (чтение, редкая запись), аудио-/видеонаблюдение (запись, редкое чтение), музыка/фильмы/журналы (чтение)

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

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

YAR ★★★★★
()

Ну согласитесь, рейзер* - очень гуд фс, несмотря на судьбу, собственно, Рейзера, из-за русской золушки. В reiser4, хоть многое еще и нереализовано, но оно круче таких поделок, типа ext4 или монструозного zfs, но в любом случае стабильнее. А reiser3 - для многих вещей не перестанет работать хуже.

madcore ★★★★★
()

Статистики наработанной годами пока нет. Месяцев 6 под RHEL эксплуатировал раздел 12Тб на XFS с довольно интенсивным I/O. Всё нормально.http://goo.gl/fbcsWc по оси Y - IOPS.

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

Под линухом единственная рабочая fs это ext4.

С которой иногда упорно после перезагрузки файлы перемещаются на Неназываемый раздел а ext3, ntfs и fat там просто работают.

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

рейзер* - очень гуд фс

Было много проблем из-за удаления BigKernelLock. Неизвестно, все ли они устранены. Грязный код. Нет online-дефрагментации. Нет быстрого способа оценить степень фрагментации.

reiser4

Недостаточно пользователей. Опять-таки, многолетний баг с нарушением сортировки дерева на сжатых ФС. Жуткая фрагментация метаданных из-за CoW при частых записях-стираниях. Онлайн-репакера всё ещё нет.

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от TuxR

Хотя вспомнил, была проблема, но там больше lvm был виноват. Была задача без даунтайма переехать на другой сторадж большего объема. Подцепили в lvm, как зеркало. При синхронизации зеркала xfs отвалилось. То есть ls /директория говорил то ли io error, то ли access denied, не помню уже. К счастью, возможность дождаться ресинка была. После перезагрузки и fsck - критических ошибок не обнаружилось. Старую половину зеркала из lvm удалили, раздел и фс расширили на полный объем. Где то на редхате баг описан аж с 2007 года. На zfs, svm или веритасе такой фокус работает, а на lvm+xfs нет.

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

reiser3 лучшая фс

У меня (и еще у некоторых людей) есть проблема с ней. Время от времени фс «лочится», на нее нельзя писать и читать с нее. Систему приходится ресетить. Эта ошибка пару раз обсуждалась на данном форуме. Проявляется не у всех и довольно редко, но мне как человеку у которого проявляется от этого не легче. Некоторым помогает опция notail и дефрагментация, мне не помогло.

С такой проблемой как то не тянет она на звание лучшей фс.

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

ext4 тоже не претендует на лучшую фс

А где я такое говорил?

и вот «21.09.2012»

Больше пол года прошло уже, с тех пор много че фиксили.

Behem0th ★★★★★
()

Я использовал на нескольких машинах. Общий размер разделов был около 15-20Т. Было это во времена RHEL4-5. Чудеса наблюдались. В частности xfs тех времен крайне плохо реагировали на отключение света и оно однажды таки случилось - пришлось БД из бэкапа разворачивать. Точнее один dbf, который протерялся.

С тех пор под БД использую ext2, под все остальное ext3. С ext4 недавно были проблемы, но связанные с производительностью, а не стабильностью (баг какой-то в RHEL 6.1), поэтому пока в матерый продашен мы его стараемся не пускать.

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