Комментарии 113
Да в линуксе полно няшных свистелок, которые по-умолчанию выключены. Хочешь свистелок — будь добр пересобери ядро, пропатч исходники, поставь пакеты и напиши такие-то конфиги.
Сжатие памяти, снэпшоты фс, кэш hdd на ssd, CoW, апдейт ядра без перезапуска и тысячи подобных штук. Технологии есть — внедрения нет.
Сжатие памяти, снэпшоты фс, кэш hdd на ssd, CoW, апдейт ядра без перезапуска и тысячи подобных штук. Технологии есть — внедрения нет.
IMHO, те, кому эти няшные свистелки действительно нужны, знают об их наличии и о том, как их включить (или способны найти способ их включить). Остальным либо не так уж и нужно, либо и вовсе опасно давать такое по умолчанию.
У нас народ про network namespaces узнал год назад, когда я предложил их использовать для поднятия нескольких идентичных копий сервиса на одной машине. Хотя в iproute они присутствуют уже давно, даже пересобирать ничего не надо. Вот так "надо" было.
имхо, дело только в целесообразности. Все это решается на уровне дистрибутива (да и практически все они кастомизируют ядро)
НЛО прилетело и опубликовало эту надпись здесь
>тысячи подобных штук
Огласите весь список, пожалуйста. Или хотя бы где посмотреть по частям?
Огласите весь список, пожалуйста. Или хотя бы где посмотреть по частям?
Вместо /bin/cp положить баш-скриптик, который будет вызывать /bin/cp_old, добавляя к параметрам --reflink=auto?
Месье знает толк.
Обычно справляются простым alias
Обычно справляются простым alias
Однажды, ещё на Solaris 8 (или 9), я положил "скриптик", который вызывал системную команду внутри. И перезагрузил сервак.
После 2хчасового интенсивного секса с незагружающейся системой (в итоге всё же обошлось без переустановки) я подумал, что больше так делать не стоит...
А потом при следующем апдейте /bin/cp все сломается, и никто про этот костыль не вспомнит :)
chattr +C /dir/file скорее всего не заработает на btrfs. В документации на chattr написано что работает только на директориях и пустых файлах. Таким образом нужно поставить +С на директорию и скопировать файл без reflink.Помимо того в документации на btrfs раньше было написано, что в некоторых пределах, ядро пытается делать CoW при записи одинаковых данных. Сейчас не могу найти.
Насколько я понял, это работает на НОВЫХ файлах, а не на обязательно пустых.
Отчасти верно, если на директории стоит +C, то он будет применяться к новым файлам в ней. Или вы можете в своем приложении при создании файла выставить этот атрибут.
Я имел ввиду, что в любой директории (даже, если у неё нет флага +C), если на любом новом файле выставить +С, то именно для этого файла CoW при изменениях будет отключена. Я так понял документацию.
И у меня есть подозрения, что даже не на новых файлах +С сработает. Там вся разница в том, что для CoW переписываются чексуммы в метаданных, а при его отсутствии они не считаются.
For btrfs, the 'C' flag should be set on new or empty files. If it is set on a file which already has data blocks, it is undefined when the blocks assigned to the file will be fully stable. If the 'C' flag is set on a directory, it will have no effect on the directory, but new files created in that directory will have the No_COW attribute.
И у меня есть подозрения, что даже не на новых файлах +С сработает. Там вся разница в том, что для CoW переписываются чексуммы в метаданных, а при его отсутствии они не считаются.
разве в бтрфс cow отключена по умолчанию?
Отключено в команде cp. В статье об этом.
Статья однобокая.
1. Акцент почему-то только на cp, тогда как всякие менеджеры виртуальных машин (тот же VirtualBox или libvirt), файловые менеджеры с GUI, а также сетевые хранилища типа NextCloud не используют cp. Еще стоило бы посмотреть на ситуацию с точки зрения разработчика — да, на Си сделать reflink легко, а на другом языке?
2. Акцент сделан на Linux и ни слова не сказано про macOS, где copy on write тоже есть.
1. Акцент почему-то только на cp, тогда как всякие менеджеры виртуальных машин (тот же VirtualBox или libvirt), файловые менеджеры с GUI, а также сетевые хранилища типа NextCloud не используют cp. Еще стоило бы посмотреть на ситуацию с точки зрения разработчика — да, на Си сделать reflink легко, а на другом языке?
2. Акцент сделан на Linux и ни слова не сказано про macOS, где copy on write тоже есть.
2. Акцент сделан на Linux и ни слова не сказано про macOS, где copy on write тоже есть.
И действительно странно! Почему в статье «Что не так с Copy-on-Write под Linux» ни слова про macOS?
Да, странно! Без сравнения с другими решениями, не будет оснований называть статью «Что не так с Copy-on-Write под Linux». Будет что-то вроде «Что не так с Copy-on-Write вообще, на примере реализации в Linux».
Вы меня простите, конечно, но ваша логическая цепочка кажется мне, как минимум, странной.
Вы пеняете на то, что в статье «Что не так с Copy-on-Write под Linux», дословно, «акцент сделан на Linux». На чем, простите, должен быть сделан акцент в статье с таким заголовком?
Если бы статья называлась «Что не так с Copy-on-Write под Linux, и что там в macOS», например, я бы тоже удивился, почему в ней ни слова про macOS. Если бы в заголовке стояло «Что не так с Copy-on-Write под Linux в сравнении с альтернативными ОС», мне так же было бы любопытно, почему другие ОС и, в частности, macOS в статье не упоминается. Однако ожидать в статье, явно декларируемой как «статья про Linux» упоминания macOS… Ну, извините, такое себе.
И ведь текст статьи делает ровно то, что декларируется в заголовке. Он обсуждает файловые системы с CoW, существующие под Linux (казалось бы, при чем тут macOS), освещает текущее положение с CoW в дистрибутивах Linux (и здесь, вроде бы, macOS не при чем), а также строит предположения на тему «почему так получилось в Linux'е». При этом в качестве причины выдвигается мнение разработчика GNU CoreUtils, не имеющих отношения к macOS(в случае CoreUtils) и не имеющего отношения к macOS(в случае разработчика).
Ну, т.е. статья декларирует в заголовке, что разговор будет про Linux, речь идет о Linux, и откуда-то возникает претензия, что «акцент сделан на Linux/почему-то ни слова про macOS». Может быть, macOS — Linux? На всякий случай, перепроверил… Нет, не Linux…
Вы пеняете на то, что в статье «Что не так с Copy-on-Write под Linux», дословно, «акцент сделан на Linux». На чем, простите, должен быть сделан акцент в статье с таким заголовком?
Если бы статья называлась «Что не так с Copy-on-Write под Linux, и что там в macOS», например, я бы тоже удивился, почему в ней ни слова про macOS. Если бы в заголовке стояло «Что не так с Copy-on-Write под Linux в сравнении с альтернативными ОС», мне так же было бы любопытно, почему другие ОС и, в частности, macOS в статье не упоминается. Однако ожидать в статье, явно декларируемой как «статья про Linux» упоминания macOS… Ну, извините, такое себе.
И ведь текст статьи делает ровно то, что декларируется в заголовке. Он обсуждает файловые системы с CoW, существующие под Linux (казалось бы, при чем тут macOS), освещает текущее положение с CoW в дистрибутивах Linux (и здесь, вроде бы, macOS не при чем), а также строит предположения на тему «почему так получилось в Linux'е». При этом в качестве причины выдвигается мнение разработчика GNU CoreUtils, не имеющих отношения к macOS(в случае CoreUtils) и не имеющего отношения к macOS(в случае разработчика).
Ну, т.е. статья декларирует в заголовке, что разговор будет про Linux, речь идет о Linux, и откуда-то возникает претензия, что «акцент сделан на Linux/почему-то ни слова про macOS». Может быть, macOS — Linux? На всякий случай, перепроверил… Нет, не Linux…
Я добавил в статью про поддержку reflink файловыми менеджерами и про macOS (конец статьи).
Очень многие пакеты под капотом используют
Очень многие пакеты под капотом используют
cp. Я бы не стал так бескомпромиссно утверждать, что libvirt, VirtualBox, NextCloud нигде в своём коде не используют cp. Совершенно не все разработчики любят писать свои «велосипеды».Бескомпромиссное утверждение основано на том, что необоснованные вызовы system(), posix_spawn(), execve() и подобных API не пройдут ревью кода безопасниками. Каждый вызов cp — это необходимость думать, а не передадут ли в качестве одного из аргументов что-то, что cp посчитает не файлом или каталогом, а опцией. И еще, в достаточно высокоуровневых языках есть готовые функции-утилиты для рекурсивного копирования каталогов. Python: shutil.copytree().
Что не так с системой создающей у пользователя ошибочное впечатление того что файлов ДВА, в то время как файл ОДИН ?
Да, вобщем то, всё.
Неискушенные пользователи действительно могут делать бакапы ценных файлов на одной и той же файловой системе.
Копирование на ту же файловую систему — один из вариантов резервирования. Носитель может умереть не сразу, а начать сыпаться по частям. Не самый лучший, но нормальный.
Кроме бэкапленья, есть другие варианты необходимости копирования.
- Скопировать файлы и потестить что-нибудь связанное с редактированием этих файлов
- Иметь какой-нибудь шаблонный файлик, типа договора, который копируется по мере необходимости
- Иметь исходные картинки, скопировать и массово их обработать. Например, отресайзить и наложить логотип
- Брать какой нибудь файл, например скрипт, копировать и использовать его в качестве основы для другого файла.
Есть много разных случаев, когда пользователь может иметь условный "эталон" копировать его и проводить операции с копиями.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо.
Понял.
Увы, из текста постинга это не следует, поэтому список отменяется.
Но тогда это создаёт другую проблему — возможность внезапного появления кучи реальных файлов.
В случае с обработкой кучи файлов это приведёт к тому, что вместо ожидаемого уменьшения (за счёт ресайза и сжатия) занятого места будет происходить его увеличение (за счёт появления несуществовавших файлов).
Увы, из текста постинга это не следует
Вот что меня удивляет: смысл поста — это именно CoW при копировании. А вы говорите, что из текста не следует.
за счёт появления несуществовавших файлов
Они существовали. Просто при перезаписи под них начинает выделяться дополнительное место.
Они существовали. Просто при перезаписи под них начинает выделяться дополнительное место.
Осталось объяснить это конечным потребителям.
Я может чего не понимаю.
Но вот ситуация, у нас, предположим
И по какой-то причине крешится сектор диска.
Вы теряете файл не в одной ВМ или контейнере а во всех, такая себе радость на мой взгляд.
Сама фича не плохая, а то что по дефолту она выключена, на мой взгляд просто замечательно. Все кто нуждается могут включить, для прочих она скорее опасна чем полезна.
Но вот ситуация, у нас, предположим
решением для лёгких виртуальных машин и контейнеров. Ведь мы могли бы не тратить место на одинаковые файлы
И по какой-то причине крешится сектор диска.
Вы теряете файл не в одной ВМ или контейнере а во всех, такая себе радость на мой взгляд.
Сама фича не плохая, а то что по дефолту она выключена, на мой взгляд просто замечательно. Все кто нуждается могут включить, для прочих она скорее опасна чем полезна.
На ссд я что-то не сталкивался с крешем одиночных секторов. Если же говорить про тех, кто очень люьит использовать много виртуалок, то они у них живут на рейде.
Ну речь не про солидных парней с кучей виртуалок и рейдами (подозреваю хостеров).
А про обычного массового пользователя, для которого и собираются дистрибутивы с дефолтными настройками. И у которого нормой десяток докеров и пяток виртуалок. Потерять их все разом радости так же мало.
Помню была бага с XFS, когда при потере питания избирательно обнулялись незакрытые файлы. Очень было неприятно и иногда даже больно. Если бы я тогда узнал что это фича, я был бы довольно несдержан в своих словах.
А про обычного массового пользователя, для которого и собираются дистрибутивы с дефолтными настройками. И у которого нормой десяток докеров и пяток виртуалок. Потерять их все разом радости так же мало.
Помню была бага с XFS, когда при потере питания избирательно обнулялись незакрытые файлы. Очень было неприятно и иногда даже больно. Если бы я тогда узнал что это фича, я был бы довольно несдержан в своих словах.
И по какой-то причине крешится сектор диска.
В этом случае весь диск выбрасывается, а данные восстанавливаются из бэкапа.
Тем более в вашем случае, когда потерялись не самые свежие изменения в одной из ВМ, а общая часть всех ВМ, т.е. неизменённая, которая точно есть в бэкапе или там, откуда вы её скачали.
В этом случае весь диск выбрасывается, а данные восстанавливаются из бэкапа.
Вы это сейчас про обычного массового пользователя линукса? Мне кажется вы большой оптимист.
И основная то проблема даже не в том что файл погиб (его копию можно найти, скопировать), а то что вполне вероятно что без оного файла система не стартанет (виртуалка) и потребуется разбираться что там и почему. Радости не много.
Вы это сейчас про обычного массового пользователя линукса? Мне кажется вы большой оптимист.Обычный массовый рользователь линукса — это кто? У меня на предприятии несколько тысяч пользователей линукса — думаю, это и есть «обычные массовые пользователи». При любой проблеме с диском (да и при многих других) такой пользователь берёт из шкафа новый диск на салазках, вставляет его в свой компьютер взамен проблемного и работает дальше.
А если у кого-то несколько клонированных виртуальных машин, то это не массовый пользователь, а как минимум айтишник или человек в айти разбирающийся, который сознательно выбрал линукс и файловую систему с CoW, и он точно знает про бэкапы.
Обычный массовый рользователь линукса — это кто?
Обычный, это который не системный. У которого нет шкафа, а которому нужно ехать в магазин и тратить кровные.
А если у кого-то несколько клонированных виртуальных машин, то это не массовый пользователь, а как минимум айтишник
Как по мне нормальный обычный пользователь. Пусть и айтишник.
И сильно сомневаюсь что на каждый вылетевший сектор побежит в магазин тратить 200-300 баксов.
По вашим словам судить, так у каждого айтишника все личные/домашние системы на рейдах, с бэкапами в облако, резервированием интернет канала и бесперебойником зацепленном на генератор. Может такое и имеет место быть но явно не в моей реальности.
И сильно сомневаюсь что на каждый вылетевший сектор побежит в магазин тратить 200-300 баксов.Первый вылетевший сектор означает, что вслед за ним в любой момент времени вылетит второй, третий, и т.д., а значит этим диском лучше не пользоваться, так как на восстановление данных придётся потратить намного больше времени, чем стоит новый диск.
По вашим словам судить, так у каждого айтишника все личные/домашние системы на рейдах, с бэкапами в облако, резервированием интернет канала и бесперебойником зацепленном на генератор. Может такое и имеет место быть но явно не в моей реальности.Странные у вас суждения, однако.
а значит этим диском лучше не пользоваться, так как на восстановление данных придётся потратить намного больше времени, чем стоит новый диск
Почему нет? Ну потеряются, и черт с ними. Перекачают заново свои торенты например. Или вышеупомянутый докер переразвернут, или виртуалку накатят заново. Это как бы не повод тратить 200 баксов на новый диск, это не продакшен.
Ради любопытства посмотрите какое количество бу памяти и дисков скупается на али. И люди довольны и счастливы. Реальность она такая вот.
«Пусть и айтишник» знает о резервном копировании как минимум то, что его нужно делать на другой (физический) носитель. Иначк он либо не айтишник, либо ему не особо нужно содержимое диска.
Более того, айтишник, который ценит содержимое диска, работает в массиве RAID просто потому, что это и недорого, и надёжно, и производительность снижает малозаметно
Более того, айтишник, который ценит содержимое диска, работает в массиве RAID просто потому, что это и недорого, и надёжно, и производительность снижает малозаметно
А теперь вы расскажите про процент айтишников использующих резервное копирование и рэйд массивы.
Давайте не будем смешивать домашний и рабочий компьютер.
От того что содержимое диска не особенно нужно и его вполне можно востановить не возникает особенно сильное желание этим заниматься. Притом как правило в не самый удачный момент.
ЗЫ А у ж сколько примеров как бэкапы делались на тот же раздел что и данные, сколько было незапланированных дроптэйблов и датабэйсов и прочего подобного. Не стоит идеализировать людей вообще и айтишников в частности.
Давайте не будем смешивать домашний и рабочий компьютер.
От того что содержимое диска не особенно нужно и его вполне можно востановить не возникает особенно сильное желание этим заниматься. Притом как правило в не самый удачный момент.
ЗЫ А у ж сколько примеров как бэкапы делались на тот же раздел что и данные, сколько было незапланированных дроптэйблов и датабэйсов и прочего подобного. Не стоит идеализировать людей вообще и айтишников в частности.
По моему опыту рейд-массив повышает производительность)
На ноутбуке сложно RAID поднять
Будет, если например не хватит места в процессе.
А вы знаете что Docker поддерживает btrfs для своего хранилища? Эту опцию нужно включать.Лучше не надо. btrfs graphdriver в Docker кривоват и имеет несколько багов пара из которых фатальны. Особенно опасно реализованы квоты. Пару лет назад я пытался его запатчить но всё руки не доходят пропихнуть в апстрим.
Во общем сейчас связка OverlayFS поверх btrfs надёжнее.
Что такое graphdriver?
А, простите это термин из внутренностей docker.
В конфигах это называется storage-driver.
В конфигах это называется storage-driver.
не знаю про какие квоты Вы, но сами квоты в btrfs использовать по факту нельзя.
когда я включил qouta (включил функцию — btrfs quota enable, но не выставил ограничений) на btrfs и использовал это для того чтобы смотреть размеры снапшотов (btrfs-du) — всё было красиво, но когда я попробовал удалить один снапшот — btrfs-cleaner сожрал всё память и дальше у меня было увлекательных несколько дней в поисках решений. Баг до сих пор присутствует
когда я включил qouta (включил функцию — btrfs quota enable, но не выставил ограничений) на btrfs и использовал это для того чтобы смотреть размеры снапшотов (btrfs-du) — всё было красиво, но когда я попробовал удалить один снапшот — btrfs-cleaner сожрал всё память и дальше у меня было увлекательных несколько дней в поисках решений. Баг до сих пор присутствует
Ссылка дана на баг-трекер Red Hat. А в баг-трекере Btrfs что говорят про это?
Обнаружил в Changelog Btrfs. Ядро 5.0. Март 2019 г.
«fix a crash due to a race when quotas are enabled during snapshot creation»
Похоже на баг, о котором вы говорили.
«fix a crash due to a race when quotas are enabled during snapshot creation»
Похоже на баг, о котором вы говорили.
Я в августе этого года это делал. Скачал archiso свежий на тот момент. И.е. ядро было 5.x (точнее не помню), и проблема продолжала наблюдаться. При монтировании fs, через примерно час 2гб ОЗУ заканчивались и все вставало колом. Я перезагружал, монтировал и наблюдал опять процесс btrfs-cleaner который бух по памяти. Потом узнал про квоты, выключил и как то помогло. Тоже не с первого раза получилось.
К сожалению всего алгоритма я не записал, но с проблемой бился несколько дней в свободные часы (домашний сервер на 6 разных дисках btrfs разделом на 14 Тб).
Т.е. я полагаю, что проблема не решена. Но это отдельный кейс, который по умолчанию выключен
На мой взгляд, проблема CoW-FS отнюдь не в coreutils. А в том что надо учить весь софт, занимающийся в том или ином виде копированием файлов, вызывать новый syscall.
А ещё CoW — не серебряная пуля, и на части сценариев будет работать хуже/медленнее чем не-CoW.
В OS X подобная опция команды cp – это '-c'.
Она включает использование атомарного системного вызова clonefile(), который создаёт запись в файловой системе о новом файле, в котором ссылки на блоки данных идентичны оригиналу. Копируются атрибуты и расширенные атрибуты файла, записи списков контроля доступа (ACL), за исключением информации о владельце файла и со сбросом setuid/setgid битов. Работает в пределах одной файловой системы, требует поддержки файловой системой (атрибут ATTR_VOL_CAPABILITIES, флаг VOL_CAP_INT_CLONE).
Поддерживается начиная с OS X 10.12 (Sierra) и только в файловой системе APFS.
Она включает использование атомарного системного вызова clonefile(), который создаёт запись в файловой системе о новом файле, в котором ссылки на блоки данных идентичны оригиналу. Копируются атрибуты и расширенные атрибуты файла, записи списков контроля доступа (ACL), за исключением информации о владельце файла и со сбросом setuid/setgid битов. Работает в пределах одной файловой системы, требует поддержки файловой системой (атрибут ATTR_VOL_CAPABILITIES, флаг VOL_CAP_INT_CLONE).
Поддерживается начиная с OS X 10.12 (Sierra) и только в файловой системе APFS.
НЛО прилетело и опубликовало эту надпись здесь
При обновлении системы, установке пакетов такое происходит автоматически. Есть масса процессов, которые проходят невидимо для пользователя, но в которых эта оптимизация бы дала прирост скорости.
НЛО прилетело и опубликовало эту надпись здесь
А вот на Gentoo пакеты собираются из исходников. Там собираются дольше, чем скачиваются.
В любом случае reflink быстрее и экономичнее в плане дискового пространства.
Насчёт цифр. Всё, где используется cp теряет в скорости минимум в 5 раз. Большинство процессов linux использует её, а не пишут свои велосипеды копирования.
Виртуалками не пользуетесь? Машинным обучением не занимаетесь? А там этот функционал нужен и полезен.
Раз уж зашел разговор про CoW — есть какие-нибудь примеры того насколько все плохо с фрагментированием и, соответственно, производительностью таких файловых систем на обычных HDD? Хотел перевести домашний сервер на zfs (в первую очередь из-за проверки целостности данных, хотел сунуть 2-3 зеркала в 1 zpool), но боюсь как бы не получить тормозное нечто в итоге.
Предлагаю следующую статью в догонку про Redirect-on-write написать, inetstar.
del
на XFS тоже не всегда поддерживается CoW. нужно создавать файловую систему c mkfs.xfs -m reflink=1. уже на созданной ФС «включить» поддержку CoW нельзя. плюс, на ядрах до 4.11 включение этой опции вызывает красные варнинги в dmesg о том что фича – экспериментальная… в остальном работает. использую на свалке картинок нескольких сайтов (debian stretch), время от времени гоняю по ней duperemove…
Тут проблема не в COW механизме для Linux, а с изначально неправильными ожиданиями и пониманием технологии COW у автора.
Вы серьезно думаете, что COW был придуман, чтобы позволить быстро копировать файлы? Это вообще не так. И это не так хотя бы потому, что в Linux всегда был способ копирования без физического копирования — hard link — работает на любой (почти) ФС и за долго до появления COW. Мы можете сделать тот же алиес для команды cp, чтобы использовать hard link.
Основное назначение COW это предоставить механизм который позволяет при записи в тот же самый фал не перезаписывать байтики по тому же физическому месту, а записывать их в отдельное физическое место. И этот базовый механизм нужен, чтобы быть основой для следующих возможностей:
1. легкость восстановления предыдущего состояния файла (через механизм снимков или вручную)
И «легкость» тут как и для пользователя, так и техническая для разработчиков. Потому, что без COW есть другой механизм снимков — LVM snapshots — но его главная проблема это производительность и эта проблема как раз возникает потому без COW сделать механизм снимков эффективным не получится.
Замечали что для всех ФС у которых есть COW, так же есть и поддержка снимков, а где нет COW, то и снимки приходиться делать через «недешевый» LVM snapshots. Совпадение?
2. восстановления целостности файла при сбое (по питанию)
Тут опять же, COW просто сильно упрощает (для разработчиков) и делает более надежным механизмы восстановления файловой системы.
— То, что COW может ускорить копирования — просто побочная случайность, а не фича технологии. Поэтому с COW в Linux все ОК — оно работает ровно так как и задумывалось.
Вы серьезно думаете, что COW был придуман, чтобы позволить быстро копировать файлы? Это вообще не так. И это не так хотя бы потому, что в Linux всегда был способ копирования без физического копирования — hard link — работает на любой (почти) ФС и за долго до появления COW. Мы можете сделать тот же алиес для команды cp, чтобы использовать hard link.
Основное назначение COW это предоставить механизм который позволяет при записи в тот же самый фал не перезаписывать байтики по тому же физическому месту, а записывать их в отдельное физическое место. И этот базовый механизм нужен, чтобы быть основой для следующих возможностей:
1. легкость восстановления предыдущего состояния файла (через механизм снимков или вручную)
И «легкость» тут как и для пользователя, так и техническая для разработчиков. Потому, что без COW есть другой механизм снимков — LVM snapshots — но его главная проблема это производительность и эта проблема как раз возникает потому без COW сделать механизм снимков эффективным не получится.
Замечали что для всех ФС у которых есть COW, так же есть и поддержка снимков, а где нет COW, то и снимки приходиться делать через «недешевый» LVM snapshots. Совпадение?
2. восстановления целостности файла при сбое (по питанию)
Тут опять же, COW просто сильно упрощает (для разработчиков) и делает более надежным механизмы восстановления файловой системы.
— То, что COW может ускорить копирования — просто побочная случайность, а не фича технологии. Поэтому с COW в Linux все ОК — оно работает ровно так как и задумывалось.
Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?
Reflink — это тот же снимок только более гибкий. На уровне файла.
А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.
Reflink — это тот же снимок только более гибкий. На уровне файла.
2. восстановления целостности файла при сбое (по питанию)
А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.
> Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?
Ничего плохого, я лишь указываю, что это не основная цель этой технологии и что с основными целями COW в Linux отлично справляется. Главная задача COW быть небольших базовым кирпичиком который позволяет реализовывать в том числе и дедупликацию, но именно реализовывать там где это нужно (вот в docker например), а не предоставлять это по-умолчанию.
В docker, кстати, дедупликация реализуется вовсе не через cp с ключиком, а явно через снимки файловой системы (что супер быстро, в отличии от cp).
> А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.
Верно. И я указываю на то, что COW позволяет сильно проще (насколько проще, что это прям оправдывает создание этой технологии только для этого) и надежнее реализовывать механизмы обеспечения целостности в ФС.
Ничего плохого, я лишь указываю, что это не основная цель этой технологии и что с основными целями COW в Linux отлично справляется. Главная задача COW быть небольших базовым кирпичиком который позволяет реализовывать в том числе и дедупликацию, но именно реализовывать там где это нужно (вот в docker например), а не предоставлять это по-умолчанию.
В docker, кстати, дедупликация реализуется вовсе не через cp с ключиком, а явно через снимки файловой системы (что супер быстро, в отличии от cp).
> А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.
Верно. И я указываю на то, что COW позволяет сильно проще (насколько проще, что это прям оправдывает создание этой технологии только для этого) и надежнее реализовывать механизмы обеспечения целостности в ФС.
Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?
Тем, что эти плюшки достаются не бесплатно, а какой-то ценой. По этой причине включать все возможности по умолчанию без обоснования — противопоказано.
В данном случае есть очень серьёзная цена и у неиспользования новых технологий.
Аргументы человека, который запретил использование reflink по умолчанию, разобраны в статье. И я нашёл их несостоятельными.
И не только я. Но и разработчики некоторых файловых менеджеров.
Аргументы человека, который запретил использование reflink по умолчанию, разобраны в статье. И я нашёл их несостоятельными.
И не только я. Но и разработчики некоторых файловых менеджеров.
Ну я вам про конкретные в комментарии вашем — дедупликация та же, она далеко не бесплатна.
Так же и с аргументами про reflink — вы сами соглашаетесь с первым его аргументом. И, касаемо reflink — это нарушение стандартного поведения, не без последствий. А их без веской причины вообще менять не любят.
Вы приводите аргументы за 1 конкретный юзерский сценарий «быстро копировать файлы». В то время, как другие сценарии могут быть сильно весомее. И тут я согласен по поводу того, что при смене поведения сильно пострадают сценарии, рассчитывающие на быструю работу с файлами после копирования.
Поймите меня правильно, я за reflink. Но не всё так однозначно. Да и CoW тут не при чём.
Так же и с аргументами про reflink — вы сами соглашаетесь с первым его аргументом. И, касаемо reflink — это нарушение стандартного поведения, не без последствий. А их без веской причины вообще менять не любят.
Вы приводите аргументы за 1 конкретный юзерский сценарий «быстро копировать файлы». В то время, как другие сценарии могут быть сильно весомее. И тут я согласен по поводу того, что при смене поведения сильно пострадают сценарии, рассчитывающие на быструю работу с файлами после копирования.
Поймите меня правильно, я за reflink. Но не всё так однозначно. Да и CoW тут не при чём.
Вы приводите аргументы за 1 конкретный юзерский сценарий «быстро копировать файлы».
Во-первых это не юзерский сценарий. Масса пакетов и программ делают это автоматически без ведома юзера.
А во-вторых в случае reflink дедупликация даётся бесплатно.
На мой взгляд reflink без CoW невозможен. В основе снимков лежит тот же механизм, что и у reflink.
Во-первых это не юзерский сценарий. Масса пакетов и программ делают это автоматически без ведома юзера.
IIRC не всё так радужно, было бы отлично найти реальные тесты работы ПО с включенным reflink, окромя ручного копирования. Часто файлы при работе лежат либо в tmpfs, либо на других ФС, и reflink тут не поможет. А просто так делать cp туда-сюда в рамках одной ФС — ну, такое.
Важный момент — тесты должны проверят скорость дальнейшей работы с reflinked файлами, иначе самое интересное вы как раз таки выкидываете за борт :) Вы в статье критикуете именно аргумент про производительность при изменении reflinked файла («Also for performance reasons you may want the writes to happen at copy time rather than some latency sensitive process working on a CoW file and being delayed by the writes possibly to a different part of a mechanical disk.»), а тесты именно на это не делаете.
А во-вторых в случае reflink дедупликация даётся бесплатно.
Работа с дедуплицированными данными не всегда бесплатна.
На мой взгляд reflink без CoW невозможен. В основе снимков лежит тот же механизм, что и у reflink.
Так и при чём тут CoW ФС, приследовавшие совершенно другие цели, как ранее уже сказал Enchant? Чисто технически можно и на ext4 сделать нашлёпку для reflink. Да, механизм будет похож на CoW, но блин, это не магические 3 буквы :)
Рассматривая ваше сравнение reflink со снапшотами — да, механизм похож, но это не значит, что в ФС со снапшотами вы автоматом получаете reflinks. На примере ZFS — всё есть дерево, при создании снапшота грубо говоря создаётся родительский блок, наследующий все предыдущие состояния датасета, и не позволяющий их удалять. Но снапшот здесь per-dataset. Reflink же требует не просто похожий механизм, но на уровне отдельного файла, но и ещё должен давать адекватную скорость при доступе к блокам reflinked файлов. Это же тоже не бесплатно, плюс выбивается из архитектуры данной ФС. Т.е. в ZFS снапшоты бесплатны именно на создание. Но удаление снапшотов — не бесплатно. То же самое, только хуже, будет и для reflink, где удаление будет происходить сильно чаще.
И, в случае ZFS, reflinks должны полагаться на DDT, а не на снапшоты github.com/zfsonlinux/zfs/issues/405#issuecomment-57201194
А что такое DDT?
Я вот увидел следующую фразу:
Ну так это не проблема. У XFS тоже нужно ФС заново воздавать, чтобы reflink заработали.
А вот то, что у ZFS reflink нет — это печально.
Насчёт нашлёпки на ext4. Из википедии:
Эта нашлёпка, если будет работать так, то это будет CoW.
Я вот увидел следующую фразу:
The technique described cannot be applied to existing ZFS datasets
Ну так это не проблема. У XFS тоже нужно ФС заново воздавать, чтобы reflink заработали.
А вот то, что у ZFS reflink нет — это печально.
Насчёт нашлёпки на ext4. Из википедии:
Идея подхода copy-on-write заключается в том, что при чтении области данных используется общая копия, в случае изменения данных — создается новая копия.
Эта нашлёпка, если будет работать так, то это будет CoW.
DDT в случае ZFS — это та самая таблица, которая хранит информацию о дедуплицированных данных (dedup table). Вот тут как раз и кроется проблема и dedup и возможного reflink — если хочется делать всё это онлайн, а не когда нибудь потом, то для записи (и изменения данных) вам придётся по всей этой таблице ходить (а вы хотите это сделать онлайн, иначе смысла в reflink при наличии штатной дедупликации нет). Т.е. держать её в памяти. Т.е. по грубым расчётам 20ГБ ОЗУ на 1ТБ диска. Иначе — привет запись 400КБ/сек и ниже.
Это пример из конкретной реализации ZFS и причины, почему дедупликацию в ней НЕ рекомендуют включать. Конечно стоит добавить, что именно эту ситуацию тоже пытаются улучшить github.com/zfsonlinux/zfs/issues/405#issuecomment-57201194, но в этой презентации явно показана стоимость дедупликации. Кратко — она всё равно не бесплатна.
А, ну и если вам очень хочется reflink в ZFS — просто включите дедупликацию :) Даже cp менять не придётся. Только включать дедупликацию я не рекомендую, если ваш коэффициент дедупликации меньше 20, см. требования к ОЗУ выше. Лучше онлайн lz4 компрессию использовать.
Если найдёте тесты на доступ к reflinked файлам, близкие к реальным кейсам — было бы интересно на них посмотреть, спасибо!
Это пример из конкретной реализации ZFS и причины, почему дедупликацию в ней НЕ рекомендуют включать. Конечно стоит добавить, что именно эту ситуацию тоже пытаются улучшить github.com/zfsonlinux/zfs/issues/405#issuecomment-57201194, но в этой презентации явно показана стоимость дедупликации. Кратко — она всё равно не бесплатна.
А, ну и если вам очень хочется reflink в ZFS — просто включите дедупликацию :) Даже cp менять не придётся. Только включать дедупликацию я не рекомендую, если ваш коэффициент дедупликации меньше 20, см. требования к ОЗУ выше. Лучше онлайн lz4 компрессию использовать.
Если найдёте тесты на доступ к reflinked файлам, близкие к реальным кейсам — было бы интересно на них посмотреть, спасибо!
LVM снапшоты тоже ведь copy-on-write, почему они дороже?
Там большой размер блока. Что-то около 4 мегабайта по умолчанию. Много места теряется при небольших изменениях.
Там есть разница в подходе к записи данных. В случае записи в файл под LVM snapshot физическая запись выполняется в тоже самое физическое место (т.е. как будто это обычная запись) и одновременно с этим выполняется копирование предыдущего состояния данных в новое место.
Если проще — то во время записи создаётся бэкап старой записи и кладётся в отдельно место. Т.е. выполняется две операции записи, поэтому это медленнее.
Так сделано, потому что LVM snapshot универсальная прослойка для любой ФС, а сделать по другому без знания внутренностей ФС не получиться.
Если проще — то во время записи создаётся бэкап старой записи и кладётся в отдельно место. Т.е. выполняется две операции записи, поэтому это медленнее.
Так сделано, потому что LVM snapshot универсальная прослойка для любой ФС, а сделать по другому без знания внутренностей ФС не получиться.
И это не так хотя бы потому, что в Linux всегда был способ копирования без физического копирования — hard link — работает на любой (почти) ФС и за долго до появления COW. Мы можете сделать тот же алиес для команды cp, чтобы использовать hard link.
Хардлинк — это всего-лишь алиас. Если изменить файл-копию, то изменится и оригинал.
Reflink, с точки зрения пользователя, — это полноценная копия, которая, пока её не изменили, не занимает места. Ну и скорость копирования феноменальная, конечно.
И всё-таки основная задача CoW — это экономия места. Из Википедии:
Идея подхода copy-on-write заключается в том, что при чтении области данных используется общая копия, в случае изменения данных — создается новая копия.
И всё-таки основная задача CoW — это экономия места. Из Википедии:
Вы вырвали из контекста как-то :) По умолчанию в CoW нет общих копий. Другой вопрос, что т.к. блок данных никогда не переписывается, позволяет его не удалять и использовать в других целях. Но это больше бонус, нежели цель.
И я вас расстрою — CoW всегда будет требовать больше пространства, чем классический подход. При заполнении более 90% любая CoW-like ФС начинает сильно деградировать по записи, т.к. свободное место дико фрагментировано и поиск свободного места нужного размера становится очень дорог. Да, это пытаются нивелировать всякими плюшками типа компрессии. Но это не основная цель CoW!
А какая основная цель CoW?
В ядре Линукса CoW был придуман именно для экономии оперативной памяти для переменных процессов при
По-моему — это исторически первая работающая реализация CoW.
В ядре Линукса CoW был придуман именно для экономии оперативной памяти для переменных процессов при
fork().По-моему — это исторически первая работающая реализация CoW.
В ядре COW больше для экономии места и скорости создания нового процесса. Для хранилищ я думаю COW это повышенная надежность в первую очередь.
А какая основная цель CoW?
CoW — это инструмент. Он не даёт магическим образом всё, что вы пожелаете.
Цель у каждого продукта своя. CoW — инструмент. В зависимости от целей он будет по разному использоваться. Почему вы пытаетесь притянуть ему желаемую в определённом продукте вами цель?
Давайте ещё раз — CoW магическим образом вам не даёт, к примеру, дедупликацию и снапшоты. Но, добавив ингредиенты (на примере ZFS — та же DDT), вы можете добиться нужной цели.
В ядре Линукса CoW был придуман именно для экономии оперативной памяти для переменных процессов при fork().
Не в ядре линука был придуман ни CoW, ни fork. https://en.wikipedia.org/wiki/Fork_(system_call) см. там же virtual memory в SunOS-4.0 от 1988 года.
По-моему — это исторически первая работающая реализация CoW.
Увы, но это не так, см. выше.
Вы так чётко утверждали:
Как-будто знаете основную цель. Но назвать её так и не смогли.
В SunOS CoW, как я понял, был создан также для экономии памяти. Ускорение, на мой взгляд, тут неочевидно, так как механизмы CoW тоже потребояют процессорное время.
Насчёт дедупликации. Устранения дублирующей информации.
CoW по своей логике автоматически обеспечивает дедупликацию, так как хранит только различающиеся данные.
Просто в ZFS дедупликация сделана через DDT, а не через механизмы CoW. Это специфика реализации ZFS.
Но это не основная цель CoW!
Как-будто знаете основную цель. Но назвать её так и не смогли.
В SunOS CoW, как я понял, был создан также для экономии памяти. Ускорение, на мой взгляд, тут неочевидно, так как механизмы CoW тоже потребояют процессорное время.
Насчёт дедупликации. Устранения дублирующей информации.
CoW по своей логике автоматически обеспечивает дедупликацию, так как хранит только различающиеся данные.
Просто в ZFS дедупликация сделана через DDT, а не через механизмы CoW. Это специфика реализации ZFS.
CoW по своей логике автоматически обеспечивает дедупликацию, так как хранит только различающиеся данные.
Разве он по природе своей поймёт, что два файла, которые я скопировал с внешнего источника, не поддерживающего CoW, по содержимому одно и то же? По-моему, он по природе своей дедуплицирует только если источник находится на той же ФС, что и цель. А автоматически при создании нового файла (копирование со внешнего источника для ФС это создание нового) не ищет.
Всё верно. Только при копировании файлов из внешнего источника парадигма CoW не применяется. А везде где она реально применяется, она обеспечивает дедупликацию автоматически.
Однако у Ханса Райзера поехала крыша и он убил жену, а его детище (скорее всего по политическим причинам) не включили в ядро.
Восхитительно. Несколько лет коту под хвост, потому что разработчик оказался плохим парнем? Опасались, что через код передастся сумасшествие или пользоваться такими фичами — неполиткорректно?
Восхитительно. Несколько лет коту под хвост, потому что разработчик оказался плохим парнем? Опасались, что через код передастся сумасшествие или пользоваться такими фичами — неполиткорректно?
Он был ведущим разрабом там. Без него проект как-то сам заглох. Желающих продолжить в целом было не мало, но во-первых, на тот момент ещё не пришла эпоха ssd, а на hdd из-за фрагментации были проблемы с производительностью, а во-вторых, одно дело хотеть разрабатывать fs и совсем другое дело уметь это делать — людей, которые на профессиональном уровне занимаются fs в мире очень мало.
А про политические причины, это мнение автора. На самом деле на момент ареста код был не готов ко включению в ядро. Надо было привести код в соответствие стандартам Linux Kernel и это по факту никто так и не сделал, а потом стало поздно ибо внимание переключилось на btrfs/zfs и позже xfs, а потом интерес к теме упал: часть функционала r4 появилась в ext4, часть в btrfs/zfs.
Автор может пожелать добавить апдейт по поводу того, что ситуация изменилась: патч для дефолта cp на --reflink=auto был вмержен в Июне прошлого года. Правда, с тех пор не было нового релиза coreutils (на момент написания этого комментария последний релиз 8.32), изменения будут в следующем. Так же, поддержка в nautilus имеется (точно не знаю с какого момента, но комментарий ссылающийся на код оставлен 6 месяцев назад). И по словам автора багрепорта по ссылке, Dolphin тоже поддерживает reflink (уже не стал искать, с какого момента, но можно сказать, что не меньше 6-ти месяцев).
А, и ещё Fedora применяют к пакету coreutils патч для reflink=auto, так что у них это работает уже сейчас.
C каких версий наутилус и дельфин поддерживают рефлинки?
К сожалению, нет времени выискивать это самому.
К сожалению, нет времени выискивать это самому.
Добавил в статью
Dolphin и Nautilus уже поддерживают reflink, но только для btrfs.
Это не совсем так. В дискуссии по ссылке, следующий комментарий после того, на который я сослался, утверждает, что CoW работает и под XFS тоже. Там конфуз был потому что в коде функции имеют префикс btrfs_. Но это просто проблема наименования.
Кстати, просто любопытная информация от себя: изменение по поддержке CoW было сделано не непосредственно в коде Nautilus, а в общем коде Glib, который Nautilus использует (ориг. багрепорт был создан на Nautilus, но потом мигрирован на Glib). По-видимому это подразумевает, что CoW может работать у всех приложений, копирующих файлы средствами Glib. В репо Арча я вижу 393 приложения полагающихся на Glib — хотя не знаю, скольким из них это вообще релевантно.
Добавил в статью
И спасибо за апдейты!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что не так с Copy-on-Write под Linux при копировании