Обнаружены проблемы, приводящие к потере данных на разделах с ext4

>> А PackageKit - что ещё такое?

>дополнительная прослойка между пакетным менеджером и DE

Которая за этот год у меня трижды зависла, а после sigkill'а портила базу рпм.

>Опа, вот это уже плохо, я вовсю юзаю ext4 :((

Сколько уже твердили - сам создатель ext4 Ted Ts'o заявил что сейчас идет АЛЬФА-тестирование Ext4, предварительный релиз будет только в 2010 году, а полная полная стабилизация в 2011-2012.

http://www.gnuplanet.ru/main/topic.php?topic_id=2502

>От себя могу добавить что в федоре на редкость ублюдочный инсталлятор, который даже при минимальной установке притащил мне гтк, куте, нетворк-менеджер, альсу и блютус

Многие избыточные зависимости тащит метапакет rh-lsb. По LSB gtk и Qt должны быть, например.

>вы опять таки нагло врете

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

>Патрик как раз и добновляет версии пакетов когда они 99,9% рабочие. да еще нет зависимостей которые можно поломать, а да я ж забыл что эти зависимсти офиГенный козырь

стабильность системы и пакетов достигается тщательным тестированием и использованием наиболее оптимальных версий (иногда более старых), в том числе и патченных, в том числе и бэкпортированием в старое ядро исправлений кода из более новых версий. в слаке пакеты именно что рабочие (тоесть могут в принципе и запуститься).

чушь про зависимости прочитать не мог.

>>> А PackageKit - что ещё такое?

>> дополнительная прослойка между пакетным менеджером и DE

> Которая за этот год у меня трижды зависла, а после sigkill'а портила базу рпм.

Сдается мне, что кто-то гонит. PackageKit работает поверх rpm и никак не может сам испортить базу rpm. Свои настройки может, но это совсем не критично.

> PackageKit работает поверх rpm и никак не может сам испортить базу rpm.

Через librpm. Так что всё он может.

А я таки уже раз пять у себя эту ошибку обнаруживал. Заново некоторые конфиги настраивал. Только молчал, не умею я багрепорты писать ^_^

Archlinux x86_64, 2.6.28.7

>PackageKit работает поверх rpm и никак не может сам испортить базу rpm.

а rm /var/lib/rpm/__db.00*; rpm --rebuilddb я от скуки делал, да?

> например? Мне просто интересно

Dalton (quantum chemistry) на бубунте собирается только в serial-варианте. Параллельная версия требует напильника при сборке и валится при запуске. На федорке -- собирается без единого чиха. И работает в отличие от.

> Сколько уже твердили - сам создатель ext4 Ted Ts'o заявил что сейчас идет АЛЬФА-тестирование Ext4, предварительный релиз будет только в 2010 году, а полная полная стабилизация в 2011-2012.

что за бред? кто сказал что файловую систему не нужно улучшать и дорабатывать? http://ext4.wiki.kernel.org/index.php/Main_Page ещё скажи что ntfs как была стабильна и работала без багов после выхода релиза Win'XP так и умерла с SP3. Не бывает ничего идеального, тем более что ИИ в компьютеры ещё даже и не пытались толком встраивать.

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

Это я к тому что армия хомячков-бета тестеров для тестирования таких вещей как ФС - вещь довольно бесполезная.

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

поучаствовать в тестировании сознательно и "вовсю юзать" - две большие разницы ящитаю. специально обуч^W^Wзабэкапленные данные еще никто не отменял

>Проще тогда убрать журналирование полностью

По ссылке не ходим, матчасть не учим? Журналирование метаданных обеспечивает исправность ФС после сбоя и только. А журналирование данных тормозит и его почти никто не включает.

> Это я к тому что армия хомячков-бета тестеров для тестирования таких вещей как ФС - вещь довольно бесполезная.

Ну чего же крутые команды тестеров Редхата не нашли эту ошибку?

> I recently upgraded to ext4 as well, I ran a game in Wine and the system hardlocked

атас! идиоты играют виндовые игры в linux под wine... да этот wine даже запустить шифрованный iptv без зависаний процесса не умеет... а вы ему игру суёте...

Ну собственно я это знал :)) так как много тестировал ext4 и она убивала данные гарантированно.
Проверка такова - пару раз emerge --sync и она умирает.
Трабла с созданием кучи мелких файлов... но я думал разрабы знают а оказывается это новость ха....

Хы, а у меня на ноуте как раз ext4, правда только на корне, хомяк на ext3 традиционно (=
NM это фича нужная для ноутов, на компе у меня вся сеть ручками поднята, а вот на ноуте wicd юзаю.

> > дистрибутиве Ubuntu 9.04 встречается ошибка файловой система ext4, приводящая к потере данных

> тем кому нужна стабильность сидят на убунте

Ты к весне потолстел.

>>Проверка такова - пару раз emerge --sync и она умирает.
эээ щито? Сколько раз не делал emerge --sync ничо не случалось вродь

> поучаствовать в тестировании сознательно и "вовсю юзать" - две большие разницы ящитаю. специально обуч^W^Wзабэкапленные данные еще никто не отменял

M$ при каждом новом выходе в продажу своих французких булок^W^Wпродуктов вовсю использует покупателей-активных пользователей как бетатестеров, хотя фактически они все счиитаются пользователями оф.релизов. Почему нельзя использовать такой подход и на линуксоидах??? Не нравится - сиди в old stable.

Вот интересно, почему на моей памяти критичных ошибок в ReiserFS не было а в ext2/3/4 это уже третья за пару лет?

> после прелестей 9й федоры ниразу не было желания даже пробовать 10. и таки да, это было сооовсем недавно.

9-кой пользоватся просто невозможно было (после установки почти сразу откатился на 8-ку), а вот 10-ка ... совсем другая разница ;)

>Башизмы при #!/bin/sh? Авторов таких скриптов, возможно, лучше мочить в сортире.

+1

>> PackageKit работает поверх rpm и никак не может сам испортить базу rpm.

> Через librpm. Так что всё он может.

И что? У librpm кривой интерфейс, который позволяет убить базу? Возможно, но странно.

Я с ним игрался, когда он был совсем сырой. Валился на раз два. Зависал. Выжирал всю память. Но ни разу базу не убил. Только свои настройки.

Недавно смотрел. Добиться неработоспособности от него не получилось, а уж про базу и говорить не стоит.

>что за бред?

Это не бред а оценка состояния разработки самим создателем. Сейчас он оценивает состояние EXT4 как АЛЬФА ВЕРСИЮ, соответственно и плакать не надо если данные потеряете. Хотите быть альфатестером - ставьте, не хотите ждите 2011-2012 года.

>А журналирование данных тормозит и его почти никто не включает.

Неособо кстати и тормозит - юзаю на нескольких машинах субъективно вполне нормально.

>>> PackageKit работает поверх rpm и никак не может сам испортить базу rpm.

>> Через librpm. Так что всё он может.

> И что? У librpm кривой интерфейс, который позволяет убить базу?

Не в кривизне интерфейса дело. Программа, использующая БД RPM через библиотеку, by design может ее поломать (упав в неподходящий момент, например).

>От себя могу добавить что в федоре на редкость ублюдочный инсталлятор, который даже при минимальной установке притащил мне гтк, куте, нетворк-менеджер, альсу и блютус, плюс не менее дебильные зависимости у rpm пакетов

groupinstall core из кикстатрта или в чрут и меньше некуда, из анаконды же минимум это groupinstall base

> Это не бред а оценка состояния разработки самим создателем. Сейчас он оценивает состояние EXT4 как АЛЬФА ВЕРСИЮ

Там речь вообще об BTRFS. "Поздравляем вас, гражданин, соврамши" (c)

Было. До 2.4.12 reiserfs уносило данные только так. Поройся в логах сусешных ядер, они тогда поддерживали reiserfs.

>Уберите эту фигню из заголовка, по ссылке Theodore Ts'o объясняет, что поведение файловой системы полностью корректно.

+1024

Серьёзно. проблема не в ext4 а в чьих-то кривых руках. поведение fs корректно и объясняется использованием delayed allocation. Проблема не специфична ни для убунту что значится в тегах (там в числе первых 5 каментов гентушник отписался) ни для ext4, что значится в заголовке(уже писали что то же может случиться в xfs и любой другой fs использующей da). К тому же никакой ошибки по сути нет. Есть некорректное поведение некоторых программ(и людей), ожидающих что файл который они потранкали и записали тут же окажется на диске. Патчи предотвращающие всю эту дребедень уже написаны Theodore Ts'o и в 30 ядро будут замержены.

> PackageKit&NtworkManager&HAL делают десктопный Linux намного удобней.

Ровно до новой версии Xorg 7.4. ;)

> PackageKit - что ещё такое?

Имелся в виду PolicyKit, наверное. Это изобретение Федоровцев.

ИМХО, но ещё мало кто юзает ext4 на Ubuntu

> Серьёзно. проблема не в ext4 а в чьих-то кривых руках. поведение fs корректно и объясняется использованием delayed allocation.

Проблема в кривых руках разрабов ext4, которые изменили поведение ext3, на которое программы уже полагаются.

/me ниразу не уверен что рхел заботит ext4. подозреваю что до выхода бетты они даже не пошевелятся по этому поводу

> встречается ошибка файловой система ext4, приводящая к потере данных.

Ни разу не сталкивался с подобным на UFS2, с которой "списали" механизм Soft-Updates в Ext4.

Ну, главное нашли ошибку

>Было. До 2.4.12 reiserfs уносило данные только так

Преданья старины глубокой. А в ext ошибки находят и сейчас

> с которой "списали" механизм Soft-Updates в Ext4.

Зен, ты завязывай с анашой. Совсем во времени заплутался.

> Преданья старины глубокой. А в ext ошибки находят и сейчас

Так все пользоваться перестали рейзером. Вот и замер он точке замерзания. Кстати, в рейзере починили феерический баг с образом reiserfs в файле и reiserfsck?

>Проблема в кривых руках разрабов ext4, которые изменили поведение ext3, на которое программы уже полагаются.

тем что увеличили дефолтное время синхронизации файлов с 5 секунд до минуты-двух? Или тем что что используют delayed allocation?

В конце концов никого не заставляют переходить на ext4, если люди довольны производительностью ext3. =)

>Ну чего же крутые команды тестеров Редхата не нашли эту ошибку?

В Release Notes к Red Hat Enterprise 5 ext4 упоминается как Technology Preview, видимо тестеры не подписались под ext4.

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Release_Note...

Цитата:

Technology Preview features are currently not supported under Red Hat Enterprise Linux subscription services, may not be functionally complete, and are generally not suitable for production use. However, these features are included as a customer convenience and to provide the feature with wider exposure.

Customers may find these features useful in a non-production environment. Customers are also free to provide feedback and functionality suggestions for a Technology Preview feature before it becomes fully supported. Erratas will be provided for high-severity security issues.

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

сколько знаю народу который перешёл на ext4 ни от кого не слышал о потерях данных в ext3/4... хотя нет, один кадр апгрейдил root сидя в ней... не надо тут об альфах - это первый релиз, совместимость с всевозможным софтом от состояния ext4 никак не зависит, чего уж тут говорить о Wine под amd64...

> Кстати, в рейзере починили феерический баг с образом reiserfs в файле и reiserfsck?

Это не баг, это фича, чтобы конвертилку в рейзер не писать. :)

>>Проблема в кривых руках разрабов ext4, которые изменили поведение ext3, на которое программы уже полагаются.

>тем что увеличили дефолтное время синхронизации файлов с 5 секунд до минуты-двух? Или тем что что используют delayed allocation?

Это к Theodore Tso вопрос. IIRC, delayed allocation есть и в ext3, так что изменилось его использование.

> Ну собственно я это знал :)) так как много тестировал ext4 и она убивала данные гарантированно.

Видел это в ext4dev, в ext4 уже ни разу.

PS: А вообще рулит sync и контроллеры с батарейкой...

По ссылкам ходим, матчасть учим :). Форматирование тоже обеспечивает исправность ФС после сбоя. Назначение журналирования в широком смысле - это откат на определенное рабочее, еще раз повторяю рабочее, состояние системы. В данном случае в погоне за скоростью отказались от обеспечения целостности информации и приложения при этом начали терять данные. В результате предлагается решение проблемы, которое, снизит скорость, но обеспечит целостность данных - возвращаемся на исходную позицию.