Как в btrfs отключить журналирование
Лишь дал подозрение, что если есть data=ordered, то может есть и data=writeback.А что такое data=writeback когда используется COW?
COW - это copy-on-write? Я в том числе из-за него и решил использовать btrfs. Чем его наличие мешает не использовать журналирование? Это же совершенно разные вещи, насколько я понимаю.
Вроде как данные сразу на диск сразу записываются, а потом правятся метаданные. Зачем данные могут быть в журнале — я не вижу. Или я чего-то сильно недопонимаю.
насколько я понял, copy-on-write имеет место быть когда я копирую файл в пределах раздела. При этом реальная копия не создаётся, хотя извне кажется, что файлы разные. Когда же я хочу один из файлов изменить, на диск записывается только отличающаяся часть файлов. То есть это просто для уменьшения объёмов сделано, ну и чтобы лишний раз не производить реальную запись данных.
нет, применительно к btrfs это значит что при изменении файла создаётся его полная копия
ужас!
А ч0, есть какие-нибудь данные по поводу того, насколько можно продлить жизнь этим устройствам путем всяких извращений? Т.е. вот если ничего особо не настраивать, пару годков протянет Vertex II, хотя конфиги для syslog-ng я уже прибил, пишет в один файл
?
А ч0, есть какие-нибудь данные по поводу того, насколько можно продлить жизнь этим устройствам путем всяких извращений? Т.е. вот если ничего особо не настраивать, пару годков протянет Vertex II, хотя конфиги для syslog-ng я уже прибил, пишет в один файл
?при изменении файла создаётся его полная копияЧто за жесть? То есть если писать в большой файл понемногу (логи, например то будут записываться каждый раз гигабайты информации? Это не только будет смерть для ssd, но и для hdd будет огромной брешью в производительности.
скорость зависит от шаблона. зато отменная надёжность, низкая фрагментированность и снапшоты делать элементарно.
ну и это не единственный способ изменения файлов в btrfs. append возможно реализовано более эффективно. но для файлов меньше мегабайта это как правило оправдано.
ну и это не единственный способ изменения файлов в btrfs. append возможно реализовано более эффективно. но для файлов меньше мегабайта это как правило оправдано.
Для ssd значит cow - это плохая идея. Там ведь скорость случайного доступа высокая, поэтому во фрагментации нет ничего страшного. А лишний раз записывать данные - плохо.
Может быть тогда "-o ssd" отключает cow?
Если нет, то похоже лучше ext4 без журнала использовать, чем btrfs.
Может быть тогда "-o ssd" отключает cow?
Если нет, то похоже лучше ext4 без журнала использовать, чем btrfs.
В моём случае наверное в cow нет ничего страшного, так как запись будет осуществляться не чаще, чем раз в неделю и rsync всё равно будет перезаписывать, а не дописывать файлы.
иметь read-only корень очень правильно ещё и с точки зрения безопасности
p.s. ставить на btrfs - это для совсем красноглазых по-моему
p.s. ставить на btrfs - это для совсем красноглазых по-моему
Гугл подсказал, что copy on write отключается с помощью опции nodatacow, так что я его, конечно, отключу.
Что будет в этом случае с журналированием?
Что будет в этом случае с журналированием?
бля 
Вот делать рут рид-онли из соображений «безопасности» — это точно красноглазие
Вот делать рут рид-онли из соображений «безопасности» — это точно красноглазие
нет, применительно к btrfs это значит что при изменении файла создаётся его полная копияДа вы что, издеваетесь? Не весь файл переписывается, конечно же, а только сектор. Ну если мы пару байт в середине удалим, то половину придётся переписать, да. Но это и без COW тоже самое.
В плане производительности это не сильно хуже чем когда запись идёт в тот же сектор. Отличается тем, что данные окажутся теперь в другом месте и метаданные нужно исправить. Т.е. и для всяких ssd over-нагрузка небольшая получается, т.к. всё равно запись производить надо. Ну разве только что на какой-нибудь убогой фс можно напрямую записать и метаданные править не надо, т.е. будет только одна запись. Но в современных фс наверняка дополнительных записей не избежать, да и не нужно этого хотеть, т.к. надёжность важнее и т.п.
Для ssd значит cow - это плохая идея. Там ведь скорость случайного доступа высокая, поэтому во фрагментации нет ничего страшного. А лишний раз записывать данные - плохо.cow вроде как не для уменьшения фрагментации нужен.
Скорее наоборот для его работы нужны дополнительные методы борьбы с ней.
насколько я понял, copy-on-write имеет место быть когда я копирую файл в пределах раздела. При этом реальная копия не создаётся, хотя извне кажется, что файлы разные.Эх, если бы это было так. Но, к сожалению, юзерспейс здесь далёк от таких деталей и тупо копирует. Хотя технически наверняка это возможно реализовать на подобных системах. Более того у zfs если делать mv между разными "файловыми системами" на одном пуле, то оно, сцука, тоже будет копироваться-удаляться, хотя технически можно сделать почти моментально.
То есть это просто для уменьшения объёмов сделано, ну и чтобы лишний раз не производить реальную запись данных.Нет, это сделано для "транзакционности", а возможность сравнительно лёгкой дедупликации — это в довесок к самому механизму идёт.
Блин, вы меня совсем запутали... 
В итоге-то cow создаёт лишние записи на диск или нет? (особенно в случае, если запись будет произвонить только rsync, который вряд ли открывает файлы в режиме append, а наверняка только перезаписывает).
Журнал при cow не нужен, поэтому в btrfs его нет, так?
В итоге-то cow создаёт лишние записи на диск или нет? (особенно в случае, если запись будет произвонить только rsync, который вряд ли открывает файлы в режиме append, а наверняка только перезаписывает).
Журнал при cow не нужен, поэтому в btrfs его нет, так?
То есть если писать в большой файл понемногу (логи, например то будут записываться каждый раз гигабайты информации?Будут записываться измененный блоки. А вообще, для SSD лучше что-нибудь типа nilfs2, хотя она все еще экспериментальная
В итоге-то cow создаёт лишние записи на диск или нет? (особенно в случае, если запись будет произвонить только rsync, который вряд ли открывает файлы в режиме append, а наверняка только перезаписывает).Не знаю как там в btrfs, но мне кажется, что особой разницы быть не должно. По крайней мере вреда не больше чем от журнала. И append тут не при чём.
Журнал при cow не нужен, поэтому в btrfs его нет, так?Таких тонкостей я не знаю. Может быть и нет его, а может быть и используется для метаданных или ещё для чего.
В википедии про btrfs написано про какой-то журнал, который для оптимизации используется, чтобы не делать несколько сложных операций, если их можно будет потом редуцировать.
А вообще, для SSD лучше что-нибудь типа nilfs2Тоже COW, кстати. А чем лучше?
дадада, поясните, всегда интересно
Тоже COW, кстати. А чем лучше?Да тем же, только проще. Лично я резко предубежден против ZFS-like ФС; то, чего реально не хватает в текущих майнстримных ОС в linux — это снапшотов ФС, которые отлично ложатся на COW идеологию. Снапшоты LVM, конечно, выручают, но они тормозные дюже: я лично не могу использовать более трех без заметных тормозов. Однако, это оффтопик
COW хорошо тем, что при изменении файла запись всегда (ну, почти) будет происходить в сектор с другим LBA, а это значит — более равномерный износ ячеек. Хотя остается нерешенным вопрос о взаимодействии логики ФС и контроллера.
без cow кстати и data-checksumming не работает
будет происходить в сектор с другим LBA, а это значит — более равномерный износ ячеекА на этот счёт я всегда думал, что всякие не-сырые флешки имеют контроллер, который сам мапит записи равномерно.
Лично я резко предубежден против ZFS-like ФСЭто ты зря. Там много очень хороших и правильных идей. Некоторые из них плохо ложатся на текущую модель работы с дисками-файловыми системами. Но это не повод отказываться от прогресса.
Хотя для какой-нибудь флешки zfs наверное всё же будет иметь слишком большой административный оверхед. Тут, да, я вижу у nilfs плюсы в виде просты использования.
Там много очень хороших и правильных идей.Назови их, кроме снапшотов и того, что дублирует функционал LVM.
Мое личное мнение: уровень манипулирования блочными устройствами не должен быть частью ФС. ZFS — монстр, возжелавший загрести под себя все. Такой прогресс нам не нужен©
Хорошая ФС была у Tru64 UNIX - AdvFS.
Если я не ошибаюсь ее недавно отдали в свободное плавание.
Если я не ошибаюсь ее недавно отдали в свободное плавание.
Назови их, кроме снапшотов и того, что дублирует функционал LVM.Это не копирование функционала LVM. То, что у нас "внизу" лежит совместно используемый пул блоков — это очень хорошо. Т.к. позволяет делать очень удобные вещи — добавлять, удалять место, динамически перераспределять размеры файловых систем, те же снапшоты и т.д. и т.п. LVM про другое, он выдаёт блочные устройства, а не пул блоков. Именно поэтому zfs-у и приходится реализовывать подобный функционал. Это на сколько я представляю картину.
Мое личное мнение: уровень манипулирования блочными устройствами не должен быть частью ФС. ZFS — монстр, возжелавший загрести под себя все. Такой прогресс нам не нужен©
Хорошая ФС была у Tru64 UNIX - AdvFS.Хмм. COW, нет. Так что не Tru.
добавлять, удалять место, динамически перераспределять размеры файловых системЭто все есть в LVM, как же он работает, если ты говоришь, что он работать не может? Я тоже могу назвать VG "пулом блоков", откуда их можно брать и присоединять к LV или, наоборот, отнимать их от LV. Да, требуются ФС, которые умеют изменять свой размер, но таких в продакшене явно больше одной. Плюс уровни рейда и шифрование блочных устройств (ах, прости, "пула блоков") — все есть в LVM.
Я еще раз повторю, что единственное, что нужно сделать на уровне ФС, по моему мнению, это снапшоты. И идея constant snapshotting (кстати, ZFS это умеет?) — это очень хорошая идея, на уровне того, что в линуксе вся свободная память используется под дисковый кэш. В самом деле, почему бы не использовать свободное место на накопителе, чтобы иметь "историю" изменений (nilfs2 сейчас) и, возможно, откатиться в прошлое (writable snapshots, nilfs2 такое пока не умеет)?
Это все есть в LVM, как же он работает, если ты говоришь, что он работать не может? Я тоже могу назвать VG "пулом блоков", откуда их можно брать и присоединять к LV или, наоборот, отнимать их от LV. Да, требуются ФС, которые умеют изменять свой размер, но таких в продакшене явно больше одной. Плюс уровни рейда и шифрование блочных устройств (ах, прости, "пула блоков") — все есть в LVM.Может я чего-то и не понимаю. Но всё же то, что как это выглядит в zfs и как это выглядит в LVM — мне кажется это совсем разные уровни. В LVM это всё кажется как-то более статичным. Ну и к тому же (да, в том числе из-за снапшотов) zfs трудно отвязать от этого уровня. Это будет уже не то. Тут изменение размера ФС — это не изменение структур файловой системы, перетряска данных и т.п., это просто изменение параметра сколько места ей можно выделять. Блоки разных файловых систем лежат в одной каше, а не на ненужном дополнительном промежуточном слое виртуальных блочных устройств, который предоставляет LVM. Именно то, что оно исользует этот блочный пул напрямую без промежуточных слоёв делает саму файловую систему более гибким объектом.
Ну в общем в моём представлении это всё же разные вещи. Файловая систем zfs обращается вниз за блоком, а "обычная" файловая система обращается вниз за блочным устройством. Т.е. изначально уже органичиваемся определённым набором блоков. А изменить характеристики блочного устройства уже сложнее, т.к. это повлечёт изменения в том наборе блоков, который нам предоставлен, а мы к этому привязаны.
Я еще раз повторю, что единственное, что нужно сделать на уровне ФС, по моему мнению, это снапшоты. И идея constant snapshotting (кстати, ZFS это умеет?) — это очень хорошая идея, на уровне того, что в линуксе вся свободная память используется под дисковый кэш. В самом деле, почему бы не использовать свободное место на накопителе, чтобы иметь "историю" изменений (nilfs2 сейчас) и, возможно, откатиться в прошлое (writable snapshots, nilfs2 такое пока не умеет)?Да, видел это у nilfs. Штука прикольная. У zfs вроде как нет такой функции, только если руками снапшотить её постоянно.
Но как я думаю это не потребует серьёзных вмешательств для реализации этой функции.(кстати, ZFS это умеет?)К сожалению, она не умеет многого, что могла бы. Но это не делает её плохой, т.к. другие не умеют ещё больше.
К сожалению, она не умеет многого, что могла бы. Но это не делает её плохой, т.к. другие не умеют ещё больше.Не-не-не, она и так уже нарушает больше, чем стоит: декомпозицию как средство решения сложных задач. Я вижу такую аналогию: скажем, отказ от уровней защиты в процессорах тоже сделает что-то эффективнее, проще и т.п., однако нарушая изоляцию, мы открываем огромное число возможностей сделать ошибку, случайно или намеренно.
ZFS может хороша как прототип для обкатки того, что нужно и актуально в реальных системах, но свои данные лично я ей никогда не доверю. Впрочем, насчет btrfs у меня тоже сильные сомнения.
Не-не-не, она и так уже нарушает больше, чем стоит:Я не имею в виду ещё что-то нарушать. Я имею в виду фичи, которые возможны на существующей "архитектуре".
декомпозицию как средство решения сложных задач. Я вижу такую аналогию: скажем, отказ от уровней защиты в процессорах тоже сделает что-то эффективнее, проще и т.п., однако нарушая изоляцию, мы открываем огромное число возможностей сделать ошибку, случайно или намеренно.Блин. Так там есть декомпозиция. Только там "разрез" в другом месте. И мне кажется, что в хорошем. И наверное если смотреть целую картину, то там не только место разреза отличается, а даже путь по-другому идёт, но он декомпозирован.
Почему это вообще только LVM может существовать, а другие типа занимаются не своим делом? А как же конкуренция? Поверх zpool-ов, кстати, можно тоже блочные девайсы сделать. И это есть и используется "на стороне".
ZFS может хороша как прототип для обкатки того, что нужно и актуально в реальных системах, но свои данные лично я ей никогда не доверю. Впрочем, насчет btrfs у меня тоже сильные сомнения.А я наоборот в плане "доверить данные" сейчас лучше сделаю zfs over fuse (к сожалению пока так) чем какую-нибудь другую ФС.
Блин. Так там есть декомпозиция. Только там "разрез" в другом месте.
В каком месте? В том, что там придумали ФС, которая может работать с заранее неопределенным числом блоков, и хранилище этих блоков? И еще додумались слить это вместе? Что мешает развивать эти фичи в рамках разных слоев абстракции — FS & VM? Нет, ZFS, как и java, и openoffice — это какие-то ужасающие монстры, тяжелые, неповоротливые, прожорливые. Нам такой хоккей не нужен! Ⓒ
А я наоборот в плане "доверить данные" сейчас лучше сделаю zfs over fuse (к сожалению пока так) чем какую-нибудь другую ФС.Не, ну восторженные хомячки для тестирования нужны, кто ж отрицает?
декомпозицию как средство решения сложных задачимеющаяся декомпозиция на уровни придумана лет 40 назад и плохо описывает современные системы и задачи
в частности "блочное устройство" - сейчас уже нет такого, что есть последовательность пронумерованных физических секторов: например, если массив дисков, то там можно нумеровать блоки по-разному, а общее количество блоков меняется во времени, а задачи таковы, что можно это использовать; во флешках при чтении и при записи разный размер физических блоков и тому подобные штуки
В каком месте? В том, что там придумали ФС, которая может работать с заранее неопределенным числом блоков, и хранилище этих блоков?Ну может быть не надо быть гением, чтобы это придумать, но они это сделали вроде как первые.
И еще додумались слить это вместе?Если они это реализовали в одном продукте, то это не значит, что склеили. Им надо было подождать пока другие реализуют отдельно?
Что мешает развивать эти фичи в рамках разных слоев абстракции — FS & VM?Так я уже сказал, что ничто не мешает их отдельно использовать. И оно используется уже сейчас.
Ну может быть не надо быть гением, чтобы это придумать, но они это сделали вроде как первые.Это ничего не доказывает. Возможно, так не делали просто потому, что так не стоит делать.
Если они это реализовали в одном продукте, то это не значит, что склеили. Им надо было подождать пока другие реализуют отдельно?
Они могут делать что угодно, опять-таки это не доказательство, что так надо делать и так делать правильно
Так я уже сказал, что ничто не мешает их отдельно использовать. И оно используется уже сейчас.
Т.е. ZFS — это НЕ фс, а комбайн из ФС, менеджера томов и менеджера носителей — ч.т.д. Возможно, для систем, где нет этих слоев по отдельности это и хорошо, но в линуксе все это уже есть по отдельности и надо совершенствовать свои инструменты.
в частности "блочное устройство" - сейчас уже нет такого, что есть последовательность пронумерованных физических секторов: например, если массив дисков, то там можно нумеровать блоки по-разному, а общее количество блоков меняется во времени, а задачи таковы, что можно это использовать; во флешках при чтении и при записи разный размер физических блоков и тому подобные штукиЭто бла-бла-бла, а не аргументы. Принцип хранения информации не менялся много десятков лет — рейды, носители только для чтения, носители последовательного доступа, горячая замена носителей — все это уже существует давным-давно. Назови хоть один принципиально новый носитель, не поддерживающий концепцию адресации отдельного блока хранения.
угу, ZFS это какой-то ужас, они многократно переплюнули XFS по бессмысленной сложности.
но многотомные фс действительно лучше интегрировать внутрь,
выделение тут слоя предоставляющего абстрактный блок-девайс добавляет кучу неразрешимых проблем с производительностью и управлением.
dm/md хорошо выглядят пока не нужно что-то поменять на лету, тут-то и начинается сад граблей.
но многотомные фс действительно лучше интегрировать внутрь,
выделение тут слоя предоставляющего абстрактный блок-девайс добавляет кучу неразрешимых проблем с производительностью и управлением.
dm/md хорошо выглядят пока не нужно что-то поменять на лету, тут-то и начинается сад граблей.
Ё-моё, не думал, что здесь разгорится ФС-срач.
Снапшоты, data-checksumming, динамическое перераспределение размеров ФС, история изменений файлов, слои абстракции для блочных устройств... зачем всё это?! Мне это всё никогда не понадобится. Я просто хочу быструю ФС, которая бы минимально изнашивала SSD-носитель при обозначенной в первом посте схеме использования.
Я всего лишь где-то прочитал, что btrfs сейчас обходит по производительности ext4, а также, что у неё есть опция монтирования -o ssd, о которой написано только загадочная фраза "There are some optimizations for SSD drives, and you can enable them by mounting with -o ssd", поэтому решил, что использование btrfs будет неплохой идеей. Я также почитал про файловые системы специально для ssd jffs, yaffs, но решил, что во-первых, они слишком сыры и не факт, что вообще будут поддерживаться, во-вторых, в ssd же есть специальный контроллер, скрывающий внутреннее устройство, перераспределяющий сектора, чтобы уменьшить износ и т. п., таким образом, что файловой системе недоступно влияние на низкоуровневые операции, что бы позволило производить оптимизации специально для ssd, а значит нет смысла использовать специализированные фс. nilfs2, я так понял, тоже к ним относится.
Снапшоты, data-checksumming, динамическое перераспределение размеров ФС, история изменений файлов, слои абстракции для блочных устройств... зачем всё это?! Мне это всё никогда не понадобится. Я просто хочу быструю ФС, которая бы минимально изнашивала SSD-носитель при обозначенной в первом посте схеме использования.
Я всего лишь где-то прочитал, что btrfs сейчас обходит по производительности ext4, а также, что у неё есть опция монтирования -o ssd, о которой написано только загадочная фраза "There are some optimizations for SSD drives, and you can enable them by mounting with -o ssd", поэтому решил, что использование btrfs будет неплохой идеей. Я также почитал про файловые системы специально для ssd jffs, yaffs, но решил, что во-первых, они слишком сыры и не факт, что вообще будут поддерживаться, во-вторых, в ssd же есть специальный контроллер, скрывающий внутреннее устройство, перераспределяющий сектора, чтобы уменьшить износ и т. п., таким образом, что файловой системе недоступно влияние на низкоуровневые операции, что бы позволило производить оптимизации специально для ssd, а значит нет смысла использовать специализированные фс. nilfs2, я так понял, тоже к ним относится.
От журнала достаточно много вреда, встречаются отзывы, что из-за него ssd быстро умирал, поэтому-то я и хочу его отключить. Таким образом, цитата ничего не говорит о вреде от cow. Это всё равно, что говорить, что не стоит бояться наводнения, так как вреда от него не больше, чем от землетрясения.
По крайней мере вреда не больше чем от журнала
Имеется в виду раздел "Log tree" в английской версии? Насколько я понял из этого абзаца, он как раз и создаст двойную запись на диск вместо одинарной. Поэтому его необходимо отключить.
В википедии про btrfs написано про какой-то журнал, который для оптимизации используется, чтобы не делать несколько сложных операций, если их можно будет потом редуцировать.
Контроллер сам распределит равномерно при записи, так что, насколько я понимаю, ничего в данном случае cow не даст ни положительного, ни отрицательного.
будет происходить в сектор с другим LBA, а это значит — более равномерный износ ячеек
Лучше тем, что там сохраняется история в свободном месте и можно делать снапшоты? Первое черевато опять же лишними записями, а второе, как я уже сказал, мне не нужно. Так что скорее хуже, чем лучше.
А вообще, для SSD лучше что-нибудь типа nilfs2
Да наплевать на отказоустойчивость: не проблема загрузиться с альтернативного корня, что на hdd и запустить ещё раз rsync.
ZFS может хороша как прототип для обкатки того, что нужно и актуально в реальных системах, но свои данные лично я ей никогда не доверю. Впрочем, насчет btrfs у меня тоже сильные сомнения.
Назови хоть один принципиально новый носитель, не поддерживающий концепцию адресации отдельного блока хранения.Поддерживают, но хреново, так как эта модель уже неадекватна.
Например, если в рейде заменить диск и поставить большего размера, чем был, то его часть окажется неадресуемой - то есть адресация поддерживается не полностью.
Или контроллеры флеша реализуют внутри себя изрядную часть логики ФС, вплоть до того, что думают, что в начале у них лежит FAT.
Например, если в рейде заменить диск и поставить большего размера, чем был, то его часть окажется неадресуемой - то есть адресация поддерживается не полностью.А как ты предполагаешь можно поступить в случае raid1 с неравными по объемам дисками? Неужели ZFS это как-то решает, кроме как не использовать кусок диска?
С другой стороны, stripe в LVM можно сделать на dos-разделах, а остатки использовать как-то по-иному. Непонятно, чем ZFS здесь может быть лучше
использование btrfs будет неплохой идеейесть и другое мнение, что btrfs - "completely broken"
http://lkml.org/lkml/2010/6/18/144
http://www.mail-archive.com/linux-vger.kernel.org/msg0...
угу, ZFS это какой-то ужас, они многократно переплюнули XFS по бессмысленной сложности.мне кажется, или ZFS таким получился (я про Solaris конечно) по причине отсутствия у Sun нормального LVM?
есть и другое мнение, что btrfs - "completely broken"ба, это-же Шишкин! ты чего от него ещё хотел услышать?
Я просто хочу быструю ФС, которая бы минимально изнашивала SSD-носитель при обозначенной в первом посте схеме использования.При монтировании в ro любая будет минимально изнашивать
Я думаю, что ext2 подойдёт - там нет журнала и всех этих лишних COW.
При монтировании в ro любая будет минимально изнашиватьДа, но надо чтобы она минимально изнашивала и в моменты запуска rsync.
Я думаю, что ext2 подойдёт - там нет журнала и всех этих лишних COW.А если примотрировать ext4 с опцией data=writeback, то у неё тоже не будет журнала и COW, но производительность будет выше, чем у ext2. При этом, насчёт COW я пока так и не понял вызывает она дополнительные записи или нет. А у btrfs произодительность ещё выше и COW можно отключить (если это надо вообще но я не знаю можно ли отключить Log tree.
Пичаль, в общем...
О, я нашёл в самом очевидном месте!
http://btrfs.wiki.kernel.org/index.php/Getting_started#Moun...
http://btrfs.wiki.kernel.org/index.php/Getting_started#Moun...
notreelog - This disables the tree logging used for fsync.Отлично, осталось выяснить надо отключать COW или нет.... ну и вообще есть подозрения, что ещё какая-нибудь супер-пупер технология в составе btrfs может захотель погрызть носитель.
Вот тут ssd монтировали с опциями:
nodatasum,nodatacow,nobarrier,ssd,noacl,notreelog,noatime,nodiratime
Про nodatasum прочитал - вроде да, они мне не нужны, так как rsync будет их вычислять (я его всегда с -c использую) при синхронизации и если что перезаписывать файлы с bit flips и bit rot.
Про nobarrier нифига не написано, кроме того, что фс может накрыться целиком при отключениях питания (на это пофиг). А что оно изменяет - неясно.
Ну и про nodatacow, как я уже сказал, есть сомнения. Хотя наверное стоит отключить COW из соображений, что если даже он не вызывает лишние операции i/o, то вроде как он мне ничего мне не даст, так как только при записи роляет, а у меня в основном чтение.
Так что поясните, пожалуйста, кто-нибудь про nobarrier.
nodatasum,nodatacow,nobarrier,ssd,noacl,notreelog,noatime,nodiratime
Про nodatasum прочитал - вроде да, они мне не нужны, так как rsync будет их вычислять (я его всегда с -c использую) при синхронизации и если что перезаписывать файлы с bit flips и bit rot.
Про nobarrier нифига не написано, кроме того, что фс может накрыться целиком при отключениях питания (на это пофиг). А что оно изменяет - неясно.
Ну и про nodatacow, как я уже сказал, есть сомнения. Хотя наверное стоит отключить COW из соображений, что если даже он не вызывает лишние операции i/o, то вроде как он мне ничего мне не даст, так как только при записи роляет, а у меня в основном чтение.
Так что поясните, пожалуйста, кто-нибудь про nobarrier.
>Ну может быть не надо быть гением, чтобы это придумать, но они это сделали вроде как первые.
NetApp WAFL была раньше.
NetApp WAFL была раньше.
он не вызывает лишние операции i/o, то вроде как он мне ничего мне не даст, так как только при записи роляет, а у меня в основном чтение.ты определись, хочешь оптимизировать запись, или нет
Я хочу оптимизировать запись по числу операций i/o, а не по скорости. Причём операций именно полной перезаписи файла, а не дописывания.
ну смотри, даже если ты каждый день будешь каждый сектор перезаписывать, ресурса хватит на много лет
и нефиг смотреть на результаты обычных тестов производительности, если тебя интересует только чтение
и нефиг смотреть на результаты обычных тестов производительности, если тебя интересует только чтение
А как же ограничение в 10k перезаписей? (где-то в инете находил такие данные) и то, что у многих ssd дохли через пару месяцев?
Интересно, когда у LVM появятся аналоги ZIL и L2ARC?
что у многих ssd дохли через пару месяцев?ты думаешь, многие держат их в ro?
А как же ограничение в 10k перезаписей?10000 дней - это сильно дофига, твоя система не проживёт столько
ты думаешь, многие держат их в ro?Я не знаю... но это же логичное решение, так что почему бы и нет.
10k дней... 27 лет... ну да, наверное я слишком уж парюсь
Я также почитал про файловые системы специально для ssd jffs, yaffs, но решил, что во-первых, они слишком сыры и не факт, что вообще будут поддерживатьсяОни не подходят по другой причине — они работают с сырым девайсом, без контроллера. Сами используют служебные зоны и т.п. Для обычных блочных устройств они не подойдут.
нет смысла использовать специализированные фс. nilfs2, я так понял, тоже к ним относится.Нет, nilfs предназначен для обычных блочных устройств.
Это ничего не доказывает. Возможно, так не делали просто потому, что так не стоит делать.А я не говорил, что это доказательство. Я лишь говорил, что этим не стоит их упрекать.
Т.е. ZFS — это НЕ фс, а комбайн из ФС, менеджера томов и менеджера носителей — ч.т.д.Если рассматривать весь комплекс, то да. Но это не значит, что он не состоит из частей. По 10 раз одно и то же будет повторять что ли?
Возможно, для систем, где нет этих слоев по отдельности это и хорошо, но в линуксе все это уже есть по отдельности и надо совершенствовать свои инструменты.Опять же, нету в Линуксе менеджера блоков. Есть менеджер блочных устройств.
угу, ZFS это какой-то ужас, они многократно переплюнули XFS по бессмысленной сложности.А в каких планах оно сложно с твоей точки зрения?
Я не утверждаю, что оно легко или сложно. Интересно что ты конкретно имеешь в виду?
Они не подходят по другой причине — они работают с сырым девайсом, без контроллера. Сами используют служебные зоны и т.п. Для обычных блочных устройств они не подойдут.А такие девайсы можно купить обычной розничной сети? (фцентры, олди всякие).
10k дней... 27 лет... ну да, наверное я слишком уж парюсья вот на 90Гб поставил систему, оставил половину еще под винду, но пока так и не поставил. Теоретически если все так и продолжится, то это еще в два раза продлит время службы
Вывод: винда говно и вредит железу
А такие девайсы можно купить обычной розничной сети? (фцентры, олди всякие).Я хз, не интересовался этим вопросом. Это вроде не совсем прямо потребительский товал. Т.к. там интерфейсы не USB и т.п.
Я так понимаю, что это во всяких embedded-девайсах флешки такие могут присутствовать. Ну это как я вижу это, может быть и ещё где они возникают, но я про это не знаю.кстати, если верить смарту, то после двух месяцев постоянного использования там Lifetime_writes 64 гига всего лишь. Журнал не отключал, компилял на tmpfs, ну еще сериальчики на него (tmpfs) качал по одной серии
Т.к. там интерфейсы не USB и т.п.Ну мне вообще-то SATA нужен, а не USB.
Ну хотя бы по какому ключевому слову можно понять, что там нет этого контроллера? В описании обычно пишут что есть, а не чего нет.
Lifetime_writes 64 гигаЭто, кстати, как можно соотносить с ресурсом в 10к перезаписей?
Ну мне вообще-то SATA нужен, а не USB.Какая разница. Через SATA ты тоже не получишь сырой контроллер, как я понимаю.
Ну хотя бы по какому ключевому слову можно понять, что там нет этого контроллера? В описании обычно пишут что есть, а не чего нет.
Вот чего на википедии написано http://en.wikipedia.org/wiki/Flash_memory:
In practice, flash file systems are only used for memory technology devices (MTDs which are embedded flash memories that do not have a controller.
Да, интересно было бы узнать... Может они считают данные, прошедшие через контроллер, а перезаписывается там блоками... Надо прошерстить их сайт...
Опции монтирования (в качестве устройства указать одно из блочных устройств, парные опции с/без no- в ядре 3.14):
degraded (позволяет монтировать файловую систему при отказе одного из блочных устройств)
recovery (ядро 3.2; автоматическое восстановление со сканированием подходящих предыдущих корней)
rescan_uuid_tree (ядро 3.12)
subvol=имя-подтома (монтирование поддерева; до ядра 3.2 подтом д.б. в корне)
subvolid=идентификатор-подтома (монтирование поддерева; корень имеет идентификатор 5)
device=устройство (сканировать устройство в поисках томов btrfs; только сканировать! перечислить все устройства в /etc/fstab, если initrd не выполняет "btrfs device scan")
nodatasum (для новых файлов; не обрабатывать контрольные суммы для данных)
nodatacow (для новых файлов; ускорение - 5% на последовательных операциях, значительное ускорение при работе с базами данных, также отключается сжатие и подсчёт контрольных сумм)
nobarrier (возможно разрушение всей файловой системы, а fsck примитивен; многодисковость учитывается с ядра 3.2)
max_inline=байт (максимальный размер данных, встраиваемых непосредственно в метаданные; по умолчанию 8192; для 4К страниц = 3900)
alloc_start= (начало выделения места на диске?)
thread_pool=число-параллельных-потоков (по умолчанию - min(количество-ядер+2,8), при использовании сжатия обязательно увеличить)
compress[=zlib|=lzo|=no] (lzo с ядра 2.6.39; no с ядра 3.6)
compress-force[=zlib|=lzo] (сжимать даже плохосжимаемые файлы)
ssd (оптимизация выделения блоков для SSD - сразу для всех устройств? автоматически проверяет /sys/block/*/queue/rotational; TRIM надо включать отдельно)
ssd_spread (попытка выделять большими кусками; приводит к усиленной фрагментации)
discard (выдавать команды TRIM/discard при освобождении блоков; замедлит работу для SATA до 3.1; вместо этого можно переодически использовать fstrim)
noacl
notreelog (в теории дерево журналов уменьшает количество операций записи метаданных при fsync, но на практике без него случайная запись больших файлов ускоряется в 5 раз для ядер до 3.0.2; если программа полагалась на fsync, то возможны проблемы)
flushoncommit (при завершении транзакции осуществлять все отложенные выделения блоков; в новых ядрах включено по умолчанию)
metadata_ratio=8 (распределение места на данные и метаданные было (?) фиксированно и если место под метаданные заканчивалось, а под данные - нет, то надо было поставить число поменьше; необходимо учитывать степень сжатия)
space_cache (хранение битовой карты свободного места на диске (без CoW и контрольной суммы), с 2.6.37, неустойчиво работает в RHEL7, ядро 3.10)
clear_cache (если ранее использовался space_cache и хотим от него избавиться, с 2.6.37)
nospace_cache (с ядра 3.2; вычислять битовую карту свободного места при монтировании)
enospc_debug (выдать отладочную печать при возникновении события "недостаток места на устройстве"; рекомендуется, не замедляет работу)
user_subvol_rm_allowed (позволять пользователям удалять подтома, с ядра 2.6.37)
autodefrag (запуск фоновой дефрагментации, несовместим с большими БД и образами виртуальных машин, с 3.0)
inode_cache (кешировать свободные inode, с 3.0; не рекомендуется, пока число inode не достигнет 2^64; обычное поведение - добавлять 1 для каждого нового файла, использованный inode повторно не использовать
check_int, check_int_data, check_int_print_mask=маска (ядро 3.3; проверка метаданных на ходу; замедляет работу, использовать только для отладки)
commit=секунд (30; с ядра 3.12; интервал сброса кеша записи на диск и формирования "точки отката" на случай сбоев и ошибок)
fatal_errors={bug|panic} (с ядра 3.4; хрен редьки не слаще)
skip_balance (с ядра 3.3; не возобновлять балансировку)
degraded (позволяет монтировать файловую систему при отказе одного из блочных устройств)
recovery (ядро 3.2; автоматическое восстановление со сканированием подходящих предыдущих корней)
rescan_uuid_tree (ядро 3.12)
subvol=имя-подтома (монтирование поддерева; до ядра 3.2 подтом д.б. в корне)
subvolid=идентификатор-подтома (монтирование поддерева; корень имеет идентификатор 5)
device=устройство (сканировать устройство в поисках томов btrfs; только сканировать! перечислить все устройства в /etc/fstab, если initrd не выполняет "btrfs device scan")
nodatasum (для новых файлов; не обрабатывать контрольные суммы для данных)
nodatacow (для новых файлов; ускорение - 5% на последовательных операциях, значительное ускорение при работе с базами данных, также отключается сжатие и подсчёт контрольных сумм)
nobarrier (возможно разрушение всей файловой системы, а fsck примитивен; многодисковость учитывается с ядра 3.2)
max_inline=байт (максимальный размер данных, встраиваемых непосредственно в метаданные; по умолчанию 8192; для 4К страниц = 3900)
alloc_start= (начало выделения места на диске?)
thread_pool=число-параллельных-потоков (по умолчанию - min(количество-ядер+2,8), при использовании сжатия обязательно увеличить)
compress[=zlib|=lzo|=no] (lzo с ядра 2.6.39; no с ядра 3.6)
compress-force[=zlib|=lzo] (сжимать даже плохосжимаемые файлы)
ssd (оптимизация выделения блоков для SSD - сразу для всех устройств? автоматически проверяет /sys/block/*/queue/rotational; TRIM надо включать отдельно)
ssd_spread (попытка выделять большими кусками; приводит к усиленной фрагментации)
discard (выдавать команды TRIM/discard при освобождении блоков; замедлит работу для SATA до 3.1; вместо этого можно переодически использовать fstrim)
noacl
notreelog (в теории дерево журналов уменьшает количество операций записи метаданных при fsync, но на практике без него случайная запись больших файлов ускоряется в 5 раз для ядер до 3.0.2; если программа полагалась на fsync, то возможны проблемы)
flushoncommit (при завершении транзакции осуществлять все отложенные выделения блоков; в новых ядрах включено по умолчанию)
metadata_ratio=8 (распределение места на данные и метаданные было (?) фиксированно и если место под метаданные заканчивалось, а под данные - нет, то надо было поставить число поменьше; необходимо учитывать степень сжатия)
space_cache (хранение битовой карты свободного места на диске (без CoW и контрольной суммы), с 2.6.37, неустойчиво работает в RHEL7, ядро 3.10)
clear_cache (если ранее использовался space_cache и хотим от него избавиться, с 2.6.37)
nospace_cache (с ядра 3.2; вычислять битовую карту свободного места при монтировании)
enospc_debug (выдать отладочную печать при возникновении события "недостаток места на устройстве"; рекомендуется, не замедляет работу)
user_subvol_rm_allowed (позволять пользователям удалять подтома, с ядра 2.6.37)
autodefrag (запуск фоновой дефрагментации, несовместим с большими БД и образами виртуальных машин, с 3.0)
inode_cache (кешировать свободные inode, с 3.0; не рекомендуется, пока число inode не достигнет 2^64; обычное поведение - добавлять 1 для каждого нового файла, использованный inode повторно не использовать
check_int, check_int_data, check_int_print_mask=маска (ядро 3.3; проверка метаданных на ходу; замедляет работу, использовать только для отладки)
commit=секунд (30; с ядра 3.12; интервал сброса кеша записи на диск и формирования "точки отката" на случай сбоев и ошибок)
fatal_errors={bug|panic} (с ядра 3.4; хрен редьки не слаще)
skip_balance (с ядра 3.3; не возобновлять балансировку)
Оставить комментарий
dangerr
или перенести журнал на другой раздел?Что-то гугл не особо помог в этом вопросе. Лишь дал подозрение, что если есть data=ordered, то может есть и data=writeback.
И какие ещё нужно, кроме -o ssd с ней сделать манипуляции, чтобы уменьшить количество записей на диск?
Использовать предполагается так:
Корень вынесу на btrfs и ssd и монтировать буду в ro. Его полная копия будет на hdd. Обновления будут проходить на копии в chroot, потом корень перемонтируется в rw и синхронизируется с копией через rsync, затем снова перемонтируется в ro.
То есть журнал и какая либо сохранность данных мне вообще не нужны.