https://opennet.dev/openforum/vsluhforumID3/50519.html При тестировании экспериментальной версии Ubuntu 9.04 всплыли (https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781) неожиданные проблемы с надежностью работы Ext4. В Ubuntu по умолчанию включена возможность отложенного распределение информации в ext4 (http://wiki.opennet.ru/Ext4) (Delayed allocation), при которой данные и мета-данные могут оставаться незаписанными до 60 секунд. <br><br><br>Данная возможность является одним из главных факторов значительного повышения производительности ext4 по сравнению с ext3. Но пользователи экспериментальной ветки Ubuntu отметили случаи произвольного краха системы, после которого терялось содержимое большого числа файлов, в основном связанных с работой KDE или GNOME. Разбор ситуации показал, что при загрузке KDE и GMOME пересоздают большое число мелких файлов, и если системный крах произойдет через небольшое после загрузки время, эти файлы окажутся обнуленными (в журнал изменения вносятся сразу, но сами данные на диск записаться не успевают). ...<br><br>URL: http://www.h-o https://opennet.dev/openforum/vsluhforumID3/50519.html#155 Fri, 27 Mar 2009 09:42:19 GMT Это опять таки проблемы реализации некоторых линуксовых fs, а не приложения. На нормальных fs будет fsync только конкретного файла, он не поставит всю систему раком в ожидании. В POSIX всё-таки 2 разных системных вызова - fsync() для одного файла и sync() для всей системы.<br> https://opennet.dev/openforum/vsluhforumID3/50519.html#154 Sat, 21 Mar 2009 19:37:15 GMT По сути, если смотреть максимально обще, то фревый SostUpdates - это действительно такой специфический журнал, только существующий исключительно в памяти. И при сбое он теряется, то есть всегда выполняется rollback транзакций.<br><br>&gt;McKusick указал на два основных недостатка: <br>&gt;1) это сложность реализации (и соответсвенно отладки) <br>&gt;2) возможность утечки свободного дискового пространства при сбоях <br>&gt;Второй пункт рекомендует лечить фоновым fsck <br><br>Да, именно сложность реализации и составляет основную проблему, а сама идея неплоха. Второй пункт появляется, поскольку на диске реального журнала нет, и если сбой случится в окно записи на диск, то будет ошибка. Однако SU построен таким образом, что класс таких ошибок очень ограничен (по большому счету пропажа места, ага), потому с введением бэкграундного fsck систему можно запускать сразу же на непроверенной fs, очень удобно, в отличие от форсированных проверок "180 дней на ext3 без fsck". Журнал не панацея, хехе.<br><br>В общем, идея, повторюсь, неплоха, и вполне кон https://opennet.dev/openforum/vsluhforumID3/50519.html#153 Mon, 16 Mar 2009 19:13:52 GMT нагрузка на фс при установке ни в какое сравнение не идёт с загрузкой...<br>это первое.<br>второе.<br>при установке файло не обнуляется, а заменяется.... т.е. либо то, либо это. :-)<br><br>а изменённые конфиги вообще не принято менять.<br><br>видимо дистростроители более правильно понимают работу с файлами. :-DDDDDDDD<br>кстати, вот маленькая статейка для ознакомления - http://ru.opensuse.org/%D0%9E%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F_Ext3<br> https://opennet.dev/openforum/vsluhforumID3/50519.html#152 Mon, 16 Mar 2009 16:19:50 GMT &gt;POSIX позволяет пустую реализацию fsync(). Пример: MacOSX. <br><br>Я сердечно поздравляю юзеров макоси с этим фактом.Не думаю что он их напрягает.Если уж им не в облом покупать втридорога только "одобренное свыше" железо (освященное богами, мля), не смущает DRM и ограничилово - то уж на целостность данных таким юзерам и вовсе насрать.Свое гей-порно они заново перекачают из интернета а ничего ценней там у них все-равно нету.<br><br>&gt;Если у вас SSD или ноут или смартфон, то в ваших интересах <br>&gt;не позволять приложениям дёргать fsync() попусту чтобы не палить флешку или <br>&gt;разряжать батарею впустую. <br><br>А вы представляете себе слет конфигов на смарте вообще?Юзер не просто кардинально влопается и будет зол, сделав антирекламу.Он потащится в сервис и принесет вагон убытков.<br><br>Более того - в смартах флеш прицеплен напрямую к процу и ФС обязана сама озаботиться его wear leveling'ом, иначе он очень быстро протрется в некоторых областях.Для этого сделаны специальные ФС и уровни трансляции.Они стараются выравнивать операции на https://opennet.dev/openforum/vsluhforumID3/50519.html#151 Mon, 16 Mar 2009 16:01:53 GMT &gt;init-скрипты не конфиги... <br><br>Это смотря с какой стороны посмотреть :)<br><br>&gt; и уж точно не перезаписываются во время загрузки.<br><br>Зато перезаписываются при установке\удалении программ.И некузяво будет если у свежеустановленной программы при внеплановом рестарте вдруг ^#нется стартовый скрипт ;)<br> https://opennet.dev/openforum/vsluhforumID3/50519.html#150 Mon, 16 Mar 2009 14:45:39 GMT Ребят, чего париться - отключаем delayed allocation и все, что может привести к обнулению и радуемся)<br> https://opennet.dev/openforum/vsluhforumID3/50519.html#149 Mon, 16 Mar 2009 12:01:49 GMT а я где то писал, что в восторге от текущего положения во всех журналируемых фс? :-D<br>пока что все они - это компромис.<br>&gt;действительно, оставим НЕлюбителей наедине с их кактусом =)<br><br>глупо.<br> https://opennet.dev/openforum/vsluhforumID3/50519.html#148 Mon, 16 Mar 2009 11:48:05 GMT никто и не преподносит.<br><br>просто на все дополнительные возможности становится как-то насрать после паники ядра.<br> https://opennet.dev/openforum/vsluhforumID3/50519.html#147 Mon, 16 Mar 2009 11:46:29 GMT да и хрен с ней. кто ж спорит.<br>речь о надёжности и только.<br>