> www.phoronix.com
Нет, спасибо.

Версия для Ъ.

When the system was back up, to much surprise and disappointment, all of the test results were gone. However, it was just not the test results file that was being read to and written from, but all of the test results and files contained within the active directory (~/.phoronix-test-suite/test-results/ati/). From the Phoronix Test Suite XML files to all of the test logs and system logs were no longer present that were found within a sub-directory. Many of these files were not even read from or written to on the most recent mount of the EXT4 file-system.

POSIX такой POSIX.

92% что там была угбунта

Как говорят на одном доставляющем сайте, «and the Real WTF is...»

Цитирую:
The Phoronix Test Suite even keeps backup copies of the XML test results from previous runs in a separate file to fend off data loss problems like that, but alas they were stored in the same directory.

(Phoronix Test Suite даже бэкапит XML с результатами тестов из предыдущих прогонов в отдельном файле, чтобы защититься от потерь данных подобного рода, но к сожалению, они хранились в той же самой директории.)

Это капец, товарищи. Они бы еще абзацы документа бэкапили в том же документе, бэкаперы хреновы.

Дело не в криворукости ворониксов, а в том, что потерялась целая директория. Вместе с файлами, которые на протяжении последнего монтирования не только не модифицировались, но даже и не считывались.

> Дело не в криворукости ворониксов

Да, но не будь они криворукими, не потеряли бы данные.

Основной принцип бэкапирования в том, что бэкапы должны храниться в другом месте, чем основные данные. Желательно на другом носителе, в другой железяке, в идеале — в другом помещении, и вообще в другом здании, радиус подбирается по стоимости восстановления, если «все наююкается».

Я это уяснил как-то на практике, когда еще юнцом прыщавым был.

> Желательно на другом носителе, в другой железяке, в идеале — в другом помещении, и вообще в другом здании

Это само собой. Но топик-то про надежность ext4, а не про ворониксов.

Вот поэтому, наверное, Red Hat и Novell не спешат внедрять сервера и файловые хранилища с Ext4, а полагаются исключительно на Ъ-ФС Ext3.

Да, тормозно и фрагментированно, но зато надёжно. Пусть толпы любителей тестируют на себе сырые поделки.

Следующий вброс: Oracle отказывается от разработок Btrfs и переводит Анбрикабл Linux на ZFSv22. :))

> Это само собой. Но топик-то про надежность ext4, а не про ворониксов.

Я знаю, но не могу не обратить внимание, если еще и они сами облажались.
У меня несколько компьютеров не потому, что десять рук, а потому, что данные, которые меня кормят, лежат на каждом + еще где-то в сети, чисто на всякий случай. Это при том, что ext3 и HFS+, обеим из которых хоть кол на голове теши.

> Следующий вброс: Oracle отказывается от разработок Btrfs и переводит Анбрикабл Linux на ZFSv22. :))

да чего уж мелочится - сразу переходит на FreeBSD

Эта ваша ext4 - сырая поделка.

>полагаются исключительно на Ъ-ФС Ext3.

Ну хз у менся в на зюзе 11.1 постоянно падала Ext3 а с Ext4 все зашибись. Хотя я подозреваю что в обновлениях 27 ядра сломали драввер Nforce

>Это капец, товарищи. Они бы еще абзацы документа бэкапили в том же документе, бэкаперы хреновы.

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

> Ну так это не бекап любимой и лелеемой базы данных, а сохранение промежуточных результатов

Учитывая, что собираются промежуточные результаты долго и кропотливо — я бы бекапил. Это же долго, и мне плотют не за то, что я вынужден повторно их собирать.

Ъ-ФС Ext3

iZEN

Что случилось?

Массовый падеж крупного рогатого скота на просторах африканских саван, не иначе

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

>Ну хз у менся в на зюзе 11.1 постоянно падала Ext3 а с Ext4 все зашибись. Хотя я подозреваю что в обновлениях 27 ядра сломали драввер Nforce

судя по топику в desktop она падала совершенно не поэтому

у меня на nforce все работало в 11.1 до нового года, потом я перешел на AMD и все продолжает работать в 11.2

PS совершенно случайно форматнул 6Гб файлопомойку в ext3, хотя собирался сделать ext4, видимо не зря

6ТБ //самопочин

>Следующий вброс: Oracle отказывается от разработок Btrfs и переводит Анбрикабл Linux на ZFSv22. :))

Ну если я правильно понимаю, то это означало бы, что ZFS перелицензирована под чтото гнутое, а значит у фряхи вырывают последний несгнивший зубик. Или не?

Я англицкого не знаю. Что у них там случилось? Завис какой-то тест, они не смогли перетыкнуться на другой виртуальный терминал чтобы снять процесс, им пришлось ребутнуть комп. После чего слетели файлы в какой-то директории (фалы видимо были открыты на редактирование). Так чтоли?


"... Результаты испытаний были утрачены. Единственный раз, когда это имело место ранее было обусловлено отказа диска диска, но на сей раз это благодаря EXT4 в ядро Linux 2.6.32. Первоначально EXT4 файловая система была приятно эволюционного обновления на ext3 (и дополнительные решения, пока Btrfs была готова), которые представили некоторые основные повышает производительность. Хотя, как принятие EXT4 увеличивать, было обнаружено, что файловая система не всегда была надежной, но данные потери были несколько общих. Это происходит из-за задержки с распределением данные не записаны на диск, прежде чем система пошли вниз или разбился, но из-за дизайна EXT4 'Being коснулся файла будет оставлено пустым, а не проведение оригинального содержимого файла.

В ядре-релизы с EXT4 проблемы потери данных были широко отметила, улучшение EXT4 были сделаны, чтобы улучшить целостность файловой системы и делает ее более безопасной для общего использования рабочего стола. Эти улучшения лучше сохранить данные пришли на большие расходы производительность в некоторых тестах и скорость EXT4 продолжает ухудшаться даже при EXT4 в ядро Linux 2.6.32 теряет скорость. Однако, по крайней мере по умолчанию параметры монтирования, EXT4 файловая система еще не всегда надежны.

При тестировании из Radeon HD 2400PRO на Linux его взаперти с ioquake3 питанием мир игры Padman, которое было пронизано Phoronix Test Suite. Все видеокарты тестирование до получения на HD 2400PRO бежал хорошо, но система взаперти и не смогли перейти на виртуальный терминал и не делать ничего, кроме перезагрузки системы."

>Вот поэтому, наверное, Red Hat и Novell не спешат внедрять сервера и файловые хранилища с Ext4, а полагаются исключительно на Ъ-ФС Ext3.

До определеенных событий у suse было reiserfs дефолтно.

> (фалы видимо были открыты на редактирование). Так чтоли?

Нет. Исчезли файлы, к которым за последнее монтирование вообще никак не притрагивались.

> Ну если я правильно понимаю, то это означало бы, что ZFS перелицензирована под чтото гнутое, а значит у фряхи вырывают последний несгнивший зубик. Или не?

Код ZFSv14 под CDDL уже в ядре FreeBSD. Перелицензирование обратной силы не имеет — все выпущенные продукты невозможно перелицензировать, можно поставить новое клеймо только на новый продукт. Так-то.

>Код ZFSv14 под CDDL уже в ядре FreeBSD. Перелицензирование обратной силы не имеет — все выпущенные продукты невозможно перелицензировать, можно поставить новое клеймо только на новый продукт. Так-то.

и что? Зато теперь нет еще одного повода(последнего?) ставить фряху,нет?

> и что? Зато теперь нет еще одного повода(последнего?) ставить фряху,нет?

UFS2 лучше, чем Ext4. По крайней мере не была замечена в выбрасывании вот в таких вот финтов ушами.

>UFS2 лучше, чем Ext4. По крайней мере не была замечена в выбрасывании вот в таких вот финтов ушами.

+1

А вот интересно почему в линуксе фс много, а выбор всё равно второсортный?

>> и что? Зато теперь нет еще одного повода(последнего?) ставить фряху,нет?

UFS2 лучше, чем Ext4.

Чем лучше?

>Ну если я правильно понимаю, то это означало бы, что ZFS перелицензирована под чтото гнутое, а значит у фряхи вырывают последний несгнивший зубик. Или не?

Надеятся то не грех. Оракл не будет закапывать солярис, перелицензируя ZFS на линукс под GPL-like лицензии. В лучшем случае сделают блоб под свой дистрибутив.

>Чем лучше?

Тем что не теряет файлы?!

ext4 нет в продакшене

а гугель что задумал?

нууу, вобще то вброс от изена, чего тут ко мне то?)))))

>UFS2 лучше, чем Ext4. По крайней мере не была замечена в выбрасывании вот в таких вот финтов ушами.

Вопрос интересный. Надо бы поизучать

When testing out the Radeon HD 2400PRO on Linux it locked up with the ioquake3-powered World of Padman game, which was being run through the Phoronix Test Suite.

Я совсем не уверен, что их fail имеет отношение к ext4, пусть повторят и без своего глюкавого Phoronix Test Suite.

>а гугель что задумал?

Что-то своеобразное и нецелевое, им вроде даже журнал не нужен.

>UFS2 лучше, чем Ext4. По крайней мере не была замечена в выбрасывании вот в таких вот финтов ушами.

UFS2 надо сравнивать с ext2.

>> UFS2 лучше, чем Ext4.

Чем лучше?

Хотя бы тем, что для обеспечения надёжности UFS2 даже журнал не нужен — семантика CoW обеспечивается «мягкими» обновлениями aka Soft Updates. А наличие журналирования gjournal(8) позволяет отказаться от продолжительного background_fsck при некорректном отмонтировании/сбое питания. (background_fsck проводится для очистки свободного пространства ФС от недозаписанных файлов, которые и так потеряны)

На какой линуксовой ФС уже смонтированной можно пускать fsck без ловли глюков? Ась?

> и переводит Анбрикабл Linux на ZFSv22.

через FUSE? OFMG O_O

>>Чем лучше?

Тем что не теряет файлы?!

А кто сказал, что нет? То что ты об этом не знаешь, еще не значит, что не теряет.

>На какой линуксовой ФС уже смонтированной можно пускать fsck без ловли глюков? Ась?

на любой.

mount -o remount,ro

Хотя бы тем, что для обеспечения надёжности UFS2 даже журнал не нужен — семантика CoW обеспечивается «мягкими» обновлениями aka Soft Updates. А наличие журналирования gjournal(8) позволяет отказаться от продолжительного background_fsck при некорректном отмонтировании/сбое питания. (background_fsck проводится для очистки свободного пространства ФС от недозаписанных файлов, которые и так потеряны)

А при чем тут к ext4 background fsck? Это проблемы твоей UFS2.

> UFS2 надо сравнивать с ext2.

Давай вместе.

0. Реальный максимальный размер тома
Ext2 — 2ТБ (при 4kb блоке)
UFS2 — 1ТБ (при 16kb блоке)

1. Журналирование
Ext2 — Нет
UFS2 — Нет

2. Отказоустойчивость
Ext2 — Нет, суперблок в первых нескольких группах блоков, таблица дескрипторов групп в нулевой группе блоков — вылет фатален.
UFS2 — Soft Updates, суперблок в каждой группе цилиндров, группы цилиндров автономны.

3. Снимки
Ext2 — Нет
UFS2 — Да

4. Квоты
Ext2 — Нет
UFS2 — Да

5. Расширенные атрибуты и ACL
Ext2 — Нет, но возможны с применением патчей.
UFS2 — Да

6. Задействование фрагментов блоков
Ext2 — Нет
UFS2 — Да

7. Переменный размер блока
Ext2 — Нет
UFS2 — Да

8. Индексирование каталога для быстрого доступа
Ext2 — Нет
UFS2 — Да, хэширование элементов каталога в памяти при первом обращении.

9. Фоновая проверка смонтированной ФС
Ext2 — Нет
UFS2 — Да

10. Дата разработки
Ext2 — 1993г
UFS2 — 2002г

>> На какой линуксовой ФС уже смонтированной можно пускать fsck без ловли глюков? Ась?

на любой.

mount -o remount,ro

Ты слил.

>>> На какой линуксовой ФС уже смонтированной можно пускать fsck без ловли глюков? Ась?

на любой.

mount -o remount,ro

Ты слил.

Бугагец. Если нечего ответить, то оппонент слил?

Ещё раз

На какой линуксовой ФС, смонтированной в RW, можно пускать fsck без ловли глюков? Ась?

А если теперь сравнить с ext3, то после пункта 1 можно дальше и не продолжать.

>На какой линуксовой ФС, смонтированной в RW, можно пускать fsck без ловли глюков? Ась?

на любой. fsck -n

>На какой линуксовой ФС, смонтированной в RW, можно пускать fsck без ловли глюков? Ась?

А смысл? У нас или повреждена fs и ей требуется восстановление, или не повреждена и тогда fsck не нужен. Проводить какие-то действия с повреждённой ФС до её полной проверки --- это искать оригинальные проблемы себе на мягкое место.

>>На какой линуксовой ФС, смонтированной в RW, можно пускать fsck без ловли глюков? Ась?

А смысл? У нас или повреждена fs и ей требуется восстановление, или не повреждена и тогда fsck не нужен. Проводить какие-то действия с повреждённой ФС до её полной проверки --- это искать оригинальные проблемы себе на мягкое место.

Блин. Ты раскрыл карты, я хотел Изю затроллить.

>>А смысл? У нас или повреждена fs и ей требуется восстановление, или не повреждена и тогда fsck не нужен. Проводить какие-то действия с повреждённой ФС до её полной проверки --- это искать оригинальные проблемы себе на мягкое место.

Даже больше. Повреждена ли она или нет можно в любом случае посмотреть. И если повреждена, то просто отложить проверку до удобного момента, а если нет, то и хорошо. в UFS2 background_fsck не поможет в тех случаях, когда исправления критически, все равно отвонтировать надо. И чем раньше - тем лучше. Так что пофигу.