Без. 6 ТБ, 8ГБ рам

Но у меня ещё zfs не OpenZFS

У меня zfsonlinux

Иллюмос тоже

Это его предок, насколько помню

Как говорится - до первого краха системы, когда у ext4 метаданные криво зайдут и надо будет откатывать транзакции у "блочного устройства"

Что-то после полуторочасового цикла "запуск ВМ -> ждем 2 минуты -> роняем ВМ" я устал ждать этого первого раза. Первые пару десятков запусков я пытался заниматься какой-то деятельностью, по типу открывать crm с битрикс, делать бекап БД, обновлять пакеты с yum, гнать тест на запись в fio. Потом мне надоело, решил жестче действовать - 10 раз дергал сервер из розетки. Когда использовал на хосте ext4 + запись в fio, то такое гарантированно ломало ФС уже на 3-4 раз. Понимаю, что дело случае может быть, стоило бы потестить дольше, но сервер загружается несколько минут и просто устал ждать.

Тем не менее, положить ext4 у меня всегда получалось. Я так и узнал об ZFS, когда искал надежную ФС

Тем не менее, положить ext4 у меня всегда получалось. Я так и узнал об ZFS, когда искал надежную ФС

Конечно) А ZFS тоже тестили перед релизо 2.2.0, и по разному Но как-то у одного человека всё было ок

положить ехт4 с журналом?

Да, до состояния, когда просит fsck и не хочет грузиться дальше

ну очевидно что конкретные юзкейсы с дырявыми файлами не тестили вот и налетели, тем более что ошибка была долго там. теперь (надеюсь) будут тестить

А как там у ext4 со временем работы fsck на 20-30Т? сколько времени оно займет?

на железе или поверх zfs?

Это скорее в тему - Решения, которые 100% работают и не дают сбоя у одного человека != так будет у всех

Не знаю, я только 10Тб так храню

Это скорее в тему - Решения, которые 100% работают и не дают сбоя у одного человека != так будет у всех

ну ок, сколько занимает на 10?

На ARM с частотой 2.4 - ну около, минут 15-20 может если навскидку

4 часа на 4Тб диске)

ну это уж какой-то крайний случай, наверное, диск медленный =)

стандартные 200+ Мб/с при линейном чтении TOSHIBA MG04ACA4

У меня просто R5 на SBC из 10 дисков без закрытого write hole (mdadm), подключённые через type-c PD (чтобы запитать 4 SSD от одного power bank) - иногда 4 диска отваливаются разом, и соответственно рейд откатывается по транзакциям на пару итераций назад и приходится fsck делать

Сколько данных на диске?

Печаль. Я помню, лет 10 назад мы встревали с ext4, но думал, что-то исправили уже. Походу нет. ну и ладно, я xfs предпочитаю, если не zfs :)

7ТБ примерно

положить ехт4 с журналом?

7ТБ примерно

дык журнал не гарантирует сохранность. Не просто так cow выбран в zfs , хоть и платить за него приходится :)

Может что-то улучшили в ext4🤷‍♂️ А что за диски?

дык журнал не гарантирует сохранность. Не просто так cow выбран в zfs , хоть и платить за него приходится :)

evo 860

Так это же SSD, а не HDD.

cow это просто другой метод гарантирования, к тому же между флашами дерева в зфс оно полагается на журнал

это не xfs

больше 100 серваков на xfs уже лет 10. Брат жив :)

ну вот это "просто" оно решающее - т.к никогда данные не перезвписываются поверх

ИМХО - соболезную

какая разница-то. если в ехт4 включить журналирование данных она тоже будет гарантировать что после синка все ок. а зфс без синка тоже ничего не гарантирует, откатится на 10 гигабайт назад и не поморщится

Я лишь сказал, что ext4 не так просто убить и fsck вполне работающая утилита

с zfs 2.1.x тоже не было проблем пока не втащили клонинг на 2.2.х

Это абсолютно не так. Я работал в фирме, которая занималась обслуживанием рабочих мест кассиров (РМК). Точное количество не скажу, но тысяч 10 машин было. Мы ставили ОС, софт, настраивали, удаленно могли подключаться для диагностики, если ОС и интернет работают. Специфика РМК в том, что там электричество нестабильно подается. То перегрузят холодильниками и рубильник вырубит, то кассиры не знаю, что комп нужно выключить в конце рабочего дня, а не тот же рубильник рубануть. Сложно вспомнить день, когда не приходилось по телефону диктовать как запустить fsck. И стабильно привозили в офис ПК, которым fsck не помог. Проверяешь диск - всё ок. Переустанавливаешь, работает дальше

ИМХО #2 Вот там треш с восстановлением, утилита на больших данных начинает жрать оперативную память как не в себя, а ещё попутно может и сказать Can't Recovery и всё, данные прощайте. Утилит для восстановления данных (тот же testdisk) очень спорно работают с XFS, ну и конечно же Нельзя уменьшить раздел

Про "уменьшить раздел" - я прям ждал =)))

а где можно?

Про "уменьшить раздел" - я прям ждал =)))

Это так ужасно: нельзя уменьшить раздел. Как я живу без этого =))

ext4))))

ну ваще иногда желательно уменьшать раздел, облегчает страдания )

ну и ZFS в каком-то смысле

а как именно фск не помогал? журналирование в фс включено было?

а где можно?

ext4 был с настройками по умолчанию, ничего не меняли. ОС были debian 7-10, ubuntu 14-20

почти везде меньше половины ФС не позволяют уменьшать раздел

ну только с метадатой в журнале наверное. а что ломалось в файлах?

(Сломанная мета убьёт любую ФС)