Открыл для себя такую штуку. Был очень рад, так как пилим подобный велосипед на работе в рамках одного проекта.
Задача: На обычном винте создать файл размером 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 версии еще нет.
Вот решаем что делать.
