дырявые файлы (sparse files)

[nicka_startcev]

любопытно, кто-нибудь с сабж работал

Comments

[stanislavvv]

Максимум, что видел - копирование с создаванием дырок (cp --sparse=always или rsync -S). На некоторых образах дисков весьма экономило место.

Распознать - разве что по размеру, занимаемому на диске (ls -s vs ls -l). При обычной работе через файловый дескриптор не определить, откуда нули - из дыры или из preread).

Если ошибаюсь - прошу сообщить.

[eddy_em]

Если уже использовал блоки, освободить их получится лишь на уровне модуля ФС в ядре. Потому как если создать файл как-то так: dd if=/dev/zero of=myfile count=1 seek=1T, то на диске он будет ровно один блок занимать. А вот как начнешь писать в него, ФС будет все больше и больше блоков выделять… Зато можно писать с середины и то "голову", то "хвост" модифицировать (в т.ч. увеличивая размер), покуда до указанного терабайта не дойдешь, тогда уж только в хвост дописывать.

[poor_sysadm]

в манах всё это есть
https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-fsctl_set_zero_data
только насколько я понимаю никто никто не гарантирует, что ос не решит этот регион офизичить, заняв всё доступное пространство
ну и если есть квоты на размер - она учитывается по номинальному размеру

ну и вообще говоря это велосипединг очереди

[nicka_startcev]

>это велосипединг очереди

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

[poor_sysadm]

а какой язык?
нагуглились либы для .net, js, python, java по такому запросу: local file based queue

[poor_sysadm]

сорян не то
FALLOC_FL_PUNCH_HOLE
https://www.man7.org/linux/man-pages/man2/fallocate.2.html

[poor_sysadm]

Вопрос лишь в том, насколько эффективно ОС будет сохранять информацию о том, что первые сто тыщ терабайт файла - пустышка.

[nicka_startcev]

дык об этом-то и вопрос.

[eddy_em]

Покуда в соответствующий блок не будет вестись запись, место для него на диске выделяться не будет. Проверено.

[self_perfection]

Единственное что меня в такой конструкции настораживает, не будет ли в файловой системе копиться множество записей вида "с x1 по x2 дырка" "с x2 по x3 дырка" и так на каждый "прокол". Это будет занимать потенциально много места и тормозить при поиске с какого места нужно читать. В теории можно их сливать, но будет ли это в реальности - вопрос.

Без натурного эксперимента не понять.

Советую тестировать именно ту ФС и примерно с тем ядром, которые предполагается использовать в проде.