Комментарии 113
Сжатие памяти, снэпшоты фс, кэш hdd на ssd, CoW, апдейт ядра без перезапуска и тысячи подобных штук. Технологии есть — внедрения нет.
IMHO, те, кому эти няшные свистелки действительно нужны, знают об их наличии и о том, как их включить (или способны найти способ их включить). Остальным либо не так уж и нужно, либо и вовсе опасно давать такое по умолчанию.
У нас народ про network namespaces узнал год назад, когда я предложил их использовать для поднятия нескольких идентичных копий сервиса на одной машине. Хотя в iproute они присутствуют уже давно, даже пересобирать ничего не надо. Вот так "надо" было.
Огласите весь список, пожалуйста. Или хотя бы где посмотреть по частям?
Обычно справляются простым alias
Однажды, ещё на Solaris 8 (или 9), я положил "скриптик", который вызывал системную команду внутри. И перезагрузил сервак.
После 2хчасового интенсивного секса с незагружающейся системой (в итоге всё же обошлось без переустановки) я подумал, что больше так делать не стоит...
chattr +C /dir/file
скорее всего не заработает на btrfs. В документации на chattr написано что работает только на директориях и пустых файлах. Таким образом нужно поставить +С на директорию и скопировать файл без reflink.Помимо того в документации на btrfs раньше было написано, что в некоторых пределах, ядро пытается делать 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 переписываются чексуммы в метаданных, а при его отсутствии они не считаются.
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», дословно, «акцент сделан на 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…
Очень многие пакеты под капотом используют
cp
. Я бы не стал так бескомпромиссно утверждать, что libvirt, VirtualBox, NextCloud нигде в своём коде не используют cp
. Совершенно не все разработчики любят писать свои «велосипеды».Что не так с системой создающей у пользователя ошибочное впечатление того что файлов ДВА, в то время как файл ОДИН ?
Да, вобщем то, всё.
Неискушенные пользователи действительно могут делать бакапы ценных файлов на одной и той же файловой системе.
Копирование на ту же файловую систему — один из вариантов резервирования. Носитель может умереть не сразу, а начать сыпаться по частям. Не самый лучший, но нормальный.
Кроме бэкапленья, есть другие варианты необходимости копирования.
- Скопировать файлы и потестить что-нибудь связанное с редактированием этих файлов
- Иметь какой-нибудь шаблонный файлик, типа договора, который копируется по мере необходимости
- Иметь исходные картинки, скопировать и массово их обработать. Например, отресайзить и наложить логотип
- Брать какой нибудь файл, например скрипт, копировать и использовать его в качестве основы для другого файла.
Есть много разных случаев, когда пользователь может иметь условный "эталон" копировать его и проводить операции с копиями.
Спасибо.
Понял.
Увы, из текста постинга это не следует, поэтому список отменяется.
Но тогда это создаёт другую проблему — возможность внезапного появления кучи реальных файлов.
В случае с обработкой кучи файлов это приведёт к тому, что вместо ожидаемого уменьшения (за счёт ресайза и сжатия) занятого места будет происходить его увеличение (за счёт появления несуществовавших файлов).
Увы, из текста постинга это не следует
Вот что меня удивляет: смысл поста — это именно CoW при копировании. А вы говорите, что из текста не следует.
за счёт появления несуществовавших файлов
Они существовали. Просто при перезаписи под них начинает выделяться дополнительное место.
Они существовали. Просто при перезаписи под них начинает выделяться дополнительное место.
Осталось объяснить это конечным потребителям.
Но вот ситуация, у нас, предположим
решением для лёгких виртуальных машин и контейнеров. Ведь мы могли бы не тратить место на одинаковые файлы
И по какой-то причине крешится сектор диска.
Вы теряете файл не в одной ВМ или контейнере а во всех, такая себе радость на мой взгляд.
Сама фича не плохая, а то что по дефолту она выключена, на мой взгляд просто замечательно. Все кто нуждается могут включить, для прочих она скорее опасна чем полезна.
На ссд я что-то не сталкивался с крешем одиночных секторов. Если же говорить про тех, кто очень люьит использовать много виртуалок, то они у них живут на рейде.
А про обычного массового пользователя, для которого и собираются дистрибутивы с дефолтными настройками. И у которого нормой десяток докеров и пяток виртуалок. Потерять их все разом радости так же мало.
Помню была бага с XFS, когда при потере питания избирательно обнулялись незакрытые файлы. Очень было неприятно и иногда даже больно. Если бы я тогда узнал что это фича, я был бы довольно несдержан в своих словах.
И по какой-то причине крешится сектор диска.
В этом случае весь диск выбрасывается, а данные восстанавливаются из бэкапа.
Тем более в вашем случае, когда потерялись не самые свежие изменения в одной из ВМ, а общая часть всех ВМ, т.е. неизменённая, которая точно есть в бэкапе или там, откуда вы её скачали.
В этом случае весь диск выбрасывается, а данные восстанавливаются из бэкапа.
Вы это сейчас про обычного массового пользователя линукса? Мне кажется вы большой оптимист.
И основная то проблема даже не в том что файл погиб (его копию можно найти, скопировать), а то что вполне вероятно что без оного файла система не стартанет (виртуалка) и потребуется разбираться что там и почему. Радости не много.
Вы это сейчас про обычного массового пользователя линукса? Мне кажется вы большой оптимист.Обычный массовый рользователь линукса — это кто? У меня на предприятии несколько тысяч пользователей линукса — думаю, это и есть «обычные массовые пользователи». При любой проблеме с диском (да и при многих других) такой пользователь берёт из шкафа новый диск на салазках, вставляет его в свой компьютер взамен проблемного и работает дальше.
А если у кого-то несколько клонированных виртуальных машин, то это не массовый пользователь, а как минимум айтишник или человек в айти разбирающийся, который сознательно выбрал линукс и файловую систему с CoW, и он точно знает про бэкапы.
Обычный массовый рользователь линукса — это кто?
Обычный, это который не системный. У которого нет шкафа, а которому нужно ехать в магазин и тратить кровные.
А если у кого-то несколько клонированных виртуальных машин, то это не массовый пользователь, а как минимум айтишник
Как по мне нормальный обычный пользователь. Пусть и айтишник.
И сильно сомневаюсь что на каждый вылетевший сектор побежит в магазин тратить 200-300 баксов.
По вашим словам судить, так у каждого айтишника все личные/домашние системы на рейдах, с бэкапами в облако, резервированием интернет канала и бесперебойником зацепленном на генератор. Может такое и имеет место быть но явно не в моей реальности.
И сильно сомневаюсь что на каждый вылетевший сектор побежит в магазин тратить 200-300 баксов.Первый вылетевший сектор означает, что вслед за ним в любой момент времени вылетит второй, третий, и т.д., а значит этим диском лучше не пользоваться, так как на восстановление данных придётся потратить намного больше времени, чем стоит новый диск.
По вашим словам судить, так у каждого айтишника все личные/домашние системы на рейдах, с бэкапами в облако, резервированием интернет канала и бесперебойником зацепленном на генератор. Может такое и имеет место быть но явно не в моей реальности.Странные у вас суждения, однако.
а значит этим диском лучше не пользоваться, так как на восстановление данных придётся потратить намного больше времени, чем стоит новый диск
Почему нет? Ну потеряются, и черт с ними. Перекачают заново свои торенты например. Или вышеупомянутый докер переразвернут, или виртуалку накатят заново. Это как бы не повод тратить 200 баксов на новый диск, это не продакшен.
Ради любопытства посмотрите какое количество бу памяти и дисков скупается на али. И люди довольны и счастливы. Реальность она такая вот.
Более того, айтишник, который ценит содержимое диска, работает в массиве RAID просто потому, что это и недорого, и надёжно, и производительность снижает малозаметно
Давайте не будем смешивать домашний и рабочий компьютер.
От того что содержимое диска не особенно нужно и его вполне можно востановить не возникает особенно сильное желание этим заниматься. Притом как правило в не самый удачный момент.
ЗЫ А у ж сколько примеров как бэкапы делались на тот же раздел что и данные, сколько было незапланированных дроптэйблов и датабэйсов и прочего подобного. Не стоит идеализировать людей вообще и айтишников в частности.
На ноутбуке сложно RAID поднять
А вы знаете что Docker поддерживает btrfs для своего хранилища? Эту опцию нужно включать.Лучше не надо. btrfs graphdriver в Docker кривоват и имеет несколько багов пара из которых фатальны. Особенно опасно реализованы квоты. Пару лет назад я пытался его запатчить но всё руки не доходят пропихнуть в апстрим.
Во общем сейчас связка OverlayFS поверх btrfs надёжнее.
когда я включил qouta (включил функцию — btrfs quota enable, но не выставил ограничений) на btrfs и использовал это для того чтобы смотреть размеры снапшотов (btrfs-du) — всё было красиво, но когда я попробовал удалить один снапшот — btrfs-cleaner сожрал всё память и дальше у меня было увлекательных несколько дней в поисках решений. Баг до сих пор присутствует
Ссылка дана на баг-трекер Red Hat. А в баг-трекере Btrfs что говорят про это?
Я в августе этого года это делал. Скачал archiso свежий на тот момент. И.е. ядро было 5.x (точнее не помню), и проблема продолжала наблюдаться. При монтировании fs, через примерно час 2гб ОЗУ заканчивались и все вставало колом. Я перезагружал, монтировал и наблюдал опять процесс btrfs-cleaner который бух по памяти. Потом узнал про квоты, выключил и как то помогло. Тоже не с первого раза получилось.
К сожалению всего алгоритма я не записал, но с проблемой бился несколько дней в свободные часы (домашний сервер на 6 разных дисках btrfs разделом на 14 Тб).
Т.е. я полагаю, что проблема не решена. Но это отдельный кейс, который по умолчанию выключен
На мой взгляд, проблема CoW-FS отнюдь не в coreutils. А в том что надо учить весь софт, занимающийся в том или ином виде копированием файлов, вызывать новый syscall.
А ещё CoW — не серебряная пуля, и на части сценариев будет работать хуже/медленнее чем не-CoW.
Она включает использование атомарного системного вызова clonefile(), который создаёт запись в файловой системе о новом файле, в котором ссылки на блоки данных идентичны оригиналу. Копируются атрибуты и расширенные атрибуты файла, записи списков контроля доступа (ACL), за исключением информации о владельце файла и со сбросом setuid/setgid битов. Работает в пределах одной файловой системы, требует поддержки файловой системой (атрибут ATTR_VOL_CAPABILITIES, флаг VOL_CAP_INT_CLONE).
Поддерживается начиная с OS X 10.12 (Sierra) и только в файловой системе APFS.
А вот на Gentoo пакеты собираются из исходников. Там собираются дольше, чем скачиваются.
В любом случае reflink быстрее и экономичнее в плане дискового пространства.
Насчёт цифр. Всё, где используется cp теряет в скорости минимум в 5 раз. Большинство процессов linux использует её, а не пишут свои велосипеды копирования.
на XFS тоже не всегда поддерживается CoW. нужно создавать файловую систему c mkfs.xfs -m reflink=1. уже на созданной ФС «включить» поддержку CoW нельзя. плюс, на ядрах до 4.11 включение этой опции вызывает красные варнинги в dmesg о том что фича – экспериментальная… в остальном работает. использую на свалке картинок нескольких сайтов (debian stretch), время от времени гоняю по ней duperemove…
Вы серьезно думаете, что COW был придуман, чтобы позволить быстро копировать файлы? Это вообще не так. И это не так хотя бы потому, что в Linux всегда был способ копирования без физического копирования — hard link — работает на любой (почти) ФС и за долго до появления COW. Мы можете сделать тот же алиес для команды cp, чтобы использовать hard link.
Основное назначение COW это предоставить механизм который позволяет при записи в тот же самый фал не перезаписывать байтики по тому же физическому месту, а записывать их в отдельное физическое место. И этот базовый механизм нужен, чтобы быть основой для следующих возможностей:
1. легкость восстановления предыдущего состояния файла (через механизм снимков или вручную)
И «легкость» тут как и для пользователя, так и техническая для разработчиков. Потому, что без COW есть другой механизм снимков — LVM snapshots — но его главная проблема это производительность и эта проблема как раз возникает потому без COW сделать механизм снимков эффективным не получится.
Замечали что для всех ФС у которых есть COW, так же есть и поддержка снимков, а где нет COW, то и снимки приходиться делать через «недешевый» LVM snapshots. Совпадение?
2. восстановления целостности файла при сбое (по питанию)
Тут опять же, COW просто сильно упрощает (для разработчиков) и делает более надежным механизмы восстановления файловой системы.
— То, что COW может ускорить копирования — просто побочная случайность, а не фича технологии. Поэтому с COW в Linux все ОК — оно работает ровно так как и задумывалось.
Reflink — это тот же снимок только более гибкий. На уровне файла.
2. восстановления целостности файла при сбое (по питанию)
А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.
Ничего плохого, я лишь указываю, что это не основная цель этой технологии и что с основными целями COW в Linux отлично справляется. Главная задача COW быть небольших базовым кирпичиком который позволяет реализовывать в том числе и дедупликацию, но именно реализовывать там где это нужно (вот в docker например), а не предоставлять это по-умолчанию.
В docker, кстати, дедупликация реализуется вовсе не через cp с ключиком, а явно через снимки файловой системы (что супер быстро, в отличии от cp).
> А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.
Верно. И я указываю на то, что COW позволяет сильно проще (насколько проще, что это прям оправдывает создание этой технологии только для этого) и надежнее реализовывать механизмы обеспечения целостности в ФС.
Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?
Тем, что эти плюшки достаются не бесплатно, а какой-то ценой. По этой причине включать все возможности по умолчанию без обоснования — противопоказано.
Аргументы человека, который запретил использование reflink по умолчанию, разобраны в статье. И я нашёл их несостоятельными.
И не только я. Но и разработчики некоторых файловых менеджеров.
Так же и с аргументами про 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
Я вот увидел следующую фразу:
The technique described cannot be applied to existing ZFS datasets
Ну так это не проблема. У XFS тоже нужно ФС заново воздавать, чтобы reflink заработали.
А вот то, что у ZFS reflink нет — это печально.
Насчёт нашлёпки на ext4. Из википедии:
Идея подхода copy-on-write заключается в том, что при чтении области данных используется общая копия, в случае изменения данных — создается новая копия.
Эта нашлёпка, если будет работать так, то это будет CoW.
Это пример из конкретной реализации ZFS и причины, почему дедупликацию в ней НЕ рекомендуют включать. Конечно стоит добавить, что именно эту ситуацию тоже пытаются улучшить github.com/zfsonlinux/zfs/issues/405#issuecomment-57201194, но в этой презентации явно показана стоимость дедупликации. Кратко — она всё равно не бесплатна.
А, ну и если вам очень хочется reflink в ZFS — просто включите дедупликацию :) Даже cp менять не придётся. Только включать дедупликацию я не рекомендую, если ваш коэффициент дедупликации меньше 20, см. требования к ОЗУ выше. Лучше онлайн lz4 компрессию использовать.
Если найдёте тесты на доступ к reflinked файлам, близкие к реальным кейсам — было бы интересно на них посмотреть, спасибо!
LVM снапшоты тоже ведь copy-on-write, почему они дороже?
Если проще — то во время записи создаётся бэкап старой записи и кладётся в отдельно место. Т.е. выполняется две операции записи, поэтому это медленнее.
Так сделано, потому что LVM snapshot универсальная прослойка для любой ФС, а сделать по другому без знания внутренностей ФС не получиться.
И это не так хотя бы потому, что в Linux всегда был способ копирования без физического копирования — hard link — работает на любой (почти) ФС и за долго до появления COW. Мы можете сделать тот же алиес для команды cp, чтобы использовать hard link.
Хардлинк — это всего-лишь алиас. Если изменить файл-копию, то изменится и оригинал.
Reflink, с точки зрения пользователя, — это полноценная копия, которая, пока её не изменили, не занимает места. Ну и скорость копирования феноменальная, конечно.
И всё-таки основная задача CoW — это экономия места. Из Википедии:
Идея подхода copy-on-write заключается в том, что при чтении области данных используется общая копия, в случае изменения данных — создается новая копия.
И всё-таки основная задача CoW — это экономия места. Из Википедии:
Вы вырвали из контекста как-то :) По умолчанию в CoW нет общих копий. Другой вопрос, что т.к. блок данных никогда не переписывается, позволяет его не удалять и использовать в других целях. Но это больше бонус, нежели цель.
И я вас расстрою — CoW всегда будет требовать больше пространства, чем классический подход. При заполнении более 90% любая CoW-like ФС начинает сильно деградировать по записи, т.к. свободное место дико фрагментировано и поиск свободного места нужного размера становится очень дорог. Да, это пытаются нивелировать всякими плюшками типа компрессии. Но это не основная цель CoW!
В ядре Линукса CoW был придуман именно для экономии оперативной памяти для переменных процессов при
fork()
.По-моему — это исторически первая работающая реализация 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.
Увы, но это не так, см. выше.
Но это не основная цель 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, так что у них это работает уже сейчас.
К сожалению, нет времени выискивать это самому.
Dolphin и Nautilus уже поддерживают reflink, но только для btrfs.
Это не совсем так. В дискуссии по ссылке, следующий комментарий после того, на который я сослался, утверждает, что CoW работает и под XFS тоже. Там конфуз был потому что в коде функции имеют префикс btrfs_
. Но это просто проблема наименования.
Кстати, просто любопытная информация от себя: изменение по поддержке CoW было сделано не непосредственно в коде Nautilus, а в общем коде Glib, который Nautilus использует (ориг. багрепорт был создан на Nautilus, но потом мигрирован на Glib). По-видимому это подразумевает, что CoW может работать у всех приложений, копирующих файлы средствами Glib. В репо Арча я вижу 393 приложения полагающихся на Glib — хотя не знаю, скольким из них это вообще релевантно.
Добавил в статью
И спасибо за апдейты!
Что не так с Copy-on-Write под Linux при копировании