Свежие комментарии

Ну это вроде бы нормальное поведение - пока fsync() не сделан нельзя быть уверенным, что (все) записалось.

Или XFS и на fsync тоже кладет с прибором?

Тут все дело в том, что данные (насколько я это понимаю) в журнал не пишутся, а пишутся в кэш. Который по умолчанию сбрасывается на диск после закрытия файла и/или после fsync(). Естественно, при O_DIRECT кеш не задействован, но и скорость соответствующая.

В итоге получаются два интересных классических эффекта XFS после проигрывания журнала по результатам внезапного пропадания питания:
(а) свежесозданные (незакрытые) файлы могут оказаться пустыми
(б) свежесозданные или перезаписываемые (опять же незакрытые) файлы могут содержать нули вместо данных.

Файловые системы - это всё-таки не реляционные СУБД, режим постоянной записи всех данных в журнал им в большинстве случаев противопоказан.

А вот мне тут ночью пришло в голову (снились кошмары: сотни серверов под Linux)

А нету там какой-то фишки, которая стертый файл затирает рандомом?

Не люблю флеймовых тем, но таки отвечу.
Личный experience.
Более полутора сотен машин под линуксом. Видеонаблюдение. Аналоговые камеры. 16 штук по ~5fps каждая (загрузка PCI шины считается на калькуляторе). Размер одного пожатого кадра 50-70 KB, иерархически пишутся, камера-событие-файлы события. Отображение на этой же машинке, плюс возможность смотреть архив, либо живую картинку удаленно. Охранники пялятся в монитор постоянно. Террабайт перезаписывался примерно за две недели. Reiserfs. В основном без UPS (начали ставить позже, до этого экономил клиент). Днем запись получалась практически постоянно.

Был вынужден перенести подчистку файловой системы на время, когда меньше движения, потому что тормозил MySQL на некоторых запросах (а не файловая система). Тюнингом MySQL и его баз естественно пришлось озаботиться в первую очередь. До этого подчищалось по мере необходимости. Файловая система успевала отрабатывать, без всяких тормозов. В противном случае охранники изнасиловали бы весь мозг. Т.е. для этих задач файловой системы хватало.

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

так нет проблем с rm, в том-то и дело.

Теперь уже диски медленные. Не знаю о чем вы подумали, но у меня там 2 * Intel SSD по 160гигабайт. И памяти 12 гигабайт. и два 4 ядерных проца. Херово оно работает с новым железом, вот и все. А Линукс туда мы зафигачили только потому, что с этими SSD линейная скорость записи была 250мб/c, против 100мб/c (ровно) на FreeBSD 8.1. Очень может быть что скоро снесем и будет там как везде фряха.

и что будет ?
удаление в течение скольких-то там секунд, да и всё.
никаких особых замираний всего и вся.

Раньше на предыдущих ядрах и медленных дисках было дольше, сейчас быстрее, потмоу как за последние 6 лет значительно лучше стали и ext*, и сами диски, и планировщики в ядрах.

Да, я тут говорю только про стабильные ядра от RHEL, и немного про ядра OpenSUSE, а вот как работает ядро, что собрал Вася-на-всю-голову-гентушник - один /dev/null ведает.

исошки недостаточно большие?
возьми бюрэйную исошку

очень хорошо.
rm на сервере не бывает или что?
rm на сервере сверхприоритетная операция или что?
какое отношение своп к rm?

ну да, с быстрым диском будет быстрее, ваш к.о, но остальное-то причем?

это оно http://lurkmore.ru/12309 :)
ну или серьезно https://bugzilla.kernel.org/show_bug.cgi?id=12309

Проблема, в общем, есть, только она снова не имеет никакого отношения к ФС.
Планировщики IO чаще всего оптимизированы под серверную нагрузку.
как это относится к rm из шела?

у меня по месяцу висит в примерно константныъ объемах.
на больше обычно лектричества не хватает

Я не знаю, чем били по рукам тех криворуких людей..

> у нас ротейт логов на одной из машин роняет ее регулярно раз в месяц (логи то ротейтятся мгновенно, только апач больше не работает) и помогает только reboot -fn

Налицо проблема с машиной. Причем тут ФС, где таких проблем нет в принципе уже много лет ?

>> на десктопе при копировании больших файлов все задумывается так что анекдот про "сейчас дискетка отформатируется..." как раз про современные Линуксовые ядра. Debian/2.6.разные, ext3/4

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

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

Кто виноват людям, сидящим в 2011-м году на 1 гиге памяти и большом свопе ?

И вот сочетание всего этого с медленными дисками иногда даёт именно то самое "сейчас дискетка отформатируется..."

>> хочешь грохнуть исошку/исходники -- и оно тупит минуты две.

Если речь про винт 2004-го года - верю. Если речь про некие самособранные криворуким гентушником/слакварщиком ядра - тоже верю.

А так... просто sata диск, ext3/4, чпок- удалили iso-шки, проблем-то.

Мой дебиан при удалении 50Гб файла через SMB c ext4 входит в клинч на 8 секунд, даже по сети не подсоединиться по VNC в этот момент. EXT4 на системном разделе у меня разок ложился напрочь при внезапном ребуте, приходилось из бэкапа разворачиваться.

Наверное выдам крамольную мысль, но из вариантов ext3, ext4 и xfs мне больше всего понравилось поведение ....NTFS, правда с kernel-mode драйвером от Paragon (единственный минус - фришная версия на сайте не умеет дефрагментировать и проверять на ошибки). Зато на ошибки можно проверить тулзой из комплекта NTFS-3G (тормоз тот еще). Процессор грузит меньше, шуршит быстро, советую попробовать.

И в любом случае, без UPS нужно быть очень осторожным в выборе, так как линуксовые ФС либо настроены на надежность, либо на скорость (но нужно выбрать что-нибудь одно из списка, а потом соответствующую ФС: большие файлы, мелкие файлы, много потоков и т.п.).