LINUX.ORG.RU

Ответ на: комментарий от t184256

Там хардлинками не обойдешься, не войдет.

То есть ты хочешь сказать, что там есть файлы, которые совпадают частично? Учитывая, что пакеты в репозиториях в подавляющем большинстве случаев сжатые, что-то не сходится.

Повторный проход блочного дедупликатора.

А ты точно понял, о какой ситуации я говорил в первом комментарии треда?

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Black_Shadow

Онлайн дедупликация слишком много памяти хочет. Имхо оффлайн подход (да ещё и инкрементальный) как в сабже - это самый правильный подход.

slovazap ★★★★★ ()
Ответ на: комментарий от greenman

сжатие и на F2FS есть

В код мне вникать лень, но судя информации в интернете и моим экспериментам, сжатие файлов в F2FS не освобождает место. При записи гигабайта нулей на ФС с включенным сжатием свободного места станет на гигабайт меньше, как и при записи на ФС без сжатия. Реально на накопитель запишется намного меньше, ведь нули хорошо сжимаются. Только вот пользователю от этого видимой пользы нет.

Проще считать, что в F2FS сжатия нет.

i-rinat ★★★★★ ()
Ответ на: комментарий от intelfx

То есть ты хочешь сказать, что там есть файлы, которые совпадают частично? Учитывая, что пакеты в репозиториях в подавляющем большинстве случаев сжатые, что-то не сходится.

Я сам удивлён, но точно говорю, что между rpm-ками даже разных мажорных версий RHELа есть что подедуплицировать, большими многомегабайтными кусками.

А ты точно понял, о какой ситуации я говорил в первом комментарии треда?

Да вроде да, неэкономное рванье экстента при записи в середину. Неприятно, но жить можно, если дедуплицируешь и сам, а не только снапшотами балуешься. И тут как раз въезжает сабж на белом коне.

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

Да вроде да, неэкономное рванье экстента при записи в середину. Неприятно, но жить можно, если дедуплицируешь и сам

Ну ок, понял правильно. А дедупликация-то тут при чём? Дедуплицировать нечего, ситуация возникает, даже когда есть ровно один файл, просто его «плотность» меньше единицы.

И тут как раз въезжает сабж на белом коне.

Тут нужен «анти-дедупликатор», который ищет не полностью зареференсенные экстенты, копирует их по кускам в новые экстенты и через FIDEDUPERANGE атомарно заменяет одно на другое.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Не, неправильно понял все-таки.

Если у тебя CoW незадействован и больше нигде первый экстент не использовался, то теперь, получается, ты хочешь autodefrag? Или опять я не догоняю?

t184256 ★★★★★ ()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256
  1. write(foo, 0, "AAAAAA", 6)
extent1: AAAAAA
foo:     AAAAAA (foo=extent1[0:6])
  1. write(foo, 2, "BB", 2)
extent1: AAAAAA
extent2:   BB  
foo:     AABBAA (foo=extent1[0:2] + extent2[0:2] + extent1[4:6])
  1. magic_extent_split(foo)
extent1: AA
extent2:   BB
extent3:     AA
foo:     AABBAA (foo=extent1[0:2] + extent2[0:2] + extent3[0:2])

Сейчас в btrfs происходит (1) и (2). Было бы неплохо после (2) делать (3).

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)

bees is a block-oriented userspace deduplication agent designed for large btrfs filesystems

Их (утилит-дедупликаторов) уже штук пять написали, поэтому не особо это и новость. Есть дефрагментатор, который умеет и btrfs, и xfs.

ttnl ★★★★★ ()
Ответ на: комментарий от intelfx

Снапшоты в btrfs и так дедуплицированы по определению.

При создании снапшота, модифицируются только метаданные. Данные остаются на своих местах на диске. Автоматическая дедупликация данных при создании снапшота – это был бы идиотизм, и такой снапшот создавался бы часами, а то и днями.

Наоборот, при необходимости имеет смысл вручную запускать дедупликацию данных перед созданием снапшота.

Их не нужно дедуплицировать отдельным демоном.

Не «не нужно», а невозможно. По крайней мере так было несколько лет назад. Снапшот в RO, двигать его экстенты нельзя.

ttnl ★★★★★ ()
Ответ на: комментарий от anonymous-angler

А почему она не имеет смысла в случае с кучей похожих виртуалок/контейнеров, например?

Конечно она имеет смысл, и люди активно используют эту возможность. Ну, например, у Red Hat даже специальный out-of-tree драйвер VDO для этого есть (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/vdo-integration)

ttnl ★★★★★ ()
Ответ на: комментарий от intelfx

1.write(foo, 0, «AAAAAA», 6) 2.write(foo, 2, «BB», 2)

Чо? Реально думаешь, что btrfs создает новый экстент при перезаписи существующего?

ttnl ★★★★★ ()
Ответ на: комментарий от intelfx

Было бы неплохо после (2) делать (3).

И как это сделать на CoW? Extent1 может использоваться другим файлом, в том числе и в каком-то снимке. Теоретически можно хранить в экстенте список всех мест, где он используется, чтобы потом можно было везде обновлять. Но тогда запись в файл превратится в неимоверную жесть с лавиной обновления метаданных.

i-rinat ★★★★★ ()
Ответ на: комментарий от ttnl

btrfs создает новый экстент при перезаписи существующего?

Да. И проверить легко. Создай ФС на гигабайт, запиши 100 мегабайт данных. У меня на весь файл получился один экстент. Потом записывай куски по 50 мегабайт в этот же файл, со смещением в 25, 24, 23 и так далее. После каждой записи делай sync. Через некоторое время место на ФС кончится, хотя там всего один файл на сто мегабайт.

Делаешь btrfs fi defrag /path/to/file, и свободное место снова доступно.

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

Эээ… ну ты ведь в курсе, что extent backreferences уже есть?

Без них было бы очень сложно, например, делать balance или ресайз вниз.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от ttnl

При создании снапшота, модифицируются только метаданные. Данные остаются на своих местах на диске. Автоматическая дедупликация данных при создании снапшота – это был бы идиотизм, и такой снапшот создавался бы часами, а то и днями.

И зачем ты мне это рассказываешь? Думаешь, я не знаю?

Не «не нужно», а невозможно. По крайней мере так было несколько лет назад. Снапшот в RO, двигать его экстенты нельзя.

Вылезай из танка. Какие-то ограниченные манипуляции (собственно, BTRFS_IOC_FILE_EXTENT_SAME) над файлами в снапшоте вполне возможны, даже если он RO.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Делаешь btrfs fi defrag /path/to/file, и свободное место снова доступно.

мдаа, в проде на несколько Тб не дело fi defrag запускать. тем более, часто

darkenshvein ★★★★★ ()
Ответ на: комментарий от i-rinat

Создай ФС на гигабайт, запиши 100 мегабайт данных.

У меня nodatacow маунт опция стоит, она это поведение отменяет. На голой btrfs и вправду такое происходит, но размер используемых данных не растет, и место не заканчивается.


#!/bin/bash
rm file.img
truncate -s 1G file.img
losetup /dev/loop0 file.img || exit 0
mkfs.btrfs /dev/loop0 || exit 0
mkdir mnt || exit 0
mount /dev/loop0 mnt
dd if=/dev/urandom of=mnt/test.file bs=1M count=100 oflag=direct
sync
filefrag -e mnt/test.file
ls -s file.img

for seek in {0..50}; do
	dd if=/dev/urandom of=mnt/test.file bs=1M count=50 seek=$seek \
		oflag=direct conv=nocreat,notrunc
	sync
	filefrag -e mnt/test.file
	ls -s file.img
	df -h mnt
done

dd if=/dev/urandom of=mnt/file2.img bs=1M count=800
sync

umount mnt
losetup -d /dev/loop0
rmdir mnt
ttnl ★★★★★ ()
Последнее исправление: ttnl (всего исправлений: 1)
Ответ на: комментарий от intelfx

О как. Ау. Это ж как должно быть плохо образцам VM без nodatacow.

rebalance + дедупликация должны помочь, но привнести свои минусы.

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

О как. Ау. Это ж как должно быть плохо образцам VM без nodatacow.

Всё так.

# compsize /mnt/vm/libvirt/images/windows.img
Processed 1 file, 945431 regular extents (1098755 refs), 0 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL      100%      864G         864G         791G
none       100%      864G         864G         791G

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

rebalance + дедупликация должны помочь

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

Тут нужна «дедупликация наоборот», ну или «дефраг наоборот». Т. е. нужна тулза, которая пробежится по диску, построит карту экстентов, найдёт среди них все не полностью зареференсенные экстенты, скопирует их по кускам в отдельные экстенты и потом сделает в эти куски EXTENT_SAME (после чего основной экстент останется без ссылок и будет целиком освобождён).

Ну или запилить истинный extent splitting прямо в драйвере, но это якобы настолько сложная проблема, что к ней никто даже не собирается притрагиваться.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 5)
Ответ на: комментарий от intelfx

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

А rebalance… Блин, а если не rebalance, как тогда звалась операция, которая имитировала практически что запись каждого файла заново? Она ещё все раздедуплицировала вхламину.

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

Наверное, ты имеешь в виду дефраг. Это почти то что нужно, только обычный дефраг совершает много лишней работы и не гарантирует совершения правильной работы (если все интересующие нас куски экстента будут больше target extent size, то дефраг пробежит мимо них, а если выкрутить target extent size в 9000, то такой дефраг у тебя займёт 100 лет и очень много лишнего I/O).

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

ну ты ведь в курсе

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Яннп. Когда ты пишешь в файл, ты пишешь в один конкретный файл. Если ты пишешь поверх шаренного экстента, то он аншарится от твоего файла и создаётся новый экстент, т. о. количество обновлений ссылок всегда O(1). Операций, прямо модифицирующих шаренные экстенты, в общем-то и нет, потому что они нарушают семантику copy-on-write.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

он аншарится от твоего файла и создаётся новый экстент

Он целиком копируется в новое место или одни и те же байты могут принадлежать сразу нескольким разным экстентам?

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Экстент — это непрерывная последовательность байт на диске, т. е. самая низкоуровневая конструкция. В btrfs, насколько я понимаю, все экстенты immutable (nodatacow в расчёт не берём). Части одного экстента могут принадлежать разным файлам, и даже нескольким сразу (это и есть дедупликация, рефлинки и т. п.).

Под «он аншарится» я имел в виду, что новые байты пишутся в новый экстент (не пошаренный ни с какими другими файлами) и на них создаётся ровно одна ссылка из того файла, в который записали. А старая ссылка либо уничтожается, либо заменяется на некоторое количество (1 или 2) частичных ссылок.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

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

Но ведь это ровно то поведение, которое сейчас уже есть. Я думал, что ты пытаешься описать желаемое поведение.

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Существующее и желаемое поведение я описал здесь. А сейчас я просто отвечал на твой вопрос.

intelfx ★★★★★ ()
Ответ на: комментарий от i-rinat

А, я понял, что ты пытаешься сказать. Предположим, что у нас есть один большой экстент, на который ссылается N файлов. Потом мы по очереди вышибаем из каждого файла серединку. Дальше есть два варианта поведения:

  • либо мы втупую делаем extent splitting для каждого файла по отдельности (при этом оставляя оригинальный экстент нетронутым, т. к. на него всё ещё есть ссылки). Тогда мы теряем дедупликацию;
  • либо при первых N-1 операциях мы замечаем, что на серединку экстента всё ещё ссылаются какие-то файлы и от extent splitting нет пользы, а при N-й операции замечаем, что на серединку экстента больше никто не ссылается, в этот момент делаем extent splitting и тут нам нужно сразу обновить N файлов, чтобы они ссылались на новые экстенты.

Ну да. Всё так.

intelfx ★★★★★ ()
Ответ на: комментарий от i-rinat

Спасибо за разъяснение. Получается, это сжатие только для экономии ресурса?

Была у меня мысль через пол-года (как сжатие на F2FS будет в lts ядре) перейти на F2FS. Теперь, по крайней мере, не будет одной иллюзии.

И думается, как только перешедших на F2FS будет больше, неизбежны возгласы — «нас обманули».

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 1)
Ответ на: комментарий от greenman

Получается, это сжатие только для экономии ресурса?

Выходит, что так.

i-rinat ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)