LINUX.ORG.RU

Sparse Files


0

1

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

Задача: На обычном винте создать файл размером 500 TB, записать 100 MB в середину, а потом, попозже их оттуда считать. Эпизодически могут быть записаны и потом считаны блоки в самых разных местах этого файла. Но сумарый обьем задействованных данных вполне всегда влезает на винчестер, например всего 1 ГБ.

Но файл должен существовать и работать так, как будто он реально существует.

Пока-что накопал (пока гуглением, я в венде сейчас):

1. В Windows работает через бубен и только в NTFS. Нужно вручную указывать существующие и несуществующие блоки с помощью спец-функций WinAPI. Если не указывать, то ситуация следующая. Забавно что файл в полтора гига (переместиться в нужную позицию и записать байт) появляется моментально. Если «пошуршать» там - записать несколько блоков размером с метр в том месте, то первая запись длится у меня более 200 сек(!!!). Пока это создается, то почти 12309 в венде. Автоматический спарсинг - неюзабелен. Есть атрибут файла, который устанавливает спарсинг, но он ничего не делает. По крайней мере из .NET. Для того, чтобы работало нужна нехилая гимнастика с Interop и WinAPI

2. В Linux/FreeBSD файловый системы это поддерживают автоматически. lseek в нужное место и запись должно работать быстро и сохраняя место на диске. До конца дня не смогу протестировать, буду в венде. Например копирование таких файлов можно делать путем проверки каждого блока на «нулевость» и с пропуском фазы записи этого плока, просто перемещение дальше. Это поддерживает в специальном режиме cp (но не в FreeBSD).

3. MacOSX сливает, HFS+ не поддерживает такого совсем. А так как яблочники - тоже клиенты, то надо на этой системе таки писать свой велик.

Пока что велосипед преставляет собой файл с записанными блоками и базой SQLite рядом для учета что-куда. Это на несколько порядков работает быстрее чем обычная работа с файлом (подразумевающая автоматический спарсинг) в венде. Linux версии еще нет.

Вот решаем что делать.

★★★★★

Ну и да. «*nix - история успеха»

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

Представь торрент. Но размером в 100 ГБ. Тебе из него нужно 3 блока размером в 1 МБ каждый. Как будешь хранить? Скачать только их? Ок. А если еще понадобится?

vertexua ★★★★★ ()

Оказывается в венде для того чтобы это работало нужно выставить аттрибут - сжатый. Все начинает летать.

P.S. Очень весело становится когда ты создашь побольше таких файлов, потом уберешь галочку сжатый и нажмешь применить. Очень грустная история... А если это когда-то это сделает пользователь? Не с целью отстрелить себе мозг, а рекурсивно для всего диска, он просто не знает о этом требовании программы? )

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

Интерестное совпадение ) Но я узнал не оттуда, просто как раз решаю эту проблему и нагуглил

vertexua ★★★★★ ()

Веду ЖЖ для интересующихся дальше. Теперь остался вопрос: а как же все-таки знать когда по-факту прийдет Disk Full и уберечь от этого?

vertexua ★★★★★ ()

Месье знает толк в извращенном троллинге!

Mobyshvein ()
Ответ на: комментарий от vertexua

>а как же все-таки знать когда по-факту прийдет Disk Full и уберечь от этого?

Когда записываться перестанет?

proud_anon ★★★★★ ()

у меня есть подозрение, что то сейчас используете - лучшее решение. могу еще предложить запилить свою fs через fuse

antony986 ()

>На обычном винте создать файл размером 500 TB

Обычном? Для тебя будет неожиданностью... но таких винтов нет.

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

ни разу не видел юзеров которые бы с этим флагом игрались... Забей, короче.

Они есть, просто как следствие из закона подлости. Из того же закона следует, что как минимум один из таких пользователей окажется среди пользователей программы автора темы 8).

Deleted ()
Ответ на: комментарий от true_admin

>ни разу не видел юзеров которые бы с этим флагом игрались... Забей, короче.

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

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

Он же сказал: «разреженный» файл. Реально такой файл будет занимать всего лишь несколько сот мегабайт, пока в него что-нибудь не запишут.

Eddy_Em ☆☆☆☆☆ ()

А нельзя ли на виндах попробовать посмотреть, как с этим справляется, например, uTorrent? Он там ничего особенного не делает? Он обычные файлы создает или сжатые? Если сжатые, то как?

proud_anon ★★★★★ ()

>Задача: На обычном винте создать файл размером 500 TB, записать 100 MB в середину, а потом, попозже их оттуда считать

Если действительно задача поставлена именно в ТАКОМ виде, то сказать можно только одно: «Забористая у вас там трава».

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

pathfinder ★★★★ ()

да, что за велосипед такой, который потребовал сабж ?

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

Оказывается в венде для того чтобы это работало нужно выставить аттрибут - сжатый. Все начинает летать.

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

да, сжатие - вещь довольно опасная (сам пользовался), и юзать ее лучше только на своем домашнем компе, где ты можешь отследить, что где и как.

так что если есть возможность сделать как-то иначе (file+file.sqlite), то лучше сделать иначе :)

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

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

eth ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.