30.10.2019 10:00
inetstar 91 20700 Источник


Предупреждение: эта статья относится ко всем CoW файловым системам в Linux, поддерживающим reflink при копировании. В данный момент это: BTRFS, XFS и OCFS2.

Прошу воздержаться от холиваров о том, какая ФС лучше: Btrfs, XFS, Reiser4, NILFS2, ZFS или какая-то неупомянутая.

Предыстория


  • 21 июля 2001 года — Namesys публикует анонс Reiser4. DARPA спонсирует разработку.
  • 20 ноября 2003 — Namesys публикует некоторые бенчмарки Reiser4.
  • 24 августа 2004 — Namesys делает публичный релиз Reiser4.
  • 14 сентября 2004 — анонс ZFS.
  • 16 ноября 2005 — ZFS включена в 27 сборку OpenSolaris.
  • сентябрь 2006 — Ханс Райзер арестован за убийство жены, Нины Райзер. Начало конца Namesys
  • 12 июня 2007 — анонс Btrfs Крисом Мейсоном (бывший сотрудник Namesys).
  • 22 сентября 2011 — В ZFSonLinux появился тикет с запросом на реализацию reflink.
  • 2012 — Btrfs признана стабильной Oracle Linux и SUSE Linux Enterprise
  • 21 января 2013 — метка экспериментальности была снята c Btrfs в исходных кодах ядра Linux.
  • май 2019 — Btrfs удалена из RHEL 8 (подозревается скрытые политические причины, так как Btrfs продвигается Oracle)

Ожидания от копирования в CoW-файловых системах


Когда в 2001 году анонсировалась Reiser4, я был вдохновлён и увлечён возможностями Copy-on-Write. Подумать только, мы можем легко и просто иметь сколько угодно копий разных проектов, а физически диск будет хранить только отличия между ними!

К тому же скорость копирования должна была неприлично вырасти. За счёт того, что при копировании создавалась бы только reflink-ссылка на старый файл. При записи в такой новый файл автоматически выделялись бы сектора для изменённых данных. В итоге мы бы имели одинаковые сектора для общих частей файлов, а разные части были бы записаны в разных секторах.

Это тогда выглядело панацеей для создания аккаунтов для shared-хостинга, а сейчас оптимальным решением для лёгких виртуальных машин и контейнеров. Ведь мы могли бы не тратить место на одинаковые файлы, вместе с тем позволяя пользователям их беспроблемно менять.

Однако у Ханса Райзера поехала крыша и он убил жену, а его детище (скорее всего по политическим причинам) не включили в ядро. Может всё-таки история зависит от конкретной личности?

ZFS была опубликована под несовместимой с Linux лицензией, и потому не вошла в ядро. Поэтому внедрение ZFS в Linux оказалось надолго заторможено.

После этого я стал ждать Btrfs. И только через 6 лет после анонса она была признана разработчиками ядра Linux стабильной.

После этого я не торопился использовать Cow-системы, так как сама парадигма Copy-on-Write предполагает повышенную фрагментацию, потому что изменения данных каждый раз записываются в новое место.

Для HDD фрагментация убивает производительность, так как процесс перепозиционирования блока считывающих головок — очень длительная операция.

Поэтому лично я откладывал внедрение btrfs на своих машинах, пока они не перешли на SSD.

Замечу, что SSD тоже не любят фрагментацию, всем известно, что для SSD линейная запись/чтение могут быть в десятки раз быстрее, чем случайный доступ.

Но производительность фрагментированного SSD падает не так драматически, как у HDD.

Итак, что со скоростью копирования при CoW?


И вот, наконец, настал тот час. Когда SSD стали достаточно надёжны, я стал вовсю использовать CoW-файловые системы. А конкретнее — Btrfs и Nilfs2.

Осваивая захватывающие возможности снимков (снепшотов), на время я забыл о моих ожиданиях из 2000-х годов о сверхбыстром копировании файлов.

Через некоторое время я решил провести тесты. И к моему великому разочарованию не увидел никакого прироста скорости от CoW при копировании. Вот результат на SATA SSD:

time cp -a /usr /usr1
real    0m15,572s
user    0m0,240s
sys     0m4,739s

Оказалось, что для использования CoW нужно указывать специальный ключ.

time cp -a --reflink=auto /usr /usr2

real    0m3,166s
user    0m0,178s
sys     0m2,891s

Только в этом случае мы видим 5-кратное преимущество. К слову говоря, размер преимущества неограниченно растёт при увеличении длины файлов. В папке /usr, которую я копировал, в основном мелкие файлы.

Я был несказанно удивлён, почему ключевое преимущество CoW-файловой системы не используется по умолчанию. Ведь для этого она и создавалась!

В данном случае я тестировал копирование на Btrfs-разделе. Но подобный результат вы получите и с любой другой CoW-файловой системой, поддерживающей reflink.

В чём проблема, Билли?


Проблема в cp. По умолчанию она не использует CoW при копировании. Хотя может.

Вы можете сказать — я не использую cp. Однако под капотом у Linux он используется практически везде. Многие программы, когда им нужно что-то скопировать, используют cp, а не свои «велосипеды».

Почему разработчиками coreutils было принято столь неоднозначное решение, которое перечеркнуло половину преимуществ CoW файловых систем?

Оказывается, так решил Padraig Brady, ответственный за развитие GNU coreutils.

Вот его логика:

  1. По умолчанию cp не использует CoW, так как кто-то может использовать копирование для того, чтобы повысить вероятность сохранения файла на диске после разрушения файловой системы.
  2. С точки зрения производительности, если есть некий чувствительный к задержкам процесс, вы можете захотеть, чтобы основная запись была сделана именно во время копирования, так если это произойдёт потом, то может возникнуть лаг при перепозиционировании головок жёсткого диска. Обратите внимание, начиная с версии 8.24 coreutils, mv по умолчанию использует опцию reflink.

Текст ответа Padraig Brady на английском
It's not the default since for robustness reasons one may want a copy to take place to protect against data corruption. 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. Note that from coreutils v8.24 mv will reflink by default, since it doesn't have the above constraints.

В плане скорости для mv практически нет никакой пользы от CoW при перемещении файлов. В пределах одной файловой системы mv практически всегда работает очень быстро.

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

Разбор аргументов Padraig


В первом аргументе есть кое-какой смысл. Неискушенные пользователи действительно могут делать бэкапы ценных файлов на одной и той же файловой системе.

Второй аргумент. Если почитать дальнейшие комментарии насчёт лагов от Padraig, то обнаружится, что он имел в виду ситуации с базами данных, когда при записи в существующий файл может возникнуть задержка из-за того, что файловая система будет искать свободное место. Но в случае CoW-файловой системы всегда будут искаться новые сектора для записи в силу природы CoW, как заметил Jan Kanis. Поэтому, по моему мнению, второй аргумент несостоятелен.

Однако на CoW системах действительно можно получить задержку или даже ошибку “Закончилось пространство” при записи в файл базы данных. Для избежания этого нужно для базы изначально создавать пустой каталог с отключенным CoW.

Отключается CoW на каталоге/файле так:

chattr +C /dir/file
chattr +C /dir/dir

Есть ещё опция монтирования nodatacow. Она будет применена ко всем новосоздаваемым файлам.

Как всё-таки быть, если мы хотим по умолчанию использовать CoW при копировании?


  1. Радикальный путь — это патчить coreutils. Возможно, создать свой пакет в своём частном репозитории.

    Патчим файл cp.c:

    -x->reflink_mode = REFLINK_NEVER;
+x->reflink_mode = REFLINK_AUTO;
  2. Менее радикальное решение — это прописать алиас cp для вашей оболочки. Для bash, например:

    В папке /etc/profile.d создаём файлик cp_reflink.sh c содержимым:

    #!/bin/bash
alias cp='cp --reflink=auto'

    Это решение будет работать почти во всех случаях, когда к cp идёт обращение из оболочки по имени. Но если в скриптах будет использоваться /bin/cp, то алиас не сработает и копирование будет происходить по старинке.

Файловые менеджеры и reflink


Состояние на 31 октября 2019 года:

  • Midnight Commander — поддерживает.
  • Krusader — не поддерживает.
  • Dolphin — не поддерживает.
  • Nautilus — не поддерживает.
  • Nemo — поддерживает.

Языки программирования, системные вызовы и reflink


В большинстве языков программирования поддержка reflink отсутствует.
На Си многие программисты до сих пор копируют с помощью циклов и буферов.

Системный вызов sendfile не использует reflink.
cp использует системный вызов ioctl с флагом FICLONE.

Я думаю, если нужно в коде что-то скопировать, то желательно делать это как делает cp или просто вызвать cp --reflink=auto.

Выводы


С наступлением эпохи повсеместной виртуализации и SSD стало очень актуально использовать CoW-файловые системы. Они удобны для создания снимков, быстрого копирования. Фактически, при использовании CoW при копировании мы автоматически делаем дедупликацию данных.

Сейчас только 3 файловых системы поддерживают этот тип копирования: BTRFS, XFS и OCFS2.

Я искренне надеюсь, что поддержку reflink допилят в ZFS и NILFS2, так как по внутренним механизмам они и так поддерживают CoW.

Однако во всех дистрибутивах Linux CoW при копировании файлов отключена, и нам нужно или явно указывать соответствующие ключи, или использовать различные трюки типа алиасов или патчей.

С момента анонса Reiser4 прошло уже 18 лет, однако до сих пор лёгкое CoW копирование не вошло в нашу жизнь повсеместно.

P.S. Docker и CoW


А вы знаете что Docker поддерживает btrfs для своего хранилища? Эту опцию нужно включать. Она не выбрана по умолчанию.

CoW файловая система в теории является идеальным дополнением к лёгкой виртуализации, когда разные виртуальные машины используют одно и то же ядро.

На мой взгляд, гораздо более органично, чем OverlayFS и Aufs, которые представляют из себя технологические костыли для имитации CoW.

Для использования Btrfs в Docker нужно:

  1. В свежей (без образов и виртуальных машин) инсталляции Docker примонтировать отдельный том Btrfs к /var/lib/docker
  2. Добавить опции в конфигурационный файл запуска Docker

Для Gentoo и Calculate Linux это /etc/conf.d/docker

DOCKER_OPTS="--storage-driver btrfs --data-root /var/lib/docker"

А вот полная инструкция для всех дистрибутивов.

Дополнения из комментариев


XFS и CoW


constb (источник): На XFS тоже не всегда поддерживается CoW. Нужно создавать файловую систему c mkfs.xfs -m reflink=1.
Уже на созданной ФС «включить» поддержку CoW нельзя. плюс, на ядрах до 4.11 включение этой опции вызывает красные варнинги в dmesg о том что фича – экспериментальная.

MacOS и CoW


MMik (источник): В OS X подобная опция команды cp – это -c.

Она включает использование атомарного системного вызова clonefile(), который создаёт запись в файловой системе о новом файле, в котором ссылки на блоки данных идентичны оригиналу. Копируются атрибуты и расширенные атрибуты файла, записи списков контроля доступа (ACL), за исключением информации о владельце файла и со сбросом setuid/setgid битов. Работает в пределах одной файловой системы, требует поддержки файловой системой (атрибут ATTR_VOL_CAPABILITIES, флаг VOL_CAP_INT_CLONE).

Поддерживается начиная с OS X 10.12 (Sierra) и только в файловой системе APFS.

Благодарности:

  • Компании RUVDS за поддержку и возможность публикации в своем блоге на Хабре.
  • За изображение TripletConcept.

P.P.S. Замеченные ошибки направляйте в личку. Повышаю за это карму.


Вы можете поэкспериментировать с CoW-файловыми системами, заказав виртуальную машину у RUVDS по купону ниже.

Комментарии (91)


  1. mr_tron
    30.10.2019 13:22
    #20824670

    Да в линуксе полно няшных свистелок, которые по-умолчанию выключены. Хочешь свистелок — будь добр пересобери ядро, пропатч исходники, поставь пакеты и напиши такие-то конфиги.
    Сжатие памяти, снэпшоты фс, кэш hdd на ssd, CoW, апдейт ядра без перезапуска и тысячи подобных штук. Технологии есть — внедрения нет.


    1. Yaris
      30.10.2019 14:35
      #20825066

      IMHO, те, кому эти няшные свистелки действительно нужны, знают об их наличии и о том, как их включить (или способны найти способ их включить). Остальным либо не так уж и нужно, либо и вовсе опасно давать такое по умолчанию.
      У нас народ про network namespaces узнал год назад, когда я предложил их использовать для поднятия нескольких идентичных копий сервиса на одной машине. Хотя в iproute они присутствуют уже давно, даже пересобирать ничего не надо. Вот так "надо" было.


      1. Gordon01
        31.10.2019 09:08
        #20828186

        Набоp кожи, механических насадок, вибpатоpов pазных pазмеpов, фиксатоpов потенции. В пpинципе всё это можно собpать в офигительный член. Hо те, комy нyжен член, этого сделать не могyт. А те, котоpые могyт из этого что-то собpать — не нyждаются в члене. ©


    1. dimkrayan
      30.10.2019 15:39
      #20825410

      имхо, дело только в целесообразности. Все это решается на уровне дистрибутива (да и практически все они кастомизируют ядро)


    1. eumorozov
      30.10.2019 16:48
      #20825832

      А где снэпшоты фс спрятаны? В btrfs они вроде нигде не спрятаны: бери да пользуйся.


    1. Foror
      02.11.2019 10:20
      #20838260

      >тысячи подобных штук
      Огласите весь список, пожалуйста. Или хотя бы где посмотреть по частям?


  1. e_fail
    30.10.2019 14:41
    #20825098

    Вместо /bin/cp положить баш-скриптик, который будет вызывать /bin/cp_old, добавляя к параметрам --reflink=auto?


    1. urtow
      30.10.2019 14:54
      #20825160

      Месье знает толк.
      Обычно справляются простым alias


    1. Yaris
      30.10.2019 15:36
      #20825390

      Однажды, ещё на Solaris 8 (или 9), я положил "скриптик", который вызывал системную команду внутри. И перезагрузил сервак.
      После 2хчасового интенсивного секса с незагружающейся системой (в итоге всё же обошлось без переустановки) я подумал, что больше так делать не стоит...


    1. Ad3pt
      31.10.2019 00:33
      #20827594
      +3

      А потом при следующем апдейте /bin/cp все сломается, и никто про этот костыль не вспомнит :)


  1. geov
    30.10.2019 14:46
    #20825110

    chattr +C /dir/file скорее всего не заработает на btrfs. В документации на chattr написано что работает только на директориях и пустых файлах. Таким образом нужно поставить +С на директорию и скопировать файл без reflink.

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


    1. inetstar Автор
      30.10.2019 14:47
      #20825118

      Насколько я понял, это работает на НОВЫХ файлах, а не на обязательно пустых.


      1. geov
        30.10.2019 14:51
        #20825128

        Отчасти верно, если на директории стоит +C, то он будет применяться к новым файлам в ней. Или вы можете в своем приложении при создании файла выставить этот атрибут.


        1. inetstar Автор
          30.10.2019 15:01
          #20825208

          Я имел ввиду, что в любой директории (даже, если у неё нет флага +C), если на любом новом файле выставить +С, то именно для этого файла 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. geov
            30.10.2019 15:26
            #20825336
            +1

            root@gv-pc[/mnt/backup]#lsattr rsync.sh
            -------------------- rsync.sh
            root@gv-pc[/mnt/backup]#chattr +C rsync.sh
            root@gv-pc[/mnt/backup]#lsattr rsync.sh
            -------------------- rsync.sh
            root@gv-pc[/mnt/backup]#


            Не выставляется просто :( Возможно можно еще скрестить с дефрагментацией…


  1. Ramzzza
    30.10.2019 18:20
    #20826340


    1. inetstar Автор
      30.10.2019 18:20
      #20826344

      Отключено в команде cp. В статье об этом.


      1. AEP
        31.10.2019 03:47
        #20827874

        Статья однобокая.

        1. Акцент почему-то только на cp, тогда как всякие менеджеры виртуальных машин (тот же VirtualBox или libvirt), файловые менеджеры с GUI, а также сетевые хранилища типа NextCloud не используют cp. Еще стоило бы посмотреть на ситуацию с точки зрения разработчика — да, на Си сделать reflink легко, а на другом языке?

        2. Акцент сделан на Linux и ни слова не сказано про macOS, где copy on write тоже есть.


        1. qrKot
          01.11.2019 10:51
          #20833674
          +2

          2. Акцент сделан на Linux и ни слова не сказано про macOS, где copy on write тоже есть.


          И действительно странно! Почему в статье «Что не так с Copy-on-Write под Linux» ни слова про macOS?


          1. AEP
            01.11.2019 11:38
            #20833980
            -2

            Да, странно! Без сравнения с другими решениями, не будет оснований называть статью «Что не так с Copy-on-Write под Linux». Будет что-то вроде «Что не так с Copy-on-Write вообще, на примере реализации в Linux».


            1. qrKot
              01.11.2019 13:50
              #20834776
              +2

              Вы меня простите, конечно, но ваша логическая цепочка кажется мне, как минимум, странной.

              Вы пеняете на то, что в статье «Что не так с 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…


        1. inetstar Автор
          01.11.2019 12:30
          #20834294

          Я добавил в статью про поддержку reflink файловыми менеджерами и про macOS (конец статьи).

          Очень многие пакеты под капотом используют cp. Я бы не стал так бескомпромиссно утверждать, что libvirt, VirtualBox, NextCloud нигде в своём коде не используют cp. Совершенно не все разработчики любят писать свои «велосипеды».


          1. AEP
            01.11.2019 14:44
            #20835130
            -1

            Бескомпромиссное утверждение основано на том, что необоснованные вызовы system(), posix_spawn(), execve() и подобных API не пройдут ревью кода безопасниками. Каждый вызов cp — это необходимость думать, а не передадут ли в качестве одного из аргументов что-то, что cp посчитает не файлом или каталогом, а опцией. И еще, в достаточно высокоуровневых языках есть готовые функции-утилиты для рекурсивного копирования каталогов. Python: shutil.copytree().


  1. muxa_ru
    30.10.2019 18:21
    #20826350

    Что не так с системой создающей у пользователя ошибочное впечатление того что файлов ДВА, в то время как файл ОДИН ?


    Да, вобщем то, всё.


    Неискушенные пользователи действительно могут делать бакапы ценных файлов на одной и той же файловой системе.

    Копирование на ту же файловую систему — один из вариантов резервирования. Носитель может умереть не сразу, а начать сыпаться по частям. Не самый лучший, но нормальный.


    Кроме бэкапленья, есть другие варианты необходимости копирования.


    • Скопировать файлы и потестить что-нибудь связанное с редактированием этих файлов
    • Иметь какой-нибудь шаблонный файлик, типа договора, который копируется по мере необходимости
    • Иметь исходные картинки, скопировать и массово их обработать. Например, отресайзить и наложить логотип
    • Брать какой нибудь файл, например скрипт, копировать и использовать его в качестве основы для другого файла.

    Есть много разных случаев, когда пользователь может иметь условный "эталон" копировать его и проводить операции с копиями.


    1. eumorozov
      30.10.2019 18:36
      #20826424
      +9

      Кроме бэкапленья, есть другие варианты необходимости копирования.

      Во всех перечисленных вариантах, кроме бэкапа, CoW не будет помехой. Это не hard link.


      1. muxa_ru
        30.10.2019 19:10
        #20826540
        +1

        Спасибо.
        Понял.


        Увы, из текста постинга это не следует, поэтому список отменяется.


        Но тогда это создаёт другую проблему — возможность внезапного появления кучи реальных файлов.


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


        1. inetstar Автор
          30.10.2019 19:38
          #20826682
          +5

          Увы, из текста постинга это не следует


          Вот что меня удивляет: смысл поста — это именно CoW при копировании. А вы говорите, что из текста не следует.

          за счёт появления несуществовавших файлов


          Они существовали. Просто при перезаписи под них начинает выделяться дополнительное место.


          1. muxa_ru
            30.10.2019 20:56
            #20826936
            -3

            Они существовали. Просто при перезаписи под них начинает выделяться дополнительное место.

            Осталось объяснить это конечным потребителям.


          1. JPEGEC
            31.10.2019 05:19
            #20827920

            Я может чего не понимаю.
            Но вот ситуация, у нас, предположим

            решением для лёгких виртуальных машин и контейнеров. Ведь мы могли бы не тратить место на одинаковые файлы

            И по какой-то причине крешится сектор диска.
            Вы теряете файл не в одной ВМ или контейнере а во всех, такая себе радость на мой взгляд.
            Сама фича не плохая, а то что по дефолту она выключена, на мой взгляд просто замечательно. Все кто нуждается могут включить, для прочих она скорее опасна чем полезна.


            1. inetstar Автор
              31.10.2019 09:26
              #20828246

              На ссд я что-то не сталкивался с крешем одиночных секторов. Если же говорить про тех, кто очень люьит использовать много виртуалок, то они у них живут на рейде.


              1. JPEGEC
                31.10.2019 09:51
                #20828370

                Ну речь не про солидных парней с кучей виртуалок и рейдами (подозреваю хостеров).
                А про обычного массового пользователя, для которого и собираются дистрибутивы с дефолтными настройками. И у которого нормой десяток докеров и пяток виртуалок. Потерять их все разом радости так же мало.
                Помню была бага с XFS, когда при потере питания избирательно обнулялись незакрытые файлы. Очень было неприятно и иногда даже больно. Если бы я тогда узнал что это фича, я был бы довольно несдержан в своих словах.


            1. Goodkat
              31.10.2019 10:06
              #20828456

              И по какой-то причине крешится сектор диска.

              В этом случае весь диск выбрасывается, а данные восстанавливаются из бэкапа.
              Тем более в вашем случае, когда потерялись не самые свежие изменения в одной из ВМ, а общая часть всех ВМ, т.е. неизменённая, которая точно есть в бэкапе или там, откуда вы её скачали.


              1. JPEGEC
                31.10.2019 10:13
                #20828482

                В этом случае весь диск выбрасывается, а данные восстанавливаются из бэкапа.

                Вы это сейчас про обычного массового пользователя линукса? Мне кажется вы большой оптимист.
                И основная то проблема даже не в том что файл погиб (его копию можно найти, скопировать), а то что вполне вероятно что без оного файла система не стартанет (виртуалка) и потребуется разбираться что там и почему. Радости не много.


                1. Goodkat
                  31.10.2019 10:31
                  #20828594

                  Вы это сейчас про обычного массового пользователя линукса? Мне кажется вы большой оптимист.
                  Обычный массовый рользователь линукса — это кто? У меня на предприятии несколько тысяч пользователей линукса — думаю, это и есть «обычные массовые пользователи». При любой проблеме с диском (да и при многих других) такой пользователь берёт из шкафа новый диск на салазках, вставляет его в свой компьютер взамен проблемного и работает дальше.

                  А если у кого-то несколько клонированных виртуальных машин, то это не массовый пользователь, а как минимум айтишник или человек в айти разбирающийся, который сознательно выбрал линукс и файловую систему с CoW, и он точно знает про бэкапы.


                  1. JPEGEC
                    31.10.2019 10:45
                    #20828678

                    Обычный массовый рользователь линукса — это кто?

                    Обычный, это который не системный. У которого нет шкафа, а которому нужно ехать в магазин и тратить кровные.
                    А если у кого-то несколько клонированных виртуальных машин, то это не массовый пользователь, а как минимум айтишник

                    Как по мне нормальный обычный пользователь. Пусть и айтишник.
                    И сильно сомневаюсь что на каждый вылетевший сектор побежит в магазин тратить 200-300 баксов.
                    По вашим словам судить, так у каждого айтишника все личные/домашние системы на рейдах, с бэкапами в облако, резервированием интернет канала и бесперебойником зацепленном на генератор. Может такое и имеет место быть но явно не в моей реальности.


                    1. Goodkat
                      31.10.2019 12:22
                      #20829228

                      И сильно сомневаюсь что на каждый вылетевший сектор побежит в магазин тратить 200-300 баксов.
                      Первый вылетевший сектор означает, что вслед за ним в любой момент времени вылетит второй, третий, и т.д., а значит этим диском лучше не пользоваться, так как на восстановление данных придётся потратить намного больше времени, чем стоит новый диск.

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


                      1. JPEGEC
                        01.11.2019 04:52
                        #20832838

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

                        Почему нет? Ну потеряются, и черт с ними. Перекачают заново свои торенты например. Или вышеупомянутый докер переразвернут, или виртуалку накатят заново. Это как бы не повод тратить 200 баксов на новый диск, это не продакшен.
                        Ради любопытства посмотрите какое количество бу памяти и дисков скупается на али. И люди довольны и счастливы. Реальность она такая вот.


                        1. Alexsey
                          01.11.2019 21:09
                          #20837150

                          Все очень сильно зависит от количества секторов.

                          На моей практике еще не было случаев когда 100+ битых секторов лавинообразно не убили бы за собой весь диск за считанные часы или дни.

                          А вот пара дисков с 2-3 секторами, вылетившими через месяц после покупки, уже лет 6 живут в домашнем компе.


      1. vanxant
        30.10.2019 19:38
        #20826680
        +1

        Будет, если например не хватит места в процессе.


  1. nikitych
    30.10.2019 19:21
    #20826594
    +6

    А вы знаете что Docker поддерживает btrfs для своего хранилища? Эту опцию нужно включать.
    Лучше не надо. btrfs graphdriver в Docker кривоват и имеет несколько багов пара из которых фатальны. Особенно опасно реализованы квоты. Пару лет назад я пытался его запатчить но всё руки не доходят пропихнуть в апстрим.
    Во общем сейчас связка OverlayFS поверх btrfs надёжнее.


    1. inetstar Автор
      30.10.2019 19:21
      #20826598
      +1

      Что такое graphdriver?


      1. nikitych
        30.10.2019 19:33
        #20826654

        А, простите это термин из внутренностей docker.
        В конфигах это называется storage-driver.


    1. typ6o0jiehb
      31.10.2019 05:38
      #20827924

      не знаю про какие квоты Вы, но сами квоты в btrfs использовать по факту нельзя.
      когда я включил qouta (включил функцию — btrfs quota enable, но не выставил ограничений) на btrfs и использовал это для того чтобы смотреть размеры снапшотов (btrfs-du) — всё было красиво, но когда я попробовал удалить один снапшот — btrfs-cleaner сожрал всё память и дальше у меня было увлекательных несколько дней в поисках решений. Баг до сих пор присутствует


      1. inetstar Автор
        31.10.2019 09:29
        #20828258

        Ссылка дана на баг-трекер Red Hat. А в баг-трекере Btrfs что говорят про это?


      1. inetstar Автор
        02.11.2019 23:23
        #20840090

        Обнаружил в Changelog Btrfs. Ядро 5.0. Март 2019 г.
        «fix a crash due to a race when quotas are enabled during snapshot creation»

        Похоже на баг, о котором вы говорили.


        1. typ6o0jiehb
          03.11.2019 05:16
          #20840518

          Я в августе этого года это делал. Скачал archiso свежий на тот момент. И.е. ядро было 5.x (точнее не помню), и проблема продолжала наблюдаться. При монтировании fs, через примерно час 2гб ОЗУ заканчивались и все вставало колом. Я перезагружал, монтировал и наблюдал опять процесс btrfs-cleaner который бух по памяти. Потом узнал про квоты, выключил и как то помогло. Тоже не с первого раза получилось.
          К сожалению всего алгоритма я не записал, но с проблемой бился несколько дней в свободные часы (домашний сервер на 6 разных дисках btrfs разделом на 14 Тб).
          Т.е. я полагаю, что проблема не решена. Но это отдельный кейс, который по умолчанию выключен


  1. slonopotamus
    30.10.2019 19:29
    #20826630
    +2

    На мой взгляд, проблема CoW-FS отнюдь не в coreutils. А в том что надо учить весь софт, занимающийся в том или ином виде копированием файлов, вызывать новый syscall.


    А ещё CoW — не серебряная пуля, и на части сценариев будет работать хуже/медленнее чем не-CoW.


  1. MMik
    30.10.2019 21:17
    #20827002
    +6

    В OS X подобная опция команды cp – это '-c'.

    Она включает использование атомарного системного вызова clonefile(), который создаёт запись в файловой системе о новом файле, в котором ссылки на блоки данных идентичны оригиналу. Копируются атрибуты и расширенные атрибуты файла, записи списков контроля доступа (ACL), за исключением информации о владельце файла и со сбросом setuid/setgid битов. Работает в пределах одной файловой системы, требует поддержки файловой системой (атрибут ATTR_VOL_CAPABILITIES, флаг VOL_CAP_INT_CLONE).

    Поддерживается начиная с OS X 10.12 (Sierra) и только в файловой системе APFS.


    1. inetstar Автор
      01.11.2019 12:32
      #20834302

      Добавил ваш коммент в конец статьи.


      1. MMik
        01.11.2019 12:39
        #20834356

        Хорошо. Можете и для других систем найти подобное: BSD и пр.


  1. le1ic
    30.10.2019 23:57
    #20827532
    +1

    По-моему проблема не в ФС и не в cp, а в том, что это мало кому нужно. Я не знаю, когда я последний раз создавал копии файлов на одном диске и при этом это было критично по времени.


    1. inetstar Автор
      31.10.2019 00:55
      #20827638
      +1

      При обновлении системы, установке пакетов такое происходит автоматически. Есть масса процессов, которые проходят невидимо для пользователя, но в которых эта оптимизация бы дала прирост скорости.


      1. le1ic
        31.10.2019 08:39
        #20828116

        Цифры в студию, как говорится. Покажите сколько времени занимает установка пакета, включая время на написание команды в терминале, скачивание его, апдейт локального репозитория, и сколько из этого времени тратится на копирование файлов.

        У меня пакеты дольше скачиваются, чем устанавливаются (скорость i/o в 10 раз все-таки отличается). Обновления либо вообще в фоне автоматом, либо если вручную, то с перезагрузкой. Опять время установки по сравнению со временам скачивания и перезагрузкой пренебрежимо мало.

        И вообще это примеры задач, некритичных по времени, и не являющимися основной работой компьютера.


        1. inetstar Автор
          31.10.2019 09:36
          #20828294

          А вот на Gentoo пакеты собираются из исходников. Там собираются дольше, чем скачиваются.


          В любом случае reflink быстрее и экономичнее в плане дискового пространства.


          Насчёт цифр. Всё, где используется cp теряет в скорости минимум в 5 раз. Большинство процессов linux использует её, а не пишут свои велосипеды копирования.


    1. MMik
      31.10.2019 01:36
      #20827724
      +1

      Виртуалками не пользуетесь? Машинным обучением не занимаетесь? А там этот функционал нужен и полезен.


      1. VolCh
        31.10.2019 07:21
        #20827986

        А виртуалки тут каким боком?


        1. inetstar Автор
          31.10.2019 09:38
          #20828300

          Когда много виртуалок на основе одного и тоже дистрибутива или образа, то будет значительный выигрыш в плане дискового пространства.


        1. MMik
          31.10.2019 15:00
          #20830172

          Запуск виртуальных машин из образа (снимка, клона) или шаблона – это отличный вариант для использования CoW.


      1. le1ic
        31.10.2019 08:45
        #20828124

        Я матстатистикой и обработкой данных занимаюсь. Долгая по времени процедура не считая расчетов — это скачивание логов или данных из облака или с серверов. Локально многогигабайтные файлы клонировать как-то не нужно было, а все что меньше 100мб — вопрос одной секунды, дольше «cp» набирать. Да и даже этим я не пользуюсь, обычно мне файл нужен в единственном экземпляре.

        Виртуалками — смешно, у меня вся среда на виртуалках — и разработка (linux в vitrualbox на маке) и в продакшене — k8s кластер на EC2. Копирование никогда не было проблемой, даже вопросов таких не возникало. Что вы такого делаете с виртуалками?


        1. inetstar Автор
          31.10.2019 09:39
          #20828316

          cp используется под капотом Linux везде. В том числе и в Амазон.


        1. MMik
          31.10.2019 15:08
          #20830214

          Запуск виртуальных машин из образа (снимка, клона) или шаблона – это отличный вариант для использования CoW.

          DVC для данных машинного обучения и git-annex для Git под капотом используют CoW/RoW reflink(), если файловая система это поддерживает.


  1. Alexsey
    31.10.2019 00:02
    #20827546

    Раз уж зашел разговор про CoW — есть какие-нибудь примеры того насколько все плохо с фрагментированием и, соответственно, производительностью таких файловых систем на обычных HDD? Хотел перевести домашний сервер на zfs (в первую очередь из-за проверки целостности данных, хотел сунуть 2-3 зеркала в 1 zpool), но боюсь как бы не получить тормозное нечто в итоге.


    1. inetstar Автор
      31.10.2019 01:09
      #20827678

      Просадка будет на данных, которые часто перезаписываются: почтовые БД, просто база данных. Такая просадка, что терпеть её можно только на ССД.
      Когда есть некие большие файлы, в которых перезаписываюся некие фрагменты.

      А в остальном всё летает.


  1. MMik
    31.10.2019 01:38
    #20827734

    Предлагаю следующую статью в догонку про Redirect-on-write написать, inetstar.


    1. inetstar Автор
      31.10.2019 01:48
      #20827742

      Вообще-то в NILFS2 так и пишутся данные. Но всё равно называется CoW почему-то.


      1. MMik
        31.10.2019 02:14
        #20827794
        +1

        Вот будет возможность вникнуть и рассказать детали по разным ФС и менеджерам томов, где там CoW, а где RoW.


  1. MMik
    31.10.2019 02:14
    #20827792

    del


  1. constb
    31.10.2019 07:50
    #20828028
    +2

    на XFS тоже не всегда поддерживается CoW. нужно создавать файловую систему c mkfs.xfs -m reflink=1. уже на созданной ФС «включить» поддержку CoW нельзя. плюс, на ядрах до 4.11 включение этой опции вызывает красные варнинги в dmesg о том что фича – экспериментальная… в остальном работает. использую на свалке картинок нескольких сайтов (debian stretch), время от времени гоняю по ней duperemove…


    1. inetstar Автор
      01.11.2019 12:33
      #20834308

      Добавил ваш коммент в конец статьи.


  1. Enchant
    31.10.2019 10:18
    #20828524
    +1

    Тут проблема не в 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 все ОК — оно работает ровно так как и задумывалось.


    1. inetstar Автор
      31.10.2019 11:19
      #20828854

      Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?

      Reflink — это тот же снимок только более гибкий. На уровне файла.

      2. восстановления целостности файла при сбое (по питанию)

      А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.


      1. Enchant
        31.10.2019 12:38
        #20829320

        > Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?

        Ничего плохого, я лишь указываю, что это не основная цель этой технологии и что с основными целями COW в Linux отлично справляется. Главная задача COW быть небольших базовым кирпичиком который позволяет реализовывать в том числе и дедупликацию, но именно реализовывать там где это нужно (вот в docker например), а не предоставлять это по-умолчанию.

        В docker, кстати, дедупликация реализуется вовсе не через cp с ключиком, а явно через снимки файловой системы (что супер быстро, в отличии от cp).

        > А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.

        Верно. И я указываю на то, что COW позволяет сильно проще (насколько проще, что это прям оправдывает создание этой технологии только для этого) и надежнее реализовывать механизмы обеспечения целостности в ФС.


      1. gmelikov
        01.11.2019 09:26
        #20833254

        Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?

        Тем, что эти плюшки достаются не бесплатно, а какой-то ценой. По этой причине включать все возможности по умолчанию без обоснования — противопоказано.


        1. inetstar Автор
          01.11.2019 12:39
          #20834350

          В данном случае есть очень серьёзная цена и у неиспользования новых технологий.
          Аргументы человека, который запретил использование reflink по умолчанию, разобраны в статье. И я нашёл их несостоятельными.

          И не только я. Но и разработчики некоторых файловых менеджеров.


          1. gmelikov
            01.11.2019 13:06
            #20834518

            Ну я вам про конкретные в комментарии вашем — дедупликация та же, она далеко не бесплатна.

            Так же и с аргументами про reflink — вы сами соглашаетесь с первым его аргументом. И, касаемо reflink — это нарушение стандартного поведения, не без последствий. А их без веской причины вообще менять не любят.

            Вы приводите аргументы за 1 конкретный юзерский сценарий «быстро копировать файлы». В то время, как другие сценарии могут быть сильно весомее. И тут я согласен по поводу того, что при смене поведения сильно пострадают сценарии, рассчитывающие на быструю работу с файлами после копирования.

            Поймите меня правильно, я за reflink. Но не всё так однозначно. Да и CoW тут не при чём.


            1. inetstar Автор
              01.11.2019 13:14
              #20834564

              Вы приводите аргументы за 1 конкретный юзерский сценарий «быстро копировать файлы».


              Во-первых это не юзерский сценарий. Масса пакетов и программ делают это автоматически без ведома юзера.

              А во-вторых в случае reflink дедупликация даётся бесплатно.

              На мой взгляд reflink без CoW невозможен. В основе снимков лежит тот же механизм, что и у reflink.


              1. gmelikov
                01.11.2019 14:02
                #20834850

                Во-первых это не юзерский сценарий. Масса пакетов и программ делают это автоматически без ведома юзера.


                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


                1. inetstar Автор
                  01.11.2019 14:10
                  #20834904

                  А что такое DDT?
                  Я вот увидел следующую фразу:

                  The technique described cannot be applied to existing ZFS datasets

                  Ну так это не проблема. У XFS тоже нужно ФС заново воздавать, чтобы reflink заработали.

                  А вот то, что у ZFS reflink нет — это печально.

                  Насчёт нашлёпки на ext4. Из википедии:
                  Идея подхода copy-on-write заключается в том, что при чтении области данных используется общая копия, в случае изменения данных — создается новая копия.

                  Эта нашлёпка, если будет работать так, то это будет CoW.


                  1. gmelikov
                    01.11.2019 14:21
                    #20834966

                    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 файлам, близкие к реальным кейсам — было бы интересно на них посмотреть, спасибо!


    1. catharsis
      01.11.2019 15:05
      #20835224

      LVM снапшоты тоже ведь copy-on-write, почему они дороже?


      1. inetstar Автор
        01.11.2019 15:23
        #20835326
        -1

        Там большой размер блока. Что-то около 4 мегабайта по умолчанию. Много места теряется при небольших изменениях.


      1. Enchant
        01.11.2019 15:35
        #20835420
        +1

        Там есть разница в подходе к записи данных. В случае записи в файл под LVM snapshot физическая запись выполняется в тоже самое физическое место (т.е. как будто это обычная запись) и одновременно с этим выполняется копирование предыдущего состояния данных в новое место.
        Если проще — то во время записи создаётся бэкап старой записи и кладётся в отдельно место. Т.е. выполняется две операции записи, поэтому это медленнее.

        Так сделано, потому что LVM snapshot универсальная прослойка для любой ФС, а сделать по другому без знания внутренностей ФС не получиться.


    1. inetstar Автор
      01.11.2019 15:22
      #20835316

      И это не так хотя бы потому, что в Linux всегда был способ копирования без физического копирования — hard link — работает на любой (почти) ФС и за долго до появления COW. Мы можете сделать тот же алиес для команды cp, чтобы использовать hard link.


      Хардлинк — это всего-лишь алиас. Если изменить файл-копию, то изменится и оригинал.
      Reflink, с точки зрения пользователя, — это полноценная копия, которая, пока её не изменили, не занимает места. Ну и скорость копирования феноменальная, конечно.

      И всё-таки основная задача CoW — это экономия места. Из Википедии:

      Идея подхода copy-on-write заключается в том, что при чтении области данных используется общая копия, в случае изменения данных — создается новая копия.


      1. gmelikov
        01.11.2019 15:47
        #20835488

        И всё-таки основная задача CoW — это экономия места. Из Википедии:

        Вы вырвали из контекста как-то :) По умолчанию в CoW нет общих копий. Другой вопрос, что т.к. блок данных никогда не переписывается, позволяет его не удалять и использовать в других целях. Но это больше бонус, нежели цель.

        И я вас расстрою — CoW всегда будет требовать больше пространства, чем классический подход. При заполнении более 90% любая CoW-like ФС начинает сильно деградировать по записи, т.к. свободное место дико фрагментировано и поиск свободного места нужного размера становится очень дорог. Да, это пытаются нивелировать всякими плюшками типа компрессии. Но это не основная цель CoW!


        1. inetstar Автор
          01.11.2019 21:06
          #20837140

          А какая основная цель CoW?

          В ядре Линукса CoW был придуман именно для экономии оперативной памяти для переменных процессов при fork().

          По-моему — это исторически первая работающая реализация CoW.


          1. RomanStrlcpy
            01.11.2019 22:33
            #20837478

            В ядре COW больше для экономии места и скорости создания нового процесса. Для хранилищ я думаю COW это повышенная надежность в первую очередь.


          1. gmelikov
            02.11.2019 12:47
            #20838534

            А какая основная цель 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.

            Увы, но это не так, см. выше.


            1. inetstar Автор
              02.11.2019 14:29
              #20838764

              Вы так чётко утверждали:

              Но это не основная цель CoW!

              Как-будто знаете основную цель. Но назвать её так и не смогли.

              В SunOS CoW, как я понял, был создан также для экономии памяти. Ускорение, на мой взгляд, тут неочевидно, так как механизмы CoW тоже потребояют процессорное время.

              Насчёт дедупликации. Устранения дублирующей информации.
              CoW по своей логике автоматически обеспечивает дедупликацию, так как хранит только различающиеся данные.
              Просто в ZFS дедупликация сделана через DDT, а не через механизмы CoW. Это специфика реализации ZFS.


  1. DrunkBear
    31.10.2019 10:32
    #20828602

    Однако у Ханса Райзера поехала крыша и он убил жену, а его детище (скорее всего по политическим причинам) не включили в ядро.
    Восхитительно. Несколько лет коту под хвост, потому что разработчик оказался плохим парнем? Опасались, что через код передастся сумасшествие или пользоваться такими фичами — неполиткорректно?


    1. acmnu
      31.10.2019 11:23
      #20828872

      Он был ведущим разрабом там. Без него проект как-то сам заглох. Желающих продолжить в целом было не мало, но во-первых, на тот момент ещё не пришла эпоха ssd, а на hdd из-за фрагментации были проблемы с производительностью, а во-вторых, одно дело хотеть разрабатывать fs и совсем другое дело уметь это делать — людей, которые на профессиональном уровне занимаются fs в мире очень мало.
      А про политические причины, это мнение автора. На самом деле на момент ареста код был не готов ко включению в ядро. Надо было привести код в соответствие стандартам Linux Kernel и это по факту никто так и не сделал, а потом стало поздно ибо внимание переключилось на btrfs/zfs и позже xfs, а потом интерес к теме упал: часть функционала r4 появилась в ext4, часть в btrfs/zfs.


      1. inetstar Автор
        31.10.2019 12:40
        #20829332

        Он выбивал деньги для всей команды. А без денег всё сразу заглохло.