Вопрос для програмистов.

Это значит сделать всё через ...хотя здравые мысли есть.

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

Про get - очевидно запросом типа http://мойлюбимыйсервер/?pos=0x0666&len=0x010

P.S: Статью по ссылке не читал - хватило описания в вопросе. Я-бы так не делал =)

>ЧТО БУДЕТ ЕСЛИ ХРАНИТЬ ФАЙЛЫ МЕНЬШЕ 1KB НА EXT3?
ОНИ БУДУТ ТАМ ХРАНИТЬСЯ НЕЭФФЕКТИВНО. НО ОБЫЧНО ЭТО ВСЕМ ПОХРЕНУ.

>ЧТО ОЗНАЧАЕТ"задавая в get параметре смещение и длину самого файла в hex виде"?
Значит, что нужно указать, с какого места в твоем большом файле начинается твой маленький, и сколько он занимает. Т. е. просто скачивать часть большого.

А что мешает монтировать файловую систему, хранящуюся в файле? Например, SquashFS

Тебе заняться нечем?
На реальную работу пойти не пробовал? :)

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

Казалось бы, что мешает просто создать где-нибудь ещё одну файловую систему с опциями, более подходящими для большого количества небольших файлов (размер блока, лимит на иноды и т. д.) и смонтировать её в нужное место?
Чукча, как говорится, не читатель...

Ничего страшного не будет. Специально для этих целей в ext4 есть опция: -T news
Можно ещё иноды сделать побольше и чексуммы включить, если так боишься, будет вообще непробиваемая система:
mkfs.ext4 -b 4096 -I 512 -T news -O metadata_csum,64bit

Вообще, ext4 многие недооценивают. На самом деле ext4+LVM - можно творить такие вещи! Любой Райзер за пояс заткнёшь!

Не нужно никаких серверов. Для тех целей, что были у автора, давно придумали LVM:
https://ru.wikipedia.org/wiki/LVM

В статье по ссылке, про многопоточный сервер на ассемблере... Но это лукавство. На самом деле автор не использует потоки, а юзает fork(), как в классических примерах на Си. Ну что сказать, перевести man по Си на ассемблер - тоже труд. Из всего многообразия протокола HTTP 1.1 поддерживается только метод GET...

ext3/4, ntfs 1/2, exFat/ Fat32 именно так и поступают с файлами которые меньше одного сектора размеченного диска. Обычно файл разбивается на части и эти части размещаются по разным секторам диска. Оставшиеся части сваливаются в сектор который специально хранит собственную размету со смещениями для разных файлов.

Раньше при работе с файлами при уменьшении увеличении размеров файлов сектора диска соответственно освобождались и занимались что со временем сильно замедляло работу с ними.
Файловую систему было необходимо дефрагментировать что бы перемещать сектора последовательно в порядке чтения и записи что сильно ускоряло работу файловой системы.

Софременные файловые системы в частности ext3 умеют незаметно для пользователя оптимизировать размещение файлов этим занимается драйвер по математически выверенным алгоритмам. Но у файловых систем есть рамки которым они должны соответствовать по этому возможно делать решения более оптимальные в определенных условиях.

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

Не нужно думать и гадать что и как будет лучше.
Нужно проводить тестирование и замеры в условия максимально приближенных к боевым =).

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