Предупреждение: эта статья относится ко всем 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.
Вот его логика:
- По умолчанию cp не использует CoW, так как кто-то может использовать копирование для того, чтобы повысить вероятность сохранения файла на диске после разрушения файловой системы.
- С точки зрения производительности, если есть некий чувствительный к задержкам процесс, вы можете захотеть, чтобы основная запись была сделана именно во время копирования, так если это произойдёт потом, то может возникнуть лаг при перепозиционировании головок жёсткого диска. Обратите внимание, начиная с версии 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 при копировании?
- Радикальный путь — это патчить coreutils. Возможно, создать свой пакет в своём частном репозитории.
Патчим файл cp.c:
-x->reflink_mode = REFLINK_NEVER; +x->reflink_mode = REFLINK_AUTO; - Менее радикальное решение — это прописать алиас cp для вашей оболочки. Для bash, например:
В папке/etc/profile.dсоздаём файликcp_reflink.shc содержимым:
#!/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 нужно:
- В свежей (без образов и виртуальных машин) инсталляции Docker примонтировать отдельный том Btrfs к
/var/lib/docker - Добавить опции в конфигурационный файл запуска Docker
Для Gentoo и Calculate Linux это
/etc/conf.d/dockerDOCKER_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)
e_fail
30.10.2019 14:41Вместо /bin/cp положить баш-скриптик, который будет вызывать /bin/cp_old, добавляя к параметрам --reflink=auto?
Yaris
30.10.2019 15:36Однажды, ещё на Solaris 8 (или 9), я положил "скриптик", который вызывал системную команду внутри. И перезагрузил сервак.
После 2хчасового интенсивного секса с незагружающейся системой (в итоге всё же обошлось без переустановки) я подумал, что больше так делать не стоит...
Ad3pt
31.10.2019 00:33+3А потом при следующем апдейте /bin/cp все сломается, и никто про этот костыль не вспомнит :)
geov
30.10.2019 14:46chattr +C /dir/fileскорее всего не заработает на btrfs. В документации на chattr написано что работает только на директориях и пустых файлах. Таким образом нужно поставить +С на директорию и скопировать файл без reflink.
Помимо того в документации на btrfs раньше было написано, что в некоторых пределах, ядро пытается делать CoW при записи одинаковых данных. Сейчас не могу найти.
inetstar Автор
30.10.2019 14:47Насколько я понял, это работает на НОВЫХ файлах, а не на обязательно пустых.
geov
30.10.2019 14:51Отчасти верно, если на директории стоит +C, то он будет применяться к новым файлам в ней. Или вы можете в своем приложении при создании файла выставить этот атрибут.
inetstar Автор
30.10.2019 15:01Я имел ввиду, что в любой директории (даже, если у неё нет флага +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 переписываются чексуммы в метаданных, а при его отсутствии они не считаются.geov
30.10.2019 15:26+1root@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]#
Не выставляется просто :( Возможно можно еще скрестить с дефрагментацией…
Ramzzza
30.10.2019 18:20inetstar Автор
30.10.2019 18:20Отключено в команде cp. В статье об этом.
AEP
31.10.2019 03:47Статья однобокая.
1. Акцент почему-то только на cp, тогда как всякие менеджеры виртуальных машин (тот же VirtualBox или libvirt), файловые менеджеры с GUI, а также сетевые хранилища типа NextCloud не используют cp. Еще стоило бы посмотреть на ситуацию с точки зрения разработчика — да, на Си сделать reflink легко, а на другом языке?
2. Акцент сделан на Linux и ни слова не сказано про macOS, где copy on write тоже есть.qrKot
01.11.2019 10:51+22. Акцент сделан на Linux и ни слова не сказано про macOS, где copy on write тоже есть.
И действительно странно! Почему в статье «Что не так с Copy-on-Write под Linux» ни слова про macOS?AEP
01.11.2019 11:38-2Да, странно! Без сравнения с другими решениями, не будет оснований называть статью «Что не так с Copy-on-Write под Linux». Будет что-то вроде «Что не так с Copy-on-Write вообще, на примере реализации в Linux».
qrKot
01.11.2019 13:50+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…
inetstar Автор
01.11.2019 12:30Я добавил в статью про поддержку reflink файловыми менеджерами и про macOS (конец статьи).
Очень многие пакеты под капотом используютcp. Я бы не стал так бескомпромиссно утверждать, что libvirt, VirtualBox, NextCloud нигде в своём коде не используютcp. Совершенно не все разработчики любят писать свои «велосипеды».AEP
01.11.2019 14:44-1Бескомпромиссное утверждение основано на том, что необоснованные вызовы system(), posix_spawn(), execve() и подобных API не пройдут ревью кода безопасниками. Каждый вызов cp — это необходимость думать, а не передадут ли в качестве одного из аргументов что-то, что cp посчитает не файлом или каталогом, а опцией. И еще, в достаточно высокоуровневых языках есть готовые функции-утилиты для рекурсивного копирования каталогов. Python: shutil.copytree().
muxa_ru
30.10.2019 18:21Что не так с системой создающей у пользователя ошибочное впечатление того что файлов ДВА, в то время как файл ОДИН ?
Да, вобщем то, всё.
Неискушенные пользователи действительно могут делать бакапы ценных файлов на одной и той же файловой системе.
Копирование на ту же файловую систему — один из вариантов резервирования. Носитель может умереть не сразу, а начать сыпаться по частям. Не самый лучший, но нормальный.
Кроме бэкапленья, есть другие варианты необходимости копирования.
- Скопировать файлы и потестить что-нибудь связанное с редактированием этих файлов
- Иметь какой-нибудь шаблонный файлик, типа договора, который копируется по мере необходимости
- Иметь исходные картинки, скопировать и массово их обработать. Например, отресайзить и наложить логотип
- Брать какой нибудь файл, например скрипт, копировать и использовать его в качестве основы для другого файла.
Есть много разных случаев, когда пользователь может иметь условный "эталон" копировать его и проводить операции с копиями.
eumorozov
30.10.2019 18:36+9Кроме бэкапленья, есть другие варианты необходимости копирования.
Во всех перечисленных вариантах, кроме бэкапа, CoW не будет помехой. Это не hard link.
muxa_ru
30.10.2019 19:10+1Спасибо.
Понял.
Увы, из текста постинга это не следует, поэтому список отменяется.
Но тогда это создаёт другую проблему — возможность внезапного появления кучи реальных файлов.
В случае с обработкой кучи файлов это приведёт к тому, что вместо ожидаемого уменьшения (за счёт ресайза и сжатия) занятого места будет происходить его увеличение (за счёт появления несуществовавших файлов).
inetstar Автор
30.10.2019 19:38+5Увы, из текста постинга это не следует
Вот что меня удивляет: смысл поста — это именно CoW при копировании. А вы говорите, что из текста не следует.
за счёт появления несуществовавших файлов
Они существовали. Просто при перезаписи под них начинает выделяться дополнительное место.muxa_ru
30.10.2019 20:56-3Они существовали. Просто при перезаписи под них начинает выделяться дополнительное место.
Осталось объяснить это конечным потребителям.
JPEGEC
31.10.2019 05:19Я может чего не понимаю.
Но вот ситуация, у нас, предположим
решением для лёгких виртуальных машин и контейнеров. Ведь мы могли бы не тратить место на одинаковые файлы
И по какой-то причине крешится сектор диска.
Вы теряете файл не в одной ВМ или контейнере а во всех, такая себе радость на мой взгляд.
Сама фича не плохая, а то что по дефолту она выключена, на мой взгляд просто замечательно. Все кто нуждается могут включить, для прочих она скорее опасна чем полезна.inetstar Автор
31.10.2019 09:26На ссд я что-то не сталкивался с крешем одиночных секторов. Если же говорить про тех, кто очень люьит использовать много виртуалок, то они у них живут на рейде.
JPEGEC
31.10.2019 09:51Ну речь не про солидных парней с кучей виртуалок и рейдами (подозреваю хостеров).
А про обычного массового пользователя, для которого и собираются дистрибутивы с дефолтными настройками. И у которого нормой десяток докеров и пяток виртуалок. Потерять их все разом радости так же мало.
Помню была бага с XFS, когда при потере питания избирательно обнулялись незакрытые файлы. Очень было неприятно и иногда даже больно. Если бы я тогда узнал что это фича, я был бы довольно несдержан в своих словах.
Goodkat
31.10.2019 10:06И по какой-то причине крешится сектор диска.
В этом случае весь диск выбрасывается, а данные восстанавливаются из бэкапа.
Тем более в вашем случае, когда потерялись не самые свежие изменения в одной из ВМ, а общая часть всех ВМ, т.е. неизменённая, которая точно есть в бэкапе или там, откуда вы её скачали.JPEGEC
31.10.2019 10:13В этом случае весь диск выбрасывается, а данные восстанавливаются из бэкапа.
Вы это сейчас про обычного массового пользователя линукса? Мне кажется вы большой оптимист.
И основная то проблема даже не в том что файл погиб (его копию можно найти, скопировать), а то что вполне вероятно что без оного файла система не стартанет (виртуалка) и потребуется разбираться что там и почему. Радости не много.Goodkat
31.10.2019 10:31Вы это сейчас про обычного массового пользователя линукса? Мне кажется вы большой оптимист.
Обычный массовый рользователь линукса — это кто? У меня на предприятии несколько тысяч пользователей линукса — думаю, это и есть «обычные массовые пользователи». При любой проблеме с диском (да и при многих других) такой пользователь берёт из шкафа новый диск на салазках, вставляет его в свой компьютер взамен проблемного и работает дальше.
А если у кого-то несколько клонированных виртуальных машин, то это не массовый пользователь, а как минимум айтишник или человек в айти разбирающийся, который сознательно выбрал линукс и файловую систему с CoW, и он точно знает про бэкапы.JPEGEC
31.10.2019 10:45Обычный массовый рользователь линукса — это кто?
Обычный, это который не системный. У которого нет шкафа, а которому нужно ехать в магазин и тратить кровные.
А если у кого-то несколько клонированных виртуальных машин, то это не массовый пользователь, а как минимум айтишник
Как по мне нормальный обычный пользователь. Пусть и айтишник.
И сильно сомневаюсь что на каждый вылетевший сектор побежит в магазин тратить 200-300 баксов.
По вашим словам судить, так у каждого айтишника все личные/домашние системы на рейдах, с бэкапами в облако, резервированием интернет канала и бесперебойником зацепленном на генератор. Может такое и имеет место быть но явно не в моей реальности.Goodkat
31.10.2019 12:22И сильно сомневаюсь что на каждый вылетевший сектор побежит в магазин тратить 200-300 баксов.
Первый вылетевший сектор означает, что вслед за ним в любой момент времени вылетит второй, третий, и т.д., а значит этим диском лучше не пользоваться, так как на восстановление данных придётся потратить намного больше времени, чем стоит новый диск.
По вашим словам судить, так у каждого айтишника все личные/домашние системы на рейдах, с бэкапами в облако, резервированием интернет канала и бесперебойником зацепленном на генератор. Может такое и имеет место быть но явно не в моей реальности.
Странные у вас суждения, однако.JPEGEC
01.11.2019 04:52а значит этим диском лучше не пользоваться, так как на восстановление данных придётся потратить намного больше времени, чем стоит новый диск
Почему нет? Ну потеряются, и черт с ними. Перекачают заново свои торенты например. Или вышеупомянутый докер переразвернут, или виртуалку накатят заново. Это как бы не повод тратить 200 баксов на новый диск, это не продакшен.
Ради любопытства посмотрите какое количество бу памяти и дисков скупается на али. И люди довольны и счастливы. Реальность она такая вот.
Alexsey
01.11.2019 21:09Все очень сильно зависит от количества секторов.
На моей практике еще не было случаев когда 100+ битых секторов лавинообразно не убили бы за собой весь диск за считанные часы или дни.
А вот пара дисков с 2-3 секторами, вылетившими через месяц после покупки, уже лет 6 живут в домашнем компе.
nikitych
30.10.2019 19:21+6А вы знаете что Docker поддерживает btrfs для своего хранилища? Эту опцию нужно включать.
Лучше не надо. btrfs graphdriver в Docker кривоват и имеет несколько багов пара из которых фатальны. Особенно опасно реализованы квоты. Пару лет назад я пытался его запатчить но всё руки не доходят пропихнуть в апстрим.
Во общем сейчас связка OverlayFS поверх btrfs надёжнее.typ6o0jiehb
31.10.2019 05:38не знаю про какие квоты Вы, но сами квоты в btrfs использовать по факту нельзя.
когда я включил qouta (включил функцию — btrfs quota enable, но не выставил ограничений) на btrfs и использовал это для того чтобы смотреть размеры снапшотов (btrfs-du) — всё было красиво, но когда я попробовал удалить один снапшот — btrfs-cleaner сожрал всё память и дальше у меня было увлекательных несколько дней в поисках решений. Баг до сих пор присутствуетinetstar Автор
31.10.2019 09:29Ссылка дана на баг-трекер Red Hat. А в баг-трекере Btrfs что говорят про это?
inetstar Автор
02.11.2019 23:23Обнаружил в Changelog Btrfs. Ядро 5.0. Март 2019 г.
«fix a crash due to a race when quotas are enabled during snapshot creation»
Похоже на баг, о котором вы говорили.typ6o0jiehb
03.11.2019 05:16Я в августе этого года это делал. Скачал archiso свежий на тот момент. И.е. ядро было 5.x (точнее не помню), и проблема продолжала наблюдаться. При монтировании fs, через примерно час 2гб ОЗУ заканчивались и все вставало колом. Я перезагружал, монтировал и наблюдал опять процесс btrfs-cleaner который бух по памяти. Потом узнал про квоты, выключил и как то помогло. Тоже не с первого раза получилось.
К сожалению всего алгоритма я не записал, но с проблемой бился несколько дней в свободные часы (домашний сервер на 6 разных дисках btrfs разделом на 14 Тб).
Т.е. я полагаю, что проблема не решена. Но это отдельный кейс, который по умолчанию выключен
slonopotamus
30.10.2019 19:29+2На мой взгляд, проблема CoW-FS отнюдь не в coreutils. А в том что надо учить весь софт, занимающийся в том или ином виде копированием файлов, вызывать новый syscall.
А ещё CoW — не серебряная пуля, и на части сценариев будет работать хуже/медленнее чем не-CoW.
MMik
30.10.2019 21:17+6В OS X подобная опция команды cp – это '-c'.
Она включает использование атомарного системного вызова clonefile(), который создаёт запись в файловой системе о новом файле, в котором ссылки на блоки данных идентичны оригиналу. Копируются атрибуты и расширенные атрибуты файла, записи списков контроля доступа (ACL), за исключением информации о владельце файла и со сбросом setuid/setgid битов. Работает в пределах одной файловой системы, требует поддержки файловой системой (атрибут ATTR_VOL_CAPABILITIES, флаг VOL_CAP_INT_CLONE).
Поддерживается начиная с OS X 10.12 (Sierra) и только в файловой системе APFS.
le1ic
30.10.2019 23:57+1По-моему проблема не в ФС и не в cp, а в том, что это мало кому нужно. Я не знаю, когда я последний раз создавал копии файлов на одном диске и при этом это было критично по времени.
inetstar Автор
31.10.2019 00:55+1При обновлении системы, установке пакетов такое происходит автоматически. Есть масса процессов, которые проходят невидимо для пользователя, но в которых эта оптимизация бы дала прирост скорости.
le1ic
31.10.2019 08:39Цифры в студию, как говорится. Покажите сколько времени занимает установка пакета, включая время на написание команды в терминале, скачивание его, апдейт локального репозитория, и сколько из этого времени тратится на копирование файлов.
У меня пакеты дольше скачиваются, чем устанавливаются (скорость i/o в 10 раз все-таки отличается). Обновления либо вообще в фоне автоматом, либо если вручную, то с перезагрузкой. Опять время установки по сравнению со временам скачивания и перезагрузкой пренебрежимо мало.
И вообще это примеры задач, некритичных по времени, и не являющимися основной работой компьютера.inetstar Автор
31.10.2019 09:36А вот на Gentoo пакеты собираются из исходников. Там собираются дольше, чем скачиваются.
В любом случае reflink быстрее и экономичнее в плане дискового пространства.
Насчёт цифр. Всё, где используется cp теряет в скорости минимум в 5 раз. Большинство процессов linux использует её, а не пишут свои велосипеды копирования.
MMik
31.10.2019 01:36+1Виртуалками не пользуетесь? Машинным обучением не занимаетесь? А там этот функционал нужен и полезен.
VolCh
31.10.2019 07:21А виртуалки тут каким боком?
inetstar Автор
31.10.2019 09:38Когда много виртуалок на основе одного и тоже дистрибутива или образа, то будет значительный выигрыш в плане дискового пространства.
MMik
31.10.2019 15:00Запуск виртуальных машин из образа (снимка, клона) или шаблона – это отличный вариант для использования CoW.
le1ic
31.10.2019 08:45Я матстатистикой и обработкой данных занимаюсь. Долгая по времени процедура не считая расчетов — это скачивание логов или данных из облака или с серверов. Локально многогигабайтные файлы клонировать как-то не нужно было, а все что меньше 100мб — вопрос одной секунды, дольше «cp» набирать. Да и даже этим я не пользуюсь, обычно мне файл нужен в единственном экземпляре.
Виртуалками — смешно, у меня вся среда на виртуалках — и разработка (linux в vitrualbox на маке) и в продакшене — k8s кластер на EC2. Копирование никогда не было проблемой, даже вопросов таких не возникало. Что вы такого делаете с виртуалками?
Alexsey
31.10.2019 00:02Раз уж зашел разговор про CoW — есть какие-нибудь примеры того насколько все плохо с фрагментированием и, соответственно, производительностью таких файловых систем на обычных HDD? Хотел перевести домашний сервер на zfs (в первую очередь из-за проверки целостности данных, хотел сунуть 2-3 зеркала в 1 zpool), но боюсь как бы не получить тормозное нечто в итоге.
inetstar Автор
31.10.2019 01:09Просадка будет на данных, которые часто перезаписываются: почтовые БД, просто база данных. Такая просадка, что терпеть её можно только на ССД.
Когда есть некие большие файлы, в которых перезаписываюся некие фрагменты.
А в остальном всё летает.
constb
31.10.2019 07:50+2на XFS тоже не всегда поддерживается CoW. нужно создавать файловую систему c mkfs.xfs -m reflink=1. уже на созданной ФС «включить» поддержку CoW нельзя. плюс, на ядрах до 4.11 включение этой опции вызывает красные варнинги в dmesg о том что фича – экспериментальная… в остальном работает. использую на свалке картинок нескольких сайтов (debian stretch), время от времени гоняю по ней duperemove…
Enchant
31.10.2019 10:18+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 все ОК — оно работает ровно так как и задумывалось.inetstar Автор
31.10.2019 11:19Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?
Reflink — это тот же снимок только более гибкий. На уровне файла.
2. восстановления целостности файла при сбое (по питанию)
А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.Enchant
31.10.2019 12:38> Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?
Ничего плохого, я лишь указываю, что это не основная цель этой технологии и что с основными целями COW в Linux отлично справляется. Главная задача COW быть небольших базовым кирпичиком который позволяет реализовывать в том числе и дедупликацию, но именно реализовывать там где это нужно (вот в docker например), а не предоставлять это по-умолчанию.
В docker, кстати, дедупликация реализуется вовсе не через cp с ключиком, а явно через снимки файловой системы (что супер быстро, в отличии от cp).
> А это вообще сомнительно. Это относится скорее не к CoW, а к любым журналируемым фс.
Верно. И я указываю на то, что COW позволяет сильно проще (насколько проще, что это прям оправдывает создание этой технологии только для этого) и надежнее реализовывать механизмы обеспечения целостности в ФС.
gmelikov
01.11.2019 09:26Речь не только о скорости. Но и о экономии дискового пространства, автоматической дедупликации. Чем плохо иметь эти плюшки?
Тем, что эти плюшки достаются не бесплатно, а какой-то ценой. По этой причине включать все возможности по умолчанию без обоснования — противопоказано.
inetstar Автор
01.11.2019 12:39В данном случае есть очень серьёзная цена и у неиспользования новых технологий.
Аргументы человека, который запретил использование reflink по умолчанию, разобраны в статье. И я нашёл их несостоятельными.
И не только я. Но и разработчики некоторых файловых менеджеров.gmelikov
01.11.2019 13:06Ну я вам про конкретные в комментарии вашем — дедупликация та же, она далеко не бесплатна.
Так же и с аргументами про reflink — вы сами соглашаетесь с первым его аргументом. И, касаемо reflink — это нарушение стандартного поведения, не без последствий. А их без веской причины вообще менять не любят.
Вы приводите аргументы за 1 конкретный юзерский сценарий «быстро копировать файлы». В то время, как другие сценарии могут быть сильно весомее. И тут я согласен по поводу того, что при смене поведения сильно пострадают сценарии, рассчитывающие на быструю работу с файлами после копирования.
Поймите меня правильно, я за reflink. Но не всё так однозначно. Да и CoW тут не при чём.inetstar Автор
01.11.2019 13:14Вы приводите аргументы за 1 конкретный юзерский сценарий «быстро копировать файлы».
Во-первых это не юзерский сценарий. Масса пакетов и программ делают это автоматически без ведома юзера.
А во-вторых в случае reflink дедупликация даётся бесплатно.
На мой взгляд reflink без CoW невозможен. В основе снимков лежит тот же механизм, что и у reflink.gmelikov
01.11.2019 14:02Во-первых это не юзерский сценарий. Масса пакетов и программ делают это автоматически без ведома юзера.
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-57201194inetstar Автор
01.11.2019 14:10А что такое DDT?
Я вот увидел следующую фразу:
The technique described cannot be applied to existing ZFS datasets
Ну так это не проблема. У XFS тоже нужно ФС заново воздавать, чтобы reflink заработали.
А вот то, что у ZFS reflink нет — это печально.
Насчёт нашлёпки на ext4. Из википедии:
Идея подхода copy-on-write заключается в том, что при чтении области данных используется общая копия, в случае изменения данных — создается новая копия.
Эта нашлёпка, если будет работать так, то это будет CoW.gmelikov
01.11.2019 14:21DDT в случае ZFS — это та самая таблица, которая хранит информацию о дедуплицированных данных (dedup table). Вот тут как раз и кроется проблема и dedup и возможного reflink — если хочется делать всё это онлайн, а не когда нибудь потом, то для записи (и изменения данных) вам придётся по всей этой таблице ходить (а вы хотите это сделать онлайн, иначе смысла в reflink при наличии штатной дедупликации нет). Т.е. держать её в памяти. Т.е. по грубым расчётам 20ГБ ОЗУ на 1ТБ диска. Иначе — привет запись 400КБ/сек и ниже.
Это пример из конкретной реализации ZFS и причины, почему дедупликацию в ней НЕ рекомендуют включать. Конечно стоит добавить, что именно эту ситуацию тоже пытаются улучшить github.com/zfsonlinux/zfs/issues/405#issuecomment-57201194, но в этой презентации явно показана стоимость дедупликации. Кратко — она всё равно не бесплатна.
А, ну и если вам очень хочется reflink в ZFS — просто включите дедупликацию :) Даже cp менять не придётся. Только включать дедупликацию я не рекомендую, если ваш коэффициент дедупликации меньше 20, см. требования к ОЗУ выше. Лучше онлайн lz4 компрессию использовать.
Если найдёте тесты на доступ к reflinked файлам, близкие к реальным кейсам — было бы интересно на них посмотреть, спасибо!
catharsis
01.11.2019 15:05LVM снапшоты тоже ведь copy-on-write, почему они дороже?
inetstar Автор
01.11.2019 15:23-1Там большой размер блока. Что-то около 4 мегабайта по умолчанию. Много места теряется при небольших изменениях.
Enchant
01.11.2019 15:35+1Там есть разница в подходе к записи данных. В случае записи в файл под LVM snapshot физическая запись выполняется в тоже самое физическое место (т.е. как будто это обычная запись) и одновременно с этим выполняется копирование предыдущего состояния данных в новое место.
Если проще — то во время записи создаётся бэкап старой записи и кладётся в отдельно место. Т.е. выполняется две операции записи, поэтому это медленнее.
Так сделано, потому что LVM snapshot универсальная прослойка для любой ФС, а сделать по другому без знания внутренностей ФС не получиться.
inetstar Автор
01.11.2019 15:22И это не так хотя бы потому, что в Linux всегда был способ копирования без физического копирования — hard link — работает на любой (почти) ФС и за долго до появления COW. Мы можете сделать тот же алиес для команды cp, чтобы использовать hard link.
Хардлинк — это всего-лишь алиас. Если изменить файл-копию, то изменится и оригинал.
Reflink, с точки зрения пользователя, — это полноценная копия, которая, пока её не изменили, не занимает места. Ну и скорость копирования феноменальная, конечно.
И всё-таки основная задача CoW — это экономия места. Из Википедии:
Идея подхода copy-on-write заключается в том, что при чтении области данных используется общая копия, в случае изменения данных — создается новая копия.
gmelikov
01.11.2019 15:47И всё-таки основная задача CoW — это экономия места. Из Википедии:
Вы вырвали из контекста как-то :) По умолчанию в CoW нет общих копий. Другой вопрос, что т.к. блок данных никогда не переписывается, позволяет его не удалять и использовать в других целях. Но это больше бонус, нежели цель.
И я вас расстрою — CoW всегда будет требовать больше пространства, чем классический подход. При заполнении более 90% любая CoW-like ФС начинает сильно деградировать по записи, т.к. свободное место дико фрагментировано и поиск свободного места нужного размера становится очень дорог. Да, это пытаются нивелировать всякими плюшками типа компрессии. Но это не основная цель CoW!inetstar Автор
01.11.2019 21:06А какая основная цель CoW?
В ядре Линукса CoW был придуман именно для экономии оперативной памяти для переменных процессов приfork().
По-моему — это исторически первая работающая реализация CoW.
RomanStrlcpy
01.11.2019 22:33В ядре COW больше для экономии места и скорости создания нового процесса. Для хранилищ я думаю COW это повышенная надежность в первую очередь.
gmelikov
02.11.2019 12:47А какая основная цель 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.
Увы, но это не так, см. выше.inetstar Автор
02.11.2019 14:29Вы так чётко утверждали:
Но это не основная цель CoW!
Как-будто знаете основную цель. Но назвать её так и не смогли.
В SunOS CoW, как я понял, был создан также для экономии памяти. Ускорение, на мой взгляд, тут неочевидно, так как механизмы CoW тоже потребояют процессорное время.
Насчёт дедупликации. Устранения дублирующей информации.
CoW по своей логике автоматически обеспечивает дедупликацию, так как хранит только различающиеся данные.
Просто в ZFS дедупликация сделана через DDT, а не через механизмы CoW. Это специфика реализации ZFS.
DrunkBear
31.10.2019 10:32Однако у Ханса Райзера поехала крыша и он убил жену, а его детище (скорее всего по политическим причинам) не включили в ядро.
Восхитительно. Несколько лет коту под хвост, потому что разработчик оказался плохим парнем? Опасались, что через код передастся сумасшествие или пользоваться такими фичами — неполиткорректно?acmnu
31.10.2019 11:23Он был ведущим разрабом там. Без него проект как-то сам заглох. Желающих продолжить в целом было не мало, но во-первых, на тот момент ещё не пришла эпоха ssd, а на hdd из-за фрагментации были проблемы с производительностью, а во-вторых, одно дело хотеть разрабатывать fs и совсем другое дело уметь это делать — людей, которые на профессиональном уровне занимаются fs в мире очень мало.
А про политические причины, это мнение автора. На самом деле на момент ареста код был не готов ко включению в ядро. Надо было привести код в соответствие стандартам Linux Kernel и это по факту никто так и не сделал, а потом стало поздно ибо внимание переключилось на btrfs/zfs и позже xfs, а потом интерес к теме упал: часть функционала r4 появилась в ext4, часть в btrfs/zfs.
mr_tron
Да в линуксе полно няшных свистелок, которые по-умолчанию выключены. Хочешь свистелок — будь добр пересобери ядро, пропатч исходники, поставь пакеты и напиши такие-то конфиги.
Сжатие памяти, снэпшоты фс, кэш hdd на ssd, CoW, апдейт ядра без перезапуска и тысячи подобных штук. Технологии есть — внедрения нет.
Yaris
IMHO, те, кому эти няшные свистелки действительно нужны, знают об их наличии и о том, как их включить (или способны найти способ их включить). Остальным либо не так уж и нужно, либо и вовсе опасно давать такое по умолчанию.
У нас народ про network namespaces узнал год назад, когда я предложил их использовать для поднятия нескольких идентичных копий сервиса на одной машине. Хотя в iproute они присутствуют уже давно, даже пересобирать ничего не надо. Вот так "надо" было.
Gordon01
Набоp кожи, механических насадок, вибpатоpов pазных pазмеpов, фиксатоpов потенции. В пpинципе всё это можно собpать в офигительный член. Hо те, комy нyжен член, этого сделать не могyт. А те, котоpые могyт из этого что-то собpать — не нyждаются в члене. ©
dimkrayan
имхо, дело только в целесообразности. Все это решается на уровне дистрибутива (да и практически все они кастомизируют ядро)
eumorozov
А где снэпшоты фс спрятаны? В btrfs они вроде нигде не спрятаны: бери да пользуйся.
Foror
>тысячи подобных штук
Огласите весь список, пожалуйста. Или хотя бы где посмотреть по частям?