Что не так с Copy-on-Write под Linux при копировании



    Предупреждение: эта статья относится ко всем 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 файловых систем?

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

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

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

    Текст ответа Pádraig 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 практически всегда работает очень быстро.

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

    Разбор аргументов Pádraig


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

    Второй аргумент. Если почитать дальнейшие комментарии насчёт лагов от Pádraig, то обнаружится, что он имел в виду ситуации с базами данных, когда при записи в существующий файл может возникнуть задержка из-за того, что файловая система будет искать свободное место. Но в случае 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 по купону ниже.

    RUVDS.com
    1 513,05
    RUVDS – хостинг VDS/VPS серверов
    Поддержать автора
    Поделиться публикацией

    Комментарии 103

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

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

          –6

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

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

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

              0
              >тысячи подобных штук
              Огласите весь список, пожалуйста. Или хотя бы где посмотреть по частям?
              0
              Вместо /bin/cp положить баш-скриптик, который будет вызывать /bin/cp_old, добавляя к параметрам --reflink=auto?
                +10
                Месье знает толк.
                Обычно справляются простым alias
                  +4

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

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

                    Помимо того в документации на btrfs раньше было написано, что в некоторых пределах, ядро пытается делать CoW при записи одинаковых данных. Сейчас не могу найти.
                      0
                      Насколько я понял, это работает на НОВЫХ файлах, а не на обязательно пустых.
                        0
                        Отчасти верно, если на директории стоит +C, то он будет применяться к новым файлам в ней. Или вы можете в своем приложении при создании файла выставить этот атрибут.
                          0
                          Я имел ввиду, что в любой директории (даже, если у неё нет флага +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
                            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]#


                            Не выставляется просто :( Возможно можно еще скрестить с дефрагментацией…
                      0
                        0
                        Отключено в команде cp. В статье об этом.
                          +2
                          Статья однобокая.

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

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


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

                                Вы пеняете на то, что в статье «Что не так с 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…
                              0
                              Я добавил в статью про поддержку reflink файловыми менеджерами и про macOS (конец статьи).

                              Очень многие пакеты под капотом используют cp. Я бы не стал так бескомпромиссно утверждать, что libvirt, VirtualBox, NextCloud нигде в своём коде не используют cp. Совершенно не все разработчики любят писать свои «велосипеды».
                                –1
                                Бескомпромиссное утверждение основано на том, что необоснованные вызовы system(), posix_spawn(), execve() и подобных API не пройдут ревью кода безопасниками. Каждый вызов cp — это необходимость думать, а не передадут ли в качестве одного из аргументов что-то, что cp посчитает не файлом или каталогом, а опцией. И еще, в достаточно высокоуровневых языках есть готовые функции-утилиты для рекурсивного копирования каталогов. Python: shutil.copytree().
                          –7

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


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


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

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


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


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

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

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

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

                              0

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


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


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


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

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


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

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


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

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

                                    +1
                                    Я может чего не понимаю.
                                    Но вот ситуация, у нас, предположим
                                    решением для лёгких виртуальных машин и контейнеров. Ведь мы могли бы не тратить место на одинаковые файлы

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

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

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

                                          у которого нормой десяток докеров и пяток виртуалок.


                                          Ну-ка, ну-ка, оцените, какой процент пользователей GNU/Linux использует и ~10 докер-контейнеров, и ~5 виртуальных машин?
                                          IMHO ваша фраза абсурдна
                                            0
                                            Речь не за в точности такие числа, а в пределы до которых.
                                        0
                                        И по какой-то причине крешится сектор диска.

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

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

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

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

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

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

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

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

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

                                                    А вот пара дисков с 2-3 секторами, вылетившими через месяц после покупки, уже лет 6 живут в домашнем компе.
                                                  0
                                                  «Пусть и айтишник» знает о резервном копировании как минимум то, что его нужно делать на другой (физический) носитель. Иначк он либо не айтишник, либо ему не особо нужно содержимое диска.
                                                  Более того, айтишник, который ценит содержимое диска, работает в массиве RAID просто потому, что это и недорого, и надёжно, и производительность снижает малозаметно
                                                    0
                                                    А теперь вы расскажите про процент айтишников использующих резервное копирование и рэйд массивы.
                                                    Давайте не будем смешивать домашний и рабочий компьютер.
                                                    От того что содержимое диска не особенно нужно и его вполне можно востановить не возникает особенно сильное желание этим заниматься. Притом как правило в не самый удачный момент.

                                                    ЗЫ А у ж сколько примеров как бэкапы делались на тот же раздел что и данные, сколько было незапланированных дроптэйблов и датабэйсов и прочего подобного. Не стоит идеализировать людей вообще и айтишников в частности.
                                                      +1
                                                      По моему опыту рейд-массив повышает производительность)
                                                        0

                                                        На ноутбуке сложно RAID поднять

                                          +1
                                          Будет, если например не хватит места в процессе.
                                        +7
                                        А вы знаете что Docker поддерживает btrfs для своего хранилища? Эту опцию нужно включать.
                                        Лучше не надо. btrfs graphdriver в Docker кривоват и имеет несколько багов пара из которых фатальны. Особенно опасно реализованы квоты. Пару лет назад я пытался его запатчить но всё руки не доходят пропихнуть в апстрим.
                                        Во общем сейчас связка OverlayFS поверх btrfs надёжнее.
                                          +1
                                          Что такое graphdriver?
                                            0
                                            А, простите это термин из внутренностей docker.
                                            В конфигах это называется storage-driver.
                                            0
                                            не знаю про какие квоты Вы, но сами квоты в btrfs использовать по факту нельзя.
                                            когда я включил qouta (включил функцию — btrfs quota enable, но не выставил ограничений) на btrfs и использовал это для того чтобы смотреть размеры снапшотов (btrfs-du) — всё было красиво, но когда я попробовал удалить один снапшот — btrfs-cleaner сожрал всё память и дальше у меня было увлекательных несколько дней в поисках решений. Баг до сих пор присутствует
                                              0

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

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

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

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

                                              +3

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


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

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

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

                                                Поддерживается начиная с OS X 10.12 (Sierra) и только в файловой системе APFS.
                                                  0
                                                  Добавил ваш коммент в конец статьи.
                                                    0
                                                    Хорошо. Можете и для других систем найти подобное: BSD и пр.
                                                  +3
                                                  По-моему проблема не в ФС и не в cp, а в том, что это мало кому нужно. Я не знаю, когда я последний раз создавал копии файлов на одном диске и при этом это было критично по времени.
                                                    +1
                                                    При обновлении системы, установке пакетов такое происходит автоматически. Есть масса процессов, которые проходят невидимо для пользователя, но в которых эта оптимизация бы дала прирост скорости.
                                                      0
                                                      Цифры в студию, как говорится. Покажите сколько времени занимает установка пакета, включая время на написание команды в терминале, скачивание его, апдейт локального репозитория, и сколько из этого времени тратится на копирование файлов.

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

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

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


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


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

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

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

                                                          –1

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

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

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

                                                              0

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

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

                                                                DVC для данных машинного обучения и git-annex для Git под капотом используют CoW/RoW reflink(), если файловая система это поддерживает.
                                                            0
                                                            Раз уж зашел разговор про CoW — есть какие-нибудь примеры того насколько все плохо с фрагментированием и, соответственно, производительностью таких файловых систем на обычных HDD? Хотел перевести домашний сервер на zfs (в первую очередь из-за проверки целостности данных, хотел сунуть 2-3 зеркала в 1 zpool), но боюсь как бы не получить тормозное нечто в итоге.
                                                              +1
                                                              Просадка будет на данных, которые часто перезаписываются: почтовые БД, просто база данных. Такая просадка, что терпеть её можно только на ССД.
                                                              Когда есть некие большие файлы, в которых перезаписываюся некие фрагменты.

                                                              А в остальном всё летает.
                                                              0
                                                              Предлагаю следующую статью в догонку про Redirect-on-write написать, inetstar.
                                                                0
                                                                Вообще-то в NILFS2 так и пишутся данные. Но всё равно называется CoW почему-то.
                                                                  +1
                                                                  Вот будет возможность вникнуть и рассказать детали по разным ФС и менеджерам томов, где там CoW, а где RoW.
                                                                0
                                                                del
                                                                  +2

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

                                                                    0
                                                                    Добавил ваш коммент в конец статьи.
                                                                    +5
                                                                    Тут проблема не в 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 все ОК — оно работает ровно так как и задумывалось.
                                                                      0
                                                                      Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?

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

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

                                                                      А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.
                                                                        +1
                                                                        > Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?

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

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

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

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

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

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

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

                                                                            И не только я. Но и разработчики некоторых файловых менеджеров.
                                                                              0
                                                                              Ну я вам про конкретные в комментарии вашем — дедупликация та же, она далеко не бесплатна.

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

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

                                                                              Поймите меня правильно, я за reflink. Но не всё так однозначно. Да и CoW тут не при чём.
                                                                                0
                                                                                Вы приводите аргументы за 1 конкретный юзерский сценарий «быстро копировать файлы».


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

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

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


                                                                                  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
                                                                                    0
                                                                                    А что такое DDT?
                                                                                    Я вот увидел следующую фразу:

                                                                                    The technique described cannot be applied to existing ZFS datasets

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

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

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

                                                                                    Эта нашлёпка, если будет работать так, то это будет CoW.
                                                                                      0
                                                                                      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 файлам, близкие к реальным кейсам — было бы интересно на них посмотреть, спасибо!
                                                                          0

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

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

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

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


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

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

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

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

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

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

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

                                                                                  По-моему — это исторически первая работающая реализация CoW.
                                                                                    0
                                                                                    В ядре COW больше для экономии места и скорости создания нового процесса. Для хранилищ я думаю COW это повышенная надежность в первую очередь.
                                                                                      0
                                                                                      А какая основная цель 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.

                                                                                      Увы, но это не так, см. выше.
                                                                                        0
                                                                                        Вы так чётко утверждали:

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

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

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

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

                                                                                          Разве он по природе своей поймёт, что два файла, которые я скопировал с внешнего источника, не поддерживающего CoW, по содержимому одно и то же? По-моему, он по природе своей дедуплицирует только если источник находится на той же ФС, что и цель. А автоматически при создании нового файла (копирование со внешнего источника для ФС это создание нового) не ищет.

                                                                                            0
                                                                                            Всё верно. Только при копировании файлов из внешнего источника парадигма CoW не применяется. А везде где она реально применяется, она обеспечивает дедупликацию автоматически.
                                                                                              0

                                                                                              Так я и говорю, автоматически дедупликация применяется только в некоторых случаях.

                                                                                                0
                                                                                                В случае использования техники CoW, например)
                                                                                                  0

                                                                                                  Нет, в случае использования техники CoW, когда и источник, и цель лежат в одной области (грубо говоря, на одном разделе).

                                                                                                    0
                                                                                                    Когда источник и цель лежат на разных разделах при копировании CoW вообще не используется. Поэтому ВСЕГДА, когда используется копирование с технологией CoW, происходит автоматическая дедупликация.
                                                                                +1
                                                                                Однако у Ханса Райзера поехала крыша и он убил жену, а его детище (скорее всего по политическим причинам) не включили в ядро.
                                                                                Восхитительно. Несколько лет коту под хвост, потому что разработчик оказался плохим парнем? Опасались, что через код передастся сумасшествие или пользоваться такими фичами — неполиткорректно?
                                                                                  +1

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

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

                                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                Самое читаемое