Дэн Лу (Dan Luu), опубликовал (http://danluu.com/file-consistency/) заслуживающий внимания разбор ситуации с фиксацией изменений в различных файловых системах (ext2/3/4, xfs, btrfs). В случае краха системы без применения определённых обходных путей при записи файлов достаточно велика вероятность нарушения целостности или порядка записи данных. Проблема состоит в том, что для разных ФС нужно использовать разные методы обхода проблем, что выливается в достаточно сложные и неочевидные конструкции.
<center><a href="http://danluu.com/images/file-consistency/fs_properties.png&... src="https://www.opennet.me/opennews/pics_base/0_1450169520.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Единый способ отказоустойчивой записи файлов не выработан, а разработчики часто применяют методы обхода проблем, специфичные для определённых ФС. Например, некоторые программы надёжно работающие в ext3/ext4 начинают сталкиваться с проблемами после перехода на Btrfs, из-за того, что в программе не учтены особенности поведения Btrfs во время возникновения внештатных ситуаций. В качестве примера приложения, корректно обрабатывающего сбои на разных ФС, отмечается SQLite. Неплохие показатели у PostgreSQL. Одни из худших показателей выявлены в Git и Mercurial.<center><img src="https://www.opennet.me/opennews/pics_base/0_1450170423.png&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></center>
URL: http://danluu.com/file-consistency/
Новость: http://www.opennet.me/opennews/art.shtml?num=43524
Что-то нет ZFS в табличке, боятся что ли признать, то что у линукса нет ни одной современной ФС?
Ну там еще куча тормозного хлама на FUSE...
А вот в вантузе фуза нет!
Для тех, кто в танке: ZFS уже давно на ядерном модуле, а фузю потихоньку дропают за ненадобностью.
А что используется в датацентрах? Неужто BSD? ;)
CoreOS, SmartOS
> а фузю потихоньку дропают за ненадобностью.Откуда дровишки?
Ему не нужно, значит он свято уверен, что все выпиливают. Это линукс-логика.
Читай внимательнее, ZFS-FUSE.
Наверно потому что в ZFS нет аналога fsck, т.к. проблемы, которые решает fsck в ZFS решается путем организации пулов с избыточностью.
Избыточность сюда никаким боком. man транзакционность.
> Что-то нет ZFS в табличке, боятся что ли признать, то что у линукса нет ни одной современной ФС?На http://top500.org сходи и осознай какое ты говно.
Видимо ты про себя, твои ссылки даже не работают :-)> ping -c 5 top500.org
PING top500.org (46.137.188.112): 56 data bytes
--- top500.org ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
с аналогичным результатом пингуется ваша голова ;)
Все там работает. Чини свой энторнэт, малыш.
Странно, у меня та же картина. Хотя сам хост отдает text/html без проблем.
просто хост не отвечает на echo request. кто ж так сайты то проверяет, олухи.
то-то в последнее время там много ZFS стало появляться, в ущерб остальному..
> то-то в последнее время там много ZFS стало появляться, в ущерб остальному..SEARCH RESULTS
No results were found in Everything matching your query: ZFS
Иль ты про два локалхоста, тогда да, это статистика!
А потом посмотри на 1% линуксов на десктопе
> А потом посмотри на 1% линуксов на десктопеИ на Ext4 на Android...
на твоём месте я бы посмотрел на процент бздей на десктопе.
а потом посмотри 99% линукса, на фоне которых 100% "десктопа" - не просматриваются, почти :=)
Обидно, что в сравнении нет NFTS и HFS. Было бы интересно увидеть их преимущества по сравнении с ext2/3/4, XFS и btrfs
Вы хотели сказать их недостатки?
Неужели ни одного преимущества нету?
У FAT есть одно: файлы удаляет быстро.И ещё одно: реализуется тривиально.
> У FAT есть одно: файлы удаляет быстро.Не удаляет, а помечает, что в дальнейшем на эти сектора можно сверху сделать перезапись..
это и есть удаление, балбес. И оно в FAT O(размера файла)
> У FAT есть одно: файлы удаляет быстро.но только если их мало. в FAT нет никакого индекса директорий кроме линейного списка, поэтому файловые операции на большой иерархии - крайне медленны.
>> NFTSПростите, что? National Film and Television School? o0
Что, Ваганыч, в цирк WiFi завезли?
Нет, блин, посетителей [s]психушки[/s] опеннета на стажировку отрядили.
Это линукс детка. Нельзя смотреть на сторонние разработки, особенно на те, до которых тебе далеко и сравниваться с ними.
Наверное по этому zfs портировали на линукс. Впрочем, так же как и jfs, xfs.
Дык ZFS под линукс не работало, и не работает. Впрочем пользователи btrfs будут гооворить что всё работает, если оценить состояния к использованию в промышленных масштабах, на линуксе это будет равнозначно не работать как zfs так btrfs.
Повторяй эту мантру чаще. Может полегчает.А так - зфс в продакшне уже давно, в промышленных масштабах.
>в промышленных масштабахЭк вы вашу пару пентиумов третиьих красиво назвали!
> Эк вы вашу пару пентиумов третиьих красиво назвали!Эк вы фэйсбука задвинули. В соседней новости есть фото их третьего пентиума. Тот что с 8 видеокартами.
> если оценить состояния к использованию в промышленных масштабахBtrfs в фэйсбуке используется. У тебя есть продакшн круче?
А у Netflix UFS2 и найди того кто больше прокачивает трафика в Северной Америке?
Ютуб с убунтой. В мире.
Так вот почему они на слайдшаре выкладывают презентации об оптимизиции производительности линукса.
> А у Netflix UFS2 и найди того кто больше прокачивает трафика в
> Северной Америке?Шо, прям через UFS2 прокачивает?
> Обидно, что в сравнении нет NFTS и HFS. Было бы интересно увидеть
> их преимуществаУстаревшие ещё в прошлом веке? Какие нахрен преимущества?
а ещё FAT32 для полноты картины
> NFTS
> преимуществаА ты забавный.
>> NFTS
>> преимущества
> А ты забавный.Я смотрю, тут все такие чоткие пацаны собрались. А хоть кто-нибудь объяснит, что не так с NTFS, кроме того, что от MS? В плане надежности не хуже той же ext4, а по фичам еще фору даст.
Фрагментация выше, чем у extX. Фича с дополнительными потоками файлов весьма стремная. Есть некоторые проблемы fsck, хотя скорее всего это баг реализации в винде. Другой тип ACL.
Но в целом вполне годная ФС, объективно не хуже ext3.
Спокойно дефрагментирует смонтированный системный раздел. И не надо мне тут детскую манечку, что мол ext'ам дефрагментация не нужна. У вас всё, что у вас же можется только через *опу автогеном, автоматически становится "нинужно". Эдакий линукс-страус с головой в собственной *опе по жизни.
Из A>B(фрагментация ntfs выше, чем в extX) вовсе не следует, что B равно нулю. Ты сам выдумал про ненужность дефрагментации и мастерски разоблачил.
нинужнатор, о преаллокаторах сначала почитай. Посмотри процент фрагментации реально смонтированных разделов ехт4. И узнай о том, что дефрагментаторы под ехт4 есть.
> Фрагментация выше, чем у extX. Фича с дополнительными потоками файлов весьма стремная.
> Есть некоторые проблемы fsck, хотя скорее всего это баг реализации в
> винде. Другой тип ACL.
> Но в целом вполне годная ФС, объективно не хуже ext3.Ясно, спасибо.
> что не так с NTFS,Старая бестолковая ФС, по технологиям на уровне EXT3. Работает медленно, ничего особенного не умеет, журналирование частичное.
К широко применяемым NTFS, HFS+ в масс-стораджах хотелось бы увидеть результаты тестирования на стрессоустойчивость "рабочей лошалки" BSD-серверов - UFS2.
Доводилось использовать UFS2. Лошадка совсем не рабочая.> К широко применяемым NTFS, HFS+ в масс-стораджах
Так тонко, что аж толсто.
>> Доводилось использовать UFS2. Лошадка совсем не рабочая.Такая не рабочая, что для СУБД с открытым кодом работает быстрее и надежней, чем все остальное. Я в особенности про PostgreSQL.
Слайды лень искать, но могу за свой опыт говорить, как человека, работавшего в компаниях с самыми большими PostgreSQL в нашей стране в качестве DBA.
И да: быстрее всех с постгресом во фре работает ядро 10.2 . А в Linux - 2.6.32 . Странно, не так ли? )
- То, что постгрес на линуксе работает быстрее, чем на бзде - не странно. Много было бенчмарков.
- А вот то, что в пределах линукса быстрее всего работают ядра 2.6.32 и 3.13(убунтовское лтс) - это очень интересный факт, который прежде всего обусловлен огромным количеством платформозависимых оптимизаций в коде.Особенно, когда планировщик задач или IO клещится с таковым из СУБД. Ядро за последние несколько лет очень сильно изменилось в лучшую сторону, особенно по отзывчивости. Например, чтобы впасть в ступор, можно запустить постгрес поверх QCOW2, чего разрабы не предусмотрели явно. Частично лечится с помощью elevator=noop.
> - То, что постгрес на линуксе работает быстрее, чем на бзде -
> не странно. Много было бенчмарков.По последним данным и моему субъетивному опыту: на FreeBSD 10.1, 10.2 Постгрес работает лучше, чем на любом Linux. Процентов на 10 быстрее, чем на лучшем для постгреса ядре linux (2.6.32) . По ЦПУ примерно одно и тоже на 10.2 vs. 2.6.32 . Выигрыш идет за счет UFS.
Сейчас с linux и postgresql большие проблемы: старые ядра перестают поддерживаться, а постгрес работает в 4 раза медленней на современных ядрах linux.
Приглашали людей из известного консалтинга по постгресу в нашей стране: они только пожали плечами. Придется решать своими силами когда руки дойдут. Жаль что в Linux с DTrace в ядре всё плохо.
> Выигрыш идет за счет UFS.если можно, чуть деталей:
* рейд софтовый или хардовый?
* никаких lvm или чего подобного в linux-конфигурации не было?
> Доводилось использовать UFS2. Лошадка совсем не рабочая.Проблемы у вас. У нас работает годами.
>> К широко применяемым NTFS, HFS+ в масс-стораджах
> Так тонко, что аж толсто.ZyXEL делает SOHO-маршрутизаторы на прошивке NDMS V2. В компонентах USB Storage присутствует поддержка возможности работать именно с NTFS, HFS+ и FAT32 на подсоединяемых флэшках. Про XFS/Ext3/Ext4 - ни сном, не духом. А это, между прочим, БАЗОВЫЙ УРОВЕНЬ, который к масс-стораджам имеет косвенное отношение (ну какой из роутера NAS?! Так, примочки для торрентов).
Домашние NAS штатно должны иметь поддержку NTFS и HFS+, поскольку есть спрос на соответствующую функциональность, и он должен быть удовлетворён. Роутеры с базовыми функциями NAS - показатель нужности той или иной функциональности.
Сколько несвязного бреда, особенно по NTFS и HFS+, особенно когда домашние и промышленные насы на ехт4 работают.> Проблемы у вас. У нас работает годами.
Проблем с бздой уже давно нет, сразу после ухода бояздэшника. Те же самые машины работают идеально на линуксе.
Серьёзно ext4? Промышленные??? Скорей домашнее кустарнае, на дешманском и коппечном железе. А промышленные масштабы офис из 5 компьютеров с windows.
Гнилая у тебя жизнь, но я и не сочувствую.Я так понял, что сотни физмашин и тысячи ВМ - это "Скорей домашнее кустарнае, на дешманском и коппечном железе.", а твои "5 компьютеров с windows." - это промышленные.
Стрелочник :-) Правда обижает...
Ты для начала свой бред перечитай ещё раз, а потом покажи пример своего "продакшна". А насчёт правды - чем больше таких как ты, тем меньше в ИТ-сфере конкуренции.
Так вот почему у тебя 100500 вопросительных знаков и идиотских смайликов. Стандартное закипание бзды в образе вантузятника.
Не совсем ясно о чём рассуждает Дэн Лу если корректная фиксация изменений на любой ФС гарантируется только при использовании различных вызовов fsync*.
Дэн Лу рассуждает о реальной потере данных. Угроза которой появляется сразу же после вызова любой функции записи и сохраняется до возврата из fsync.
А в чём новость то?
Вот это что за глупость написана: "Единый способ отказоустойчивой записи файлов не выработан, а разработчики часто применяют методы обхода проблем, специфичные для определённых ФС"?
Реальная - это когда она в каких-то заметных количествах наблюдается. А этот товарищ посто проповедует.
Всё тут ясно, рассуждение о том что как плохо нам без ZFS. И то что мы сидим на разработках 70х годов.
А где UFS2 с soft updates?
> А где UFS2 с soft updates?В мусорке. Достала своей падучестью и недосинком.
Потом туда же ушла фрибзд, а чуть позже и бояздэшник, её поставивший.
Обоснуй это Netflix.
Обоснуй это рамблерам, яндексам, пейсбукам, опачам и прочим гуглам. Ну и ещё вдобавку расскажи о месте бзды в топ500
Он уже скидывал выше дохлый top500.
Ну да - в топ 500 всё сплошь файлопомойки :) опупеннет во всей красе!
Павлинукс - а ты в курсе что на кластерах ноды вообще локальных дисков не имеют, и все такие рассуждения о FS для них в приложении к топ 500 ... доставляют :) Впрочем для павлины и нужны для этого ...
В топ500 - числодробилки. И ещё, обязательно поищи статистику использования бояздэ там.
Как она могла тебя достать, если ты ни разу ей не пользовался? :-)
Тупая ухмылка в смайлике тебе идёт. А на бзду я забил ещё в 2008, ибо уже тогда она начала проигрывать пингвину во всём. Сейчас раз в полгода попадаются ыксперды со своими инсталляциями, которые просто дохнут и тормозят, вот одного недавно ушли.
> вот одного недавно ушли.Ыффективные фантузянеге ?!
Да. Тот бздун ещё и вантузировал на макакоси из-под ворованой вари.
> Сейчас раз в полгода попадаются ыксперды со своими инсталляциями, которые просто
> дохнут и тормозят, вот одного недавно ушли.да их много откуда ушли, пусть идут всей толпой в нетфликс.
По статистике, если человек знает xBSD, он на порядок лучше знает Linux лучше фанатичного пользователя Linux. В основном 1 к 100 если собеседуешь уг в кадрах кто любит Linux.
Особенно, если он вантузятнек и этим линуксом не пользуется. Хорошая статистика. Держи нас в курске.
Бизнесу нужен рабочий инструемент, а не фанатики которые чинят генту после желанных ебилдов, а не выполняют задачи.
Ты из некрософта? То, что нужно бизнесу, эти самые "фанатики" на убунте или центоси как раз и реализовуют. Расскажи ещё про студенческие поделки Торвальдса, или что та ещё вантузобздуны любят.
Такие как ты могут только потреблять, в том числе и блага, созданные "фанатиками".
Бизнесу нужен рабочий инструмент, а не фанатики которые чинят боязду после обновления портов, а не выполняют задачи.
//fixed
> а не фанатики которые чинят боязду после обновления портовО, сразу видно знатока!
Зы: Вы забыли проплюсовать себя, о великий эксперд!
а что, setup.exe надо было обновлять?
Че, два бота только? Слабовастенько...> а что, setup.exe надо было обновлять?
Что сказать-то хотел, ыкспертоид?
Зачем "чинить бзду" после обновления портов?
Опять: cлышал звон, да не в курсе откуда он?И что вас так бомбит-то от одного упоминания бзд? =)
Хотел сказать то, что видел. Все бздуны - вантузятнеги. Кстати, а тебя чего бомбит-то?
> Хотел сказать то, что видел.А нам откуда знать, что вы там, в бреду, про порты и бзд видели?
Что-то про починку бзд после обновления портов (хоть бы загуглили на тему портов, что ли), потом вообще свой любимый setup.exe приплели.
Ну, про бред я уже упоминал, классический "икспертус по бздaм и бздунaм" в своем репертуаре )> Кстати, а тебя чего бомбит-то?
Ну да, это же я в каждой второй новости пишу про бзду и "бздунoв" и какой оне все отстoй!
Вам, эксперту, конечно же виднее! )
Cлив бздуна. Знакомо. Кроме какашек никаких больше аргументов.
> Cлив бздуна. Знакомо. Кроме какашек никаких больше аргументов.О великий,
во-первых: мухи, тьфу, порты идут отдельно и чтобы "сломать бзду" обновлением портов нужно очень постараться.во-вторых: у портов есть "срезы", типа "стабильных", а не только "head"
в-третьих: внезапно,
> -b create and keep a backup package of an installed port
> By default portmaster creates backup packages of installed ports before
> it runs pkg_delete(1) during an update
>Хотя да, это не для джедаев.
в-четвертых:
опять же, внезапно:
pkg backup
pkg create -a -o "mybackups"полный бэкап БД и софта! Ух ты!
Да да, в случае чего можно будет тупо запустить "pkg add -f".
А если перед этим еще и запустить "pkg repo /foo/mybackup"
добавив в список реп
{url: "file:/foo/mybackup/",
enabled: true }
то получится вообще полноценная репа со всеми плюшками1!в-пятых: автоматические сборщики типа poudriere, с атомарным обновлением репы, поднимающие свой, отдельный джейл для сборки.
в-шестых: про отдельную железку для тестов я промолчу, равно как и о read-only для базы, с выносом /usr/local в отдельный раздел и бэкапах на уровне ФС (да да, dump/restore) – не для джедаев это ведь!
Но джейл с идетничной конфигурацией, даже тупо на базе основной машинки, только с отдельным /usr/local, религия тоже поднять не позволила?
Это каким же надо быть талатнливым ССЗБ и проигнорировав кучу манов и хэндбук, "сломать бзду"? =)
Хотя да, это все лирика, зато "чинят боязду после обновления портов" – аргументище иксперта! )
Слишком много понтов и бессмысленного онанизма, хотя гугление ты осилил. Просто сегодня нет смысла на 1 машине по 100500 сервисов вращать, вместе с выносом /usr/local. Нужен бэкап - есть директория контейнера или образ вм. Вот только ыксперды, ломающие бзду обновлением портов мне частенько попадались, из бояздэ-фанов кстати.
> Слишком много понтов и бессмысленного онанизма, хотя гугление ты осилил.Что сказать то хотел, болезный?
> Просто сегодня
> нет смысла на 1 машине по 100500 сервисов вращать, вместе с
> выносом /usr/local.т.е. о том, что имненно в бздах идет в /usr/local, иксперд тоже ни ухом, ни духом?
> Вот только ыксперды, ломающие бзду обновлением портов мне частенько попадались, из
> бояздэ-фанов кстати.Т.е. аргументов нема, начинаем все сначала? Ну хоть вантуз и путти еще упомянул бы!
ЗЫ: отминусовался ты оперативно, а вот проплюсовать себя любимого – забыл! Ай-я-яй!
Видать, ыксперд ничего не знает о префиксах сборки ПО. Они могут быть не только в /usr /usr/local, но и в /data/data/com.spartacusrex/files/local, или просто там, где мне удобно в соответствующей ОС этот префикс собрать.Я не минусовал, просто твой бред другим тоже не интересен.
> Видать, ыкспeрд ничего не знает о префиксах сборки ПО. Они могут бытьНе виляй сeдалищем – речь шла о бздaх и портах, а не о сборках от Васяна.
https://www.freebsd.org/doc/handbook/dirstructure.html
> /usr/local/ Local executables and libraries. Also used as the default destination for the FreeBSD ports frameworkНо ведь для настоящих джeдая чтение манов – пoнты и oнaнизм! Джeдай лучше денек-другой будет что-то чинить, зато сэкономит 20 минут на чтении!
> не только в /usr ... или просто
> там, где мне удобно в соответствующей ОС этот префикс собрать.кажется я начинаю догадываться, как обновлением портов таки "поломать бзду".
> Я не минусовал, просто твой бред другим тоже не интересен.
детский сад, штаны на лямках.
Таки изучи что такое префикс, и что это можно делать во всех юникс-подобных ОС. Например в тех, где нет /юзр, или просто корень в инитрд. Хотя тeбе это и не снилoсь.
Рабочий инструмент не ломается как раз, ubunta даже между 14.04.1 до 14.04.2 умеет ловко становиться раком. Не говоря уже про systemd и бинарные логи в CentOS/RHEL. Вы батенько видимо совсем не инженер.
Ога. Расскажи это тому, кто сотни виртуалок убунты ансиблом между релизами обновлял. И всегда успешно. А ещё я много сисв-инит скриптов на системд переписал. Почему тогда у меня всё работает? Что-то не так делаю. С бздами тоже всё получалось. Может потому, что я не вантузятнег?
Угу угу, виртуалок. На реальное железо денег нет? Да и виртуалки обновлять вообще без ansible надо. Это надо быть вообще линуксоидом с низкой квалификацией, что бы так обновлять виртуалки в 21-ом веке. А ты умеешь чинить битый бинарный лог через hex редактор? Похеру, разрешаю даже в windows это сделать.
> Угу угу, виртуалок. На реальное железо денег нет?Ага, значит облака нематериальны. Ну, это тема для свидетелей иеговы.
> Да и виртуалки обновлять
> вообще без ansible надо.Тысячи виртуалок, вручную, ага...
> Это надо быть вообще линуксоидом с низкой
> квалификацией, что бы так обновлять виртуалки в 21-ом веке.Чё?
> Похеру, разрешаю даже
> в windows это сделать.Спасибо, но такое делай сам.
> Это надо быть вообще линуксоидом с низкой
> квалификацией, что бы так обновлять виртуалки в 21-ом веке. А ты
> умеешь чинить битый бинарный лог через hex редактор? Похеру, разрешаю даже
> в windows это сделать.Чинить? А не читать?
man journalctl
"не учтены особенности поведения Btrfs" - забавно, что "самая прогрессивная и совершенная фс" требует своего собственного, особого подхода, позволяющего учесть все косяки разработчиков этой "фс".
Лет через 20, будет примерно то что сейчас есть в ZFS.
> Лет через 20, будет примерно то что сейчас есть в ZFS.но увидеть это смогут только более другие существа:)
> Лет через 20, будет примерно то что сейчас есть в ZFS.Уже сейчас ближе к народу. Кстати, а где используется Solaris, на который забили с момента поглощения Sun?
> Уже сейчас ближе к народу. Кстати, а где используется Solaris, на который
> забили с момента поглощения Sun?В куче сториджей на который вертятся твои виртуальные дедики. Ни то, ни другое ты не поглядеть, ни пощупать не можешь ...
Ну и - ты таки не поверишь!!! - в _линуксе_! Ибо пришли сурьёзные дяденьки из DOD, без чуйства юмора, но с мешком бабла и приказали скрещивать :-\ Зачем то им нада!(С)
>> Кстати, а где используется Solaris,Ну да, у нас тут холидэй сизон в разгаре, в обед пива хряпнул :)
Ответ был не про Solaris, а про ZFS :) Неее - домой, домой, домой ... :)
Тоесть разработчики фс дают пользователю опции монтирования которые позволяют ускорить фс в ущерб надежности, а разработчики софта изо всех сил стараются эти опции обойти, вместо того чтобы сказать пользователю "прежде чем менять дефолтные опции монтирования хотя бы мануал по ним почитай дабы поимать чем это чревато дебил".Я считаю что это в корне неправильно.
То есть пользователи выбирают опции, которые дают им достаточный уроыень надёжности для большинства ситуаций, а разработчики софта, который требует большего, об этом обычно знают и стараются учитывать. Обычно можно и наоборот сделать - почитать мануал на БД или подобное и синхронизацию отключить к чертям, если в носителе и ФС уверен.Напоминаю - стандартный случай записи в файл на никсах - это "записать обновлённые данные в новый файл, потом переименовать его в старый". И для этого случая никаких проблем нет. А для перезаписи поверх старого - есть, да. Но по факту это в основном касается применений, где надёжность обеспечивается другими способами - бэкапы, сетевые логи и т.п.
> То есть пользователи выбирают опции, которые дают им достаточный уроыень надёжности для большинства ситуацийА разработчики софта решили насрать на выбор пользователя потому что принимают его за идиота.
>А разработчики софта решили нaсрать на выбор пользователя потому что принимают его за идиота.Угу, мечта разработчика софта: поддерживать пару дюжин комбинаций ФС и опций.
> Проблема состоит в том, что для разных ФС нужно использовать разные методы обхода проблем, что выливается в достаточно сложные и неочевидные конструкции.
А если почитать оригинал, то вообще все может стать с ног на голову:
The manpage literally refers to rumor. This is the level of documentation we have. If we look back at our example where we had to add an fsync between the write(/dir/log, “2, 3, foo”) and pwrite(/dir/orig, 2, “bar”) to prevent reordering, I don’t think the necessity of the fsync is obvious from the description in the manpage. If you look at the hardware memory ordering “manpage” above, it specifically defines the ordering semantics, and it certainly doesn’t rely on rumor.
> I don’t think the necessity of the fsync is obvious from the description in the manpage.Вообще говоря это очевидно.
А разработчики знают, что их случай - не из этого большинства, и принимают соответствующие меры.
> Напоминаю - стандартный случай записи в файл на никсах - это "записать
> обновлённые данные в новый файл, потом переименовать его в старый".Угу, и это не работает для символических ссылок, для жёстких ссылок, для файлов с ACL и расширенными атрибутами, для больших файлов (не оптимально). Как то не очень хорошо.
> Угу, и это не работает для символических ссылок, для жёстких ссылокОно и не должно для них работать. Особенно для вторых.
> для файлов с ACL и расширенными атрибутами
Зависит от софта. Он с тем же успехом может не учитывать и обычные права.
> для больших файлов (не оптимально).
Зависит от структуры файла. Но там где она позволяет и не применяется этот метод.
> Я считаюОго, вы уже устный счёт проходили?
Почитаешь - жуть. А потом вспоминаешь, что на практике проблем особых нет, и всё это больше похоже на призыв чинить то, что не поломано.Особенно разговор об ошибках диска умиляет - ну да, если диск начал сбоить - выкинь и возьми данные из бэкапа, а то, что на сбойном диске - валидируй на уровне приложения. Стандарный подход.
Кстати, хочу заметить, что два отчёта, о которых автор в конце говорит, древние - 2005-го и 2008-го года. не знаю, как насчёт NTFS, а в линуксе с ФС с тех пор поменялось примерно всё.
А чо все ФС без барьеров? У XFS хорошая производительность с ними.
Ты чинил хоть раз это дерьмо? Или оно у тебя как top500 работает? LOL
> Ты чинил хоть раз это дерьмо? Или оно у тебя как top500
> работает? LOLМнение неадеквата, обзывающего всё вокруг дерьмом никому не интересно.
барьеры и на ext4 не создают излишней нагрузки. в пределах 1-3% просадка производительности.
При каком профиле нагрузки? Для БД у вас будет не 1-3% TPS просадка от барьеров, а больше.
"без бареьров" XFS хорош только в SGI-шной версии.
без ихних твиков, ванильная версия - что с барьерами, что без - не блещет.
исключение - твик на Очень большой буффер, который для эмбеддовки - неприменим а на серваках с декстопами - обходим с тем-же(если не лучше)эффектом.
Это у чувака из сабжа ещё при пропадании света флешпамять и всякие SSDы не сдыхали, то-то он удивится.У каких ФС есть снапшоты и шифрование без костылей а ля "смонтируйте поверх ста прокладок"?
А так же возможность сменить столетний пароль на зашифрованном томе, не потеряв успешно все данные на оном?
Ответ очевиден -> http://www.oracle.com/technetwork/articles/servers-storage-a...Больше нет ничего, а под линуксом в ближайшие лет 20 ничего ждать не стоит.
Ответ не очевиден, т.к. шифрования в открытых реализациях ZFS до сих пор нет, это весьма печалит. Если кто в теме "до коле", было бы интересно узнать.
Пользовал активно UFS2+SU, UFS2 SU+J, ZFS (в т.ч. на x86), вполне нормальные ФС, не знаю чего у всех так бомбит. В этом плане Sabayon смотрится весьма интересно, с одной стороны он source based, с другой у него заявлена поддержка ZFS из коробки, но качество пока хромает :(
Критерий "нормальности" - уж очень растяжимая вещь. Много чего поюзать пришлось, так самая надёжная фс - это как раз ext4. UFS2, на бзде, своим развалом при выключении питания/остановке ВМ - слишком рискованная вещь, чтобы в ней вообще хранить данные. ZFS на линуксе - тоже хорошо себя показала.
Всё познаётся в сравнении.
UFS2 SU+J очень сложно развалить. Тут очень интересно было бы статистику в сравнении с Ext4
Упрощённая статистика:
- ехt4 - за годы её существования никогда не падала. Линукс-машины выключались, виртуалки стопались. Я их не жалею, ибо fsck всё поправит.
- ext2,3 - при мне - тоже почти никогда. Был только случай потери данных из-за падения жёсткого диска на каменный пол.
- UFS-2 - падала всего лишь сотни раз. На разном железе и виртуалках. Основная причина - некорректное завершение работы. Данные терялись из-за недосинка. ФС терялась из-за отказа fsck. Возможно, если бы всё всегда выключалось корректно, то этого бы не происходило, но, я не могу позволить себе корректно гасить тысячи ВМ, несколько из которых были на бзде.
- NTFS - падала десятки раз(я с вантузом очень давно ковырялся. Сейчас уже не могу оценить), перемешивались данные между файлами, фрагментированные тормоза, превращение блочного устройства в нечитаемое месиво(как из-под вантуза, так и из-под линукса)
Ну не падала у меня UFS2. ext вот на малинке недавно у друзей-линуксоидов прекрасно умер ВООБЩЕ, fsck не спас. Извини, не имею оснований верить анонимусам со статистикой в "сотни тысяч смертей" на том, что они не используют вообще
> верить анонимусам со статистикой в "сотни тысяч смертей" на том, чтоБерём какой-либо конфиг, затюненый под железку с БП, с async-ами и прочими шахматами, возможно ещё без SU, но с RW и атаймом на "базу", (зато не выносим var/ tmp) и делаем сотню клонов ...
>> верить анонимусам со статистикой в "сотни тысяч смертей" на том, что
> Берём какой-либо конфиг, затюненый под железку с БП, с async-ами и прочими
> шахматами, возможно ещё без SU, но с RW и атаймом на
> "базу", (зато не выносим var/ tmp) и делаем сотню клонов ...Без SU в UFS2 не будет работать упорядочение транзакций записи.
> Без SU в UFS2 не будет работать упорядочение транзакций записи.Кэп, Вы? )
В этом ведь вся фишка – можно будет на форумах писать о том, что УФС регулярно валится на сотне машин, при этом упирая на то, что в ext4 "все работает"!Тут ведь как:
Очевидно не cрабатывает "sync" мета-данных ФС.
Мне лень в гугол, но SU это вроде как раз хитромудрая атомарная запись мета-данных, именно для того, чтоб при "резком отключении" не остаться у разбитой ФС.
Т.е. атомарность => или запись полная или она вообще отсутствует, а "недосинк" по определению – бажище.http://www.mckusick.com/softdep/
> Soft updates, an alternative to these approaches, is an implementation mechanism that tracks and
> enforces metadata update dependencies to ensure that the disk image is always kept consistent.Однако: в мылолистах тишина, в багтрекере тишина, на форумах тишина (почти как на кладбище) и лишь иногда проскакивает "когда можно будет делать снэпшоты при включенном журнале?"
Хотя вон, есть энтузиасты пилящие бзд под малину (кто-то в рассылке даже упоминал, что "убил" на это дело пару сд-карт и советовал оключить на сдшках журналирование) и уж они должны были "огрести по полной" – фн нет, там тоже тихо.
А значит, дело скорее всего все-таки в конфиге – или самой бзд или виртуалки (у которой свой кэш и которая кладет большой и толстый болт на все попытки синхронизации).
Снапшоты на SU+J делались прекрасно, не было никаких проблем. А зачем отстреливать механизм обеспечивающий целостность ФС и рекомендуемый by default и жаловаться на проблемы, которые сами себе наворотили?
Я так же не понял, как отдельно "тюнить железку под БП". У народа уже блоки питания "из коробки" не работают? Так может с БП проблемы, если их надо тюнить и всё разваливается, может стоит поискать нормальный БП?
А вот на фоне всего этого, у ext4, zfs, btrfs - спокойно можно отлючать питание. В дефолтной конфигурации.Вопрос: Как протюнить виртуалку под ИБП, если гипервизору не желательно ждать корректных выключений всех гостей?
> А вот на фоне всего этого, у ext4, zfs, btrfs - спокойно можно отлючать питание. В дефолтной конфигурации....и остаться с консистентной ФС, но с проблемами целостности открытых на запись файлов.
Вообще же, аварийное завершение работы примонтированных ФС в плане штатной операции - не самая подходящая идея для дата-центра. Будет момент, когда прилетит серьёзная ответка горе-администратору за такие вольности.
А разве SU не включено в дефолтной конфигурации? Или Вы по каким-то пионерским мануалам 2002-го года до сих пор вручную всё это размечаете?SU для UFS2 пришло с FreeBSD 5, а это 2003-ий год.
Ext4 стабильный - 2008-ой год (уже тогда во фре была ZFS).
Btrfs стабильный - вот только недавно. Причём она тоже изначально сделана Ораклом (все ж так любят хаить ZFS за то что от Оракла).
Так для вас проблема, что если ГАДИТЬ РУКАМИ ВО ВСЁ что для вас делали последние 12 лет, то странно затвиканная ФС, запущенная на другой странно затвиканной ФС, запущенной на непонятном винте, может вести себя странно если выстрелить в БП?Если вам не нужно сохранять стейт гостей, то проще поднимать снапшоты RO (кстати, Docker разве делает не так же?), а всю текучку сливать по NFS или другим удобным методом, ИМХО. И ваши волосы будут мягкими и шелковистыми.
У вас кроме локалхоста где-нибудь есть btrfs? Например на БД где хранят бабки людей есть ли btrfs или хотя бы всеми любимый ext4?Вот пример что ntfs/zfs/jfs2(AIX) есть на таких сервера почти везде
> У вас кроме локалхоста где-нибудь есть btrfs? Например на БД где хранят
> бабки людей есть ли btrfs или хотя бы всеми любимый ext4?
> Вот пример что ntfs/zfs/jfs2(AIX) есть на таких сервера почти везде- бтр, зфс, ехт4 - дев и прод ВМ. О бабках - 5 видеопорталов, биллинг, хранение видео.
- Сохранять гостей - не надо. Надо, чтобы они не разваливались из-за выключения и бзды внутри.
- Я не говорю о том, включен SU или нет по дефолту. Я о том, что с него нет толку.
- Из странно затвиканых ФС - ЗФС, работает хорошо. На линуксе, в продакшне, со снэпшотами.
- NFS? - НЕТ! Есть куча других ФС для тех же юзкейсов, но мне не надо никого сливать, у меня и так хранилище в цефе.
>Я не говорю о том, включен SU или нет по дефолту. Я о том, что с него нет толку.Т.е. даже не включен?
Или просто классическое "у всех работает, у меня не работает – значит на самом деле ни у кого не работает и вообще, все ... а я д'Артаньян!!"рукалицо.жпг
Вообще-то, уфс падала не только у меня, и с включеным SU, так кто здесь д"Артаньян? Перечитай мои комменты ещё раз, там писалось о том, что в остальные фс таких проблем не имеют.
> Вообще-то, уфс падала не только у меня, и с включеным SU,Багрепорт? Конфиги ВМки и БЗДы?
> так кто здесь д"Артаньян?
Очевидно тот, кто плюсует сам себя? )
> Перечитай мои комменты ещё раз, там писалось
> о том, что в остальные фс таких проблем не имеют.Багрепорты или хотя бы пара конфигов есть? Даже не срaча, а интереса ради ...
> А вот на фоне всего этого, у ext4, zfs, btrfs - спокойно
> можно отлючать питание. В дефолтной конфигурации.УФС тоже. Правда, проблему на уровне недописанных файлов никто не отменял, но на уровне ФС все будет зашибись.
> Вопрос: Как протюнить виртуалку под ИБП
Да никак, дефолт установка уже сама по себе идет с SU+J.
Лучше же конечно сделать корень ридонли, вынести /var /tmp /usr/local и т.д на отдельный раздел ... но не критично все это на самом деле.
1) Речь шла не о недописанных, а о потери уфс2 до невосстановимого фсцк, состояния.
2) Выноси, не выноси - всё равно получишь вышеописанное. Там речь о виртуалках была, перечитай ещё раз.
> 2) Выноси, не выноси - всё равно получишь вышеописанное. Там речь о
> виртуалках была, перечитай ещё раз.Я читал:
>> UFS-2 - падала всего лишь сотни раз. На разном железе и виртуалках.
> 1) Речь шла не о недописанных, а о потери уфс2 до невосстановимогоссылочку на багрепорт и конфиги можно?
> Снапшоты на SU+J делались прекрасно, не было никаких проблем.Лайв-дамп для бэкапов.
> А зачем отстреливать
> механизм обеспечивающий целостность ФС и рекомендуемый by default и жаловаться на
> проблемы, которые сами себе наворотили?Чтобы жаловатья на форумах на неработющую и глючную УФС, вестимо!
> Я так же не понял, как отдельно "тюнить железку под БП".
А фиг его знает, просто отдельные "умельцы" могут такое "натюнить"
> Это у чувака из сабжа ещё при пропадании света флешпамять и всякие
> SSDы не сдыхали, то-то он удивится.
> У каких ФС есть снапшоты и шифрование без костылей а ля "смонтируйте
> поверх ста прокладок"?
> А так же возможность сменить столетний пароль на зашифрованном томе, не потеряв
> успешно все данные на оном?Вообще, есть уровень устройства хранения данных, а есть уровень собственно ФС. Классические (условно) ФС, вроде FFS/extN/NTFS, работают только на втором, а вот ZFS-Btrfs лезут и на первый. Уже поэтому их сравнивать не совсем корректно, с технической точки зрения. Но корректно с пользовательской...
К чему это я? А, да, шифрование. Его уместнее, возможно, делать на первом уровне, отдельно работающем? Как в softraid опёнковском, например. Правда, последний так до конца и не научили корректно выключаться в случае стекирования... GEOM, вроде, более адекватный в этом плане.
Все помешались на этой надежности. Есть дофига задач, в которых потеря данных даже за целый час незначительна. Но при этом ни в одной фс впринципе не предусмотрено кэширование записи, всё обязательно пишем здесь и сейчас. И плевать что это создает излишние тормоза для пользователя и быстро изнашивает ssd.
> Все помешались на этой надежности. Есть дофига задач, в которых потеря данных
> даже за целый час незначительна. Но при этом ни в одной
> фс впринципе не предусмотрено кэширование записи, всё обязательно пишем здесь и
> сейчас. И плевать что это создает излишние тормоза для пользователя и
> быстро изнашивает ssd.Кеширование в нормальных ФС вполне себе предусмотрено. Если в ваших задачах не критична потеря данных за последний час - хватит качать порнуху. В продакшене за час работы организации вам съедят мозг чайной ложечкой, регулярно помешивая и звонко постукивая об край черепной коробки
Ну вот тебе сходу две очень даже продакшеновые задачи: запись логов и бекапы. Поведай нам жуткие подробности поедания мозга на их примере.
> Ну вот тебе сходу две очень даже продакшеновые задачи: запись логов и
> бекапы. Поведай нам жуткие подробности поедания мозга на их примере.За потерю нужных логов на проде поддержку/ИТ казнят лютой казнью. А как бекапы соотносятся с настройкой кеширования - не понятно, если только вы не каждую минуту бекапите систему.
А за потерю логов, которые не понадобились? А это 99% логов.Причем здесь каждую минуту? Может быть и раз в сутки, а может вообще быть непрерывным. Суть в том, что потеря пары часов при создании бекапа вообще никого не волнует, если только ровно в это же время не случился факап и с основным сервером. А ведь бекап может идти и больше чем в одно место и на кратковременное падение одного из них вообще всем плевать.
> А за потерю логов, которые не понадобились? А это 99% логов.Когда сервер падает, логи автоматически нужны. И именно в этом случае они теряются. Забавно, не находите?
> Причем здесь каждую минуту? Может быть и раз в сутки, а может
> вообще быть непрерывным. Суть в том, что потеря пары часов при
> создании бекапа вообще никого не волнует, если только ровно в это
> же время не случился факап и с основным сервером.Если при создании бекапа результат никого не интересует, то неладно что-то в королевстве датском.
> Ну вот тебе сходу две очень даже продакшеновые задачи: запись логов и
> бекапы. Поведай нам жуткие подробности поедания мозга на их примере.Кэширование для бекапов? Серьёзно? У вас клёёёвый прод!
И да, если кто-то лезет за бекапом (очевидно потому что текущее файло битое) и не находит бекапа, то кто-то с кешированием "во все ненужные места" пойдёт искать работу =)Логи... ну может быть... но может быть вам такие логи и не нужны?
И да, если сервер вдруг раз в час (или сколько вы там себе настроили на кеш) резко проседает под нагрузкой, это тоже как-то ну оооочень странно.
> Кэширование для бекапов? Серьёзно? У вас клёёёвый прод!Ну давай, поделись как надо.
> И да, если кто-то лезет за бекапом (очевидно потому что текущее файло
> битое) и не находит бекапа, то кто-то с кешированием "во все
> ненужные места" пойдёт искать работу =)То есть сразу должен навернуться и бекап и продакшен. мягко говоря не очень частая ситуацияю А если бекап шел сразу на несколько отдельных серверов еще и географически разнесенных? Тоже все сразу навернутся?
> Логи... ну может быть... но может быть вам такие логи и не
> нужны?Ты не поверишь, но логи не нужны в 99% случаев. Их ведут ради разбора факапов и иногда статистики. На небольшую потерю статистики обычно плевать, а факапы должны случаться достаточно редко. В противном случае проблема совсем не в кешировании.
> И да, если сервер вдруг раз в час (или сколько вы там
> себе настроили на кеш) резко проседает под нагрузкой, это тоже как-то
> ну оооочень странно.Про запись данных раз в час тебе нашептали голоса в голове. Не слушай их, до добра не доведут.
> Ну давай, поделись как надо.Не хочу, когда сами огребёте пару раз - научитесь научитесь, общепринятая практика хранения данных же вам не интересна, всё тлен, всё ненужно
> То есть сразу должен навернуться и бекап и продакшен. мягко говоря не очень частая ситуацияю А если бекап шел сразу на несколько отдельных серверов еще и географически разнесенных? Тоже все сразу навернутся?
Далеко не все сидят в облаках или имеют инфраструктуру размазанную по принципу "этот сервер будет работать тут, а вон оттого ННАДА чтобы респонсы тормозили посильнее, поэтому перевезём его на северный полюс, заодно сэкономим на охлаждении".
Довольно классическая ситуация: вся улица остаётся на несколько часов без света (например из-за пожара у кого-то в другом краю этой улицы). И тут вдруг оказывается, что к вашим костылям с кешированием надо дописывать ещё костыли, которые будут мониторить UPSы и быстренько синкать эти кеши на диск, а так же каждый квартал пачками менять АКБ которые без ваших понтовых костылей вполне бы ещё пару лет поработали, что тоже не самое безболезненное и не самое дешёвое мероприятие.> логи не нужны в 99% случаев
Ну так не пишите их, раз они вам не нужны, нафиг вы нам мозг морочите?
> Про запись данных раз в час
Нашептали в соседнем посте этой же ветки этого же сабжа, дочитывайте всю ветку перед комментированием
> В продакшене за час работы организации...Не все сервисы "в продакшене" критически влияют на работоспособность организации. Или у вас там всё что только можно крутится на одном серваке с одним диском/массивом и одной файловой системой на всё?
И обычно есть вполне достаточно, например, внутренних сервисов, потеря данных на которых либо вообще легко и автоматически восполнима (а значит не то что за час, за сутки, за неделю можно без особого ущерба все терять), либо совершенно по-другому резервируется/дублируется/зеркалируется/... так что потерялось, да ну и х#@ с ним, постояли, восстановились, засинхронизировались с "выжившими" и поехали дальше... Неприятно? Конечно! Катастрофа? И рядом нет! Так, легкий дискомфорт...
Ну и бред. В одной небольшой конторе, где работаю, файловые шары бэкапятся раз в день (несколько терабайт). Попробуй организуй бэкап нескольких терабайт (размазанный по всей РФ) с периодичностью меньше часа (не критична потеря данных за последний час - хватит качать порнуху). И никто не плачет, в SLA написано 1 сутки, бабло дали на данную реализацию. А 1 час - это НАМНОГО дороже.
> Ну и бред. В одной небольшой конторе, где работаю, файловые шары бэкапятся
> раз в день (несколько терабайт). Попробуй организуй бэкап нескольких терабайт (размазанный
> по всей РФ) с периодичностью меньше часа (не критична потеря данных
> за последний час - хватит качать порнуху). И никто не плачет,
> в SLA написано 1 сутки, бабло дали на данную реализацию. А
> 1 час - это НАМНОГО дороже.Это всё ещё про кеширование или уже просто про ненужность работы вашей конторы?
Очевидно ваша контора производит "нинужно" и у меня не хватает компетенций, чтобы с вами должно спорить на тему "как грамотно просрать рабочие сутки умноженные на ~180 человек + данные по платежам + бухгалтерия + данные по торговым складам".
Возможно Rsync и Ко позволят не тянуть то, что ненужно, чтобы не тягать несколько терабайт (которые у вас фиг менялись), а только дифы. Более того, если интересоваться данной темой, а не только балаболить, можно узнать что и целые ФС можно на лету удалённо реплицировать, что вообще сводит к нулю ваши стоны про несколько терабайт.
> В одной небольшой конторе, где работаю, файловые шары бэкапятся
> раз в день (несколько терабайт).Т.е. вы "производите" террабайты данных в сутки или просто не в силах наладить сам процесс?
> Все помешались на этой надежности. Есть дофига задач, в которых потеря данных
> даже за целый час незначительна. Но при этом ни в одной
> фс впринципе не предусмотрено кэширование записи, всё обязательно пишем здесь и
> сейчас. И плевать что это создает излишние тормоза для пользователя и
> быстро изнашивает ssd.Вообще-то кеширование есть и даже настраивается. А вам, судя по всему, нужен tmpfs.
Ну давайте, назовите флаг, который можно установить, чтобы данные записывались на винчестер раз в час..., ну или при заполнении буфера, допустим в 1 Гб. Фс любая из ядра.> Если в ваших задачах не критична потеря данных за последний час - хватит качать порнуху
Порнуху уже давно никто не качает. Сейчас качают игры, 4k фильмы. Много программ создает кэш на винчестере, например браузеры, фотошоп.
Из серверной области - логи, статистика. Бывает очень большой поток данных. Т.к. вообще сбой системы ооочень редкое явление (у меня электричество вырубают максимум раз в год), а логи вещь второстепенная, то в насиловании жесткого диска не вижу смысла.> А вам, судя по всему, нужен tmpfs.
Ага, лить в tmpfs, а из tmpfs на винч. Это ужаснейший костыль. Кэширование (любое, в т.ч. записи) на 100% входит в компетенцию файловой системы.
> Ну давайте, назовите флаг, который можно установить, чтобы данные записывались на винчестер раз в час..., ну или при заполнении буфера, допустим в 1 Гб. Фс любая из ядра.vm.dirty_expire_centisecs
https://lonesysadmin.net/2013/12/22/better-linux-disk-cachin.../
А вообще, гугл в помощь. Было бы желание проблему решить, а не в комментах потрындеть.
> Ага, лить в tmpfs, а из tmpfs на винч. Это ужаснейший костыль. Кэширование (любое, в т.ч. записи) на 100% входит в компетенцию файловой системы.
_Кеширование_ есть и работает вполне адекватно. А то, что вы описываете - по часу данные в памяти держать - это вы@б, нужный паре неадекватов в мире.
Кстати, можете погуглить на тему dm-cache/bcache - может, их можно настроить на использование tmpfs в качестве кеша. Сам я их не использовал, не знаю.
> Порнуху уже давно никто не качает. Сейчас качают игры, 4k фильмы. Много
> программ создает кэш на винчестере, например браузеры, фотошоп.
> Из серверной области - логи, статистика. Бывает очень большой поток данных. Т.к.
> вообще сбой системы ооочень редкое явление (у меня электричество вырубают максимум
> раз в год), а логи вещь второстепенная, то в насиловании жесткого
> диска не вижу смысла.У вас браузер и фотошоп на сервере, зачем вам смысл?
>> Порнуху уже давно никто не качает. Сейчас качают игры, 4k фильмы. Много
>> программ создает кэш на винчестере, например браузеры, фотошоп.
>> Из серверной области - логи, статистика. Бывает очень большой поток данных. Т.к.
>> вообще сбой системы ооочень редкое явление (у меня электричество вырубают максимум
>> раз в год), а логи вещь второстепенная, то в насиловании жесткого
>> диска не вижу смысла.
> У вас браузер и фотошоп на сервере, зачем вам смысл?Ой, я попутал, у вас юзверь на SSD тормозит. Всё равно совершенно не ясно, каким боком линуксовые ФС к фотошопу и главное, как у вас всё это тормозит на SSD. Опять же хочется глянуть на вашу персональную статистику по вылету SSD из-за износа.
Я уже молчу про то что фотографам и прочим ребятам РЕАЛЬНО использующим проф. инструмент для обработки избражений будет весьма обидно потерять овердофига работы только потому, что кого-то достало что "все помешались на надёжности".
Я вам открою страшную тайну: задача файловой системы - ХРАНИТЬ данные
> Но при этом ни в одной фс впринципе не предусмотрено кэширование записи, всё обязательно пишем здесь и сейчас.что за бред несёшь, во многих, если не всех, юниксоподобных ОС запись идёт через кеш который настраивается.
Пруф в студию
технически - он прав.
просто в разных ОС и что важнее - в разных ФС(и реализации оных под разные оные и билды оных, что важнее) - оно реализовано Иначе, порой.
Так есть еще и кеш самой железки - так называемый буфер и writeback кеширование.
Дэн Лу фанатик - маразматик. Все ведутся, никто не оценивает положение вещей объективно. Люда - вам не нужна такая безопасность. Ситуаций, когда требуется сохранять всё и сразу можно по пальцам пересчитать. В основном это работа с финансовыми данными. В остальных случаях потеря данных за 5-10 минут раз в год абсолютна не критична. Сбои происходят очень редко, и из-за этого насиловать диск каждой транзакцией бессмысленно.
EXT4 + data-journal и забудьте о проблемах. Познавательно.
data-journal снижает производительность иногда на порядок
Прежде всего - это надежность!
Иногда снижает, иногда повышает, фрагментация точно падает.
За счет того что запись происходит цельным куском по размеру журнала?
> EXT4 + data-journal и забудьте о проблемах. Познавательно.Нет уж. Мы будем как-нибудь ZFS пользовать, а для скорости записи ZIL на SLC SSD вынесем.
А вы сидите на своих устаревших технологиях.
Сам ты устаревший бздун! BTRFS делает во все щели вашу ZFS, и у нас она работает просто великолпено, даже нет таких багов как у бздунов!
Когда она упадет, вы будите ныть в оффлайне и без работы.
Испытываю бтрфс на себе, 2 года - полёт нормальный. После выключений питания поднимается. Я прекрасно понимаю, что рискую результатами 1-3 днями своей работы, но ничего не происходило.
> После выключений питания поднимается.Такое даже FAT умеет.
https://ru.wikipedia.org/wiki/%D0%A1%D1%...
