Есть огромное количество файлов (нескольк десятков миилонов) размером 40-90 байт.
Программа которая с ними работает умеет работать только с файлами (тоесть их не запихнёшь в базу данных или архив).

Получается два неприятных момента:
1) огромная потеря пространства (кластер ведь 4кб), в файлы всего по несколько байт
2) очешь большое количество самих файлов (и винда начинает очень медленнл работать с ними)

Размер кластера конечно можно уменьшеить до 512, но и это не панацея, ведь файлы в 10 раз меньше кластера. Да и диск 4Тб с кластерами 512 байтов съест ещё больше пространства для таблицы размещения (за счёт десятикратного увеличения маленьких кластеров).

Если попытаться заархивировать этот объём, он пространства становится почти в 1000 раз больше. Это логично, потому что пока кластер в 100 раз больше самих файлов и потом ещё сама архивация (а файлы текстовые и одинаковой структуры). Но чтобы заархивировать такое количество - надо больше суток...

Может есть какие-то виртуальные хранилища (виртуальные диски) которые расчитаны именно на хранение большого количества мелких файлов? Или работающие с архивом как с диском? (пусть даже в ущерб скорости)

Basil A. SidorovФайлы размером до, примерно, полутора килобайт NTFS хранит прямо в каталожной записи.
Я первый раз такое слышу. Но если глянуть на параметры папки скажем из 8000 таких файлов, то видим:
Размер: 508 КБ (520 678 байт)
На диске: 34.0 МБ (35 753 984 байт)


Ну ведь наверняка есть какие-то виртуальные хранилища под такие задачи?
Уже даже подумывал о компрессирующихся ISO образах (но там только для чтения)

Dimitry SibiryakovInterSkyвинда начинает очень медленнл работать с ними
Какие именно операции с ними становятся медленными? Уж не вывод ли на экран полного списка?..

После появления такого количества файлов на компьютере считай что он стал недееспособным:
Антивирусу надо 52 часа чтобы проверить диск.
Заход в папку где около 10 тысячь файлов - занимает около 5 секунд.
Конечно когда у тебя есть путь до файла - то файл откроешь моментально, но ведь чтобы получить путь - программе надо открыть папку (хоть всё и так разнесено на папаки по несколько тысячь файлов)

k-nikeМожет подойдет сжатие папки?
Нет! Файл даже если и сожмётся - всё равно будет занимать по 1 кластеру на файл (ни одного байта не выигрыешь из-за сжатия).

Basil A. SidorovСпросите чекиста - он лучше разбирается, что чем занято.
Не совсем понял. Это ведь не про CHKDSK говорите?

Dimitry SibiryakovInterSkyФайл даже если и сожмётся - всё равно будет занимать по 1 кластеру на файл

Да щаззз же. Винда не дура, она объедки в один кластер свалит.

Я проверил перед тем как писать!
Нету выигрыша ни на 1 байт!
С какого перепуга она вдруг должна несколько файлов в один кластер сваливать? Просто компрессирует файлы, но хранятся они как прежде...

Basil A. Sidorov

Разница в свободном месте - менее девяти мегабайт, а вовсе не сорок.
Из этих "менее девяти" - два мегабайта на подросшие индексы.

Не совсем понял как получить такую интересную информацию?
У меня получилось только:

Basil A. SidorovНе как прежде - пространство под сжатые файлы выделяется посекторно.
Посекторно или покластерно? Сектор-то 512 байт, а кластер 4кб.
Но ещё раз повторюсь - я реально компресанул несколько папок - и не освободился ни один байт (если берёшь папки где файлы размером по 20-30кб - там сразу идёт увеличение свободного дискового пространства).

Basil A. SidorovP.S Другой пример:
"Ноль байт" заняли более ста мегабайт :)

По большому счёту тут нет ничего удивительного - ведь файл это не только РАЗМЕР, но и название, и атрибуты...
Я тут потестировал и получилось следующее:
Мои 8000 файлов размером 40-90 байт уменьшают свободное место на диске на 10290Кб, грубо говоря на 10Мб (проверял через CHKDSK).
Эти цифры практически совпали с тем эксперементом когда Basil A. Sidorov создал 10001 файл размером 1 байи (у него свободное место уменьшилось на 9Мб)
Напомню что Проводник говорил:
Размер: 508 КБ (520 678 байт)
На диске: 34.0 МБ (35 753 984 байт)

Хотя дальше я наткнулся на необъяснимую ситуацию: Я написал небольшой скрипт, который увеличил размер каждого файла в 2 раз (просто открывал файл и два раза копировал его в самого себя).
В результате мои 8000 стали весить не 508 КБ, а 0.99 МБ (так написал Проводник, ведь в одном Мб у нас 1024Кб)
Я ожидал что такая папку будет занимать не 10Мб, а на пол мегабайта больше (так как имя файла и атрибуты не изменились, а объём вырос на пол мегабайта. Однако чекдиск показал мне что дисковое пространство уменьшилось всего на 3928Кб (4Мб).
Я удивился и для чистоты экперемента даже форматнул диск. Но и повторная проверка (запускаю чекдиск, копирую, запускаю чекдиск) опять показала такие же цифры - 3928Кб. Почему увеличение файлов в 2 раза привело к УМЕНЬШЕНИЮ занимаемого пространства - я не полнял.

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

На самом деле я искал решение на подобии того о чём написал miksoft .

Процитирую свой первый поста (а то тема ушла в сторону от моего вопроса):
Может есть какие-то виртуальные хранилища (виртуальные диски) которые расчитаны именно на хранение большого количества мелких файлов? Или работающие с архивом как с диском? (пусть даже в ущерб скорости)

И ещё раз повторюсь - единственная пока идея которая у меня была в мыслях - это использовать сжаты образы.
Можно сделать образ диска в .ISO, а у UltraISO есть режим - "Опция сжать ISO". Полученный образ будет иметь расширение .ISZ.
Но я не смогу дописать файлы в такой фал :(

miksoftа почему вы не хотите использовать СУБД под эту задачу?
и экономия места будет, и всякие дополнительные плюшки появятся...
Как человек более 13 лет работающий с MySQL, я первым же делом перегнал все данные в базу данных. И если мне самому среди этих 10 миллионов надо найти какие-нибудь данные (по содержимому или по дате или по названию) - я ищу в базе данных...
Но программа-обработчик работает только с физическими файлами (это я говорил в первом посте).

GatorЭээ... Может быть, на внешнем диске?
С подобранными опытным путём ФС, кластером и прочее.

А если их объединять по к.-н. признаку (а-ля дата, клиент)
в один большой txt или bin файл "с разделителями-метаданными"?

Ну, приблуду написать, которая бы их склеивала по расписанию и выдавала on demand.

Очень не хотелось бы упираться в железо и брать отдельные диски только для хранения файлов. Думал что есть виртуальные контейнеры. Но народ здесь вроде как написал что под Windows есть тоже самое как под UNIX, но названия не прозвучало...

А если держать всё соединённом в файле (у меня сейчас паралельно в базе данных хранится) а потом в нужный для программы период это опять превращать в физические файлы - то будет уходить жутко много времени на самих дисковых операциях. Попробуй удалить 10 тысячь файлов - это пол минуты займёт, а объём-то всего в пол мегабайта.

Dimitry SibiryakovТы лучше процитируй в чём твоя проблема. В занимаемом месте или медленной работе?
А зачем цитировать второй раз? Я ведь говорил - проблема в занимаемом месте и медленном формировании списка файлов. Если заходим в архив, то список создаётся тысячекратно быстрей. Ну и тоже самое если скажем данные перекидываю на SSD (причём у меня ХР, по этому потоковая скорость чтения с SSD OCZ Vertex 3 составляет всего 35Мб/с, но за счётс нулевой скорости доступа - просто летаю), следовательно и если данные хранились бы в каком-нибудь контейнере - скорость тоже была многократно выше.

К сожалению пока единственный толковым предложением из всей ветки было про WM c линусом...
Но не ужели ничего подобного под винду нету?

Ну нету желания ради этого отдельный диск (тем более SSD) покупать.
Всякими драйверами типа STACKER ещё в 1993-ем году пользовался, которые под DOS'ом виртуальный диск с компрессией из файла делали. Не ужели за 20 лет не продвинулась тема?

А по поводу собственного файла контейнера - это конечно оптимальнейший способ с точки зрения экономи пространства, но ещё раз повторю - превращать блоки информации в файлы, это гиблое дело по времени (даже без учёта того что под это придётся софт писать). Просто зайди у себя в папку c:\document and settings\user\cookies и посмотри сколько она открывается (а у тебя там и 10 тысячь файлов нету), а потом попробуй её стереть... А теперь представь что из 10 миллионов...

Расскажу вначале что нового у меня за эти сутки (думаю будет очень интересно тем кто собирается иметь много мелких файлов).

Начну с того что в поисках контейнеров я наткнулся на ImDisk Virtual Disk Driver .
Программа бесплатная и занимает 300кб, по этому решил попробывать.
Стало гораздо легче контролировать занимаемые размеры...
Напомню что тестирую на одном каталоге в котором 8000 текстовых файлов размером 40-90 байт. Сам каталог занимает 508кб, при этом виндоус говорит что физически на диске занимает 34Мб, однако как вчера выяснилось - физически занимает чуть больше 10Мб.

Теперь просто расскажу тезисно что меня удивило в ходе тестов:

1) Изначально создал контейнер размером 5Мб - в него вместилось 1900 файлов.
Увеличил контейнер до 10Мб - в него поместилось более 6000 файлов.
Тоесть не пропорционально.
Всё влезло только в контейнер размером 13Мб (именно с ним дальше и проводились все экперементы)
При этом практически никакой разницы от размера кластера: 512 или 4096 байт
Если кластер 512 байт - то после заполнения остаётся 268кб свободного места.
Если кластер 4096 байт - то после заполнения остаётся 280кб свободного места.
Значит прав Basil A. Sidorov , говоря что Файлы размером до, примерно, полутора килобайт NTFS хранит прямо в каталожной записи.

2) Вчера на предложение пользователя k-nike поставить в виндоусе галочку "Сжимать данные" я говорил что это ни как не влияет (свободное место не увеличилось ни на байт). Хотя пользователь Dimitry Sibiryakov говорил что Винда не дура, она объедки в один кластер свалит.
На самом деле оказалось НАОБОРОТ!
Если ставить галочку на существующий каталог - то действительно изменений нет (очевидно виндоус просто видит что лучше не будет и не трогает файлы)
Но ситуация меняется если я вначале создам каталог, поставлю ему галочку "Сжимать данные" и потом начну копировать туда файлы (или сразу при формате скажу что этот диск со сжимаемыми данными).
Вы думаете будет больше свободного места? Нет! Всё наоборот.
В контейнер размером 13Мб влезает всего 1300 файлов (если размер кластера 512 байт).
В контейнер размером 13Мб влезает всего 180 файлов (если размер кластера 4096 байт).
После этого Total Commander говорит что диск переполнен.
Однако если мы после этого будем нажимать на кнопку "Обновить", то увидим, что свободное место на диске в течении 5 секунд будет увеличиваться и с нуля байт поднимется до 9Мб, после чего можно опять дописывать файл (он опять скажет что место кончилось, потом ждём 5-7 секунд и дописываем файлы).
Предпологаю что когда идёт копировани в область где данные должны сжиматься - виндоус налету пытается сжимать файлы что связано с выделением под это дело дополнительных объёмов или дописывания специальных шапок. Но после того как копирование прекратилось, у виндоуса появляется возможноть работы над ошибками, он проверяет что записал и понимает что там небыло смысла сжимать и возвращает файлы к первоначальной форме или освобождает зарезервированное пространство (удивительно что ему на это надо более 5 секунд).

3) Если на диск 13Мб записать 8000 файлов и удалить их, то на диске останется только 3Мб свободного места! (в не зависимости от размера кластера). Туда можно будет опять записать эти 8000 файлов (поскольку они занимают всего 508кб) но записать файл размером 4Мб туда уже не выйдет (тотал коммандер скажет что нет свободного места).
Я попробывал сделать полное заполнение свободного места через разбиение на части (которое есть в тотал коммандере) и оно создало только 2 файла - один на 3Мб, второй 0 байт. Удаляешь их, и видим что диск пустой, свободно 3Мб из 13Мб.
Если зайти на диск через Auslogics Disk Defrag Professional, то видишь что там есть:
$MFT - 8Mb
$MFT::BITMAP - 1Kb
$LogFile - 2Мб

3)

miksoftInterSkyВсякими драйверами типа STACKER ещё в 1993-ем году пользовался, которые под DOS'ом виртуальный диск с компрессией из файла делали. Не ужели за 20 лет не продвинулась тема?Сейчас жив близкий класс ПО - шифрованные диски (TrueCrypt и прочие).
Возможно, что-нибудь из них вам подойдет.
В этом плане мой ImDisk (Virtual Disk Driver) оказался гораздо лучше, потому что он ничего не шифрует и если взглянуть на соедержимое самого контейнера, то он состоит из пустот и текста, тоесть сам контейнер можно по крайней мере сжать как средствами виндоуса (и тогда он "На диске" занимает 3Мб вместо 13Мб), так и заархивировать при переносе и тогда он занимает вообще около 1Мб. Тоесть это уже прогресс в плане занимаемого места.
В то время как контейнер шифрованного диска уже не сжать...

Но просто домумал - Если фриварные контейнеры занимают 300кб, неужели никто за столько лет не повторил аналог STACKER?

Vladimir BaskakovавторНо программа-обработчик работает только с физическими файлами (это я говорил в первом посте).
всеми сразу? может ей пакет ссыпать из базы, обработать и назад всосать? это раз.
Сколько стоит ее замена. Что такого суперуникального она делает?Если это все распарсено и лежит грудой в удобной базе?

и

Guest_otorvaInterSky, а как именно программа работает с файлами? Если имя файла передается ей в качестве параметра в командной строке, то несложно написать оболочку, которая будет извлекать данные из СУБД, формировать файл и подсовывать вашей программе. Если программа открывает файл через GUI, можно опять-таки извлекать из СУБД необходимый набор файлов и подсовывать его программе. Аналогичные действия можно выполнять при создании таких файлов, т.е. после создания файла программой с помощью оболочки записывать его в СУБД.

Ребята, ну я же уже 3 раза писал об этом выше... Создание/удаление файлов дико тяжолая операция с точки зрения операционной системы. Жутко не выгодно создавать ту область файлов которая нужна программе. Я вначале должен придумать что программа запросит, создать это, а потом войти и запросить в ней тоже самое. А из результатов хочу перейти в анализ по одному параметру, и опять заходишь в свою программу и делаешь чтобы программа несколько минут создавала файлы нужные файлы.
Это не говоря о том что тогда надо изучить какие файлы использует программа для анализа, какие для контроля целостности информации...

Да - Можно купить новый SSD под каждую машину где стоит такая программа...
Да - Можно нанаять программистов которые изучат как работает программа и создадут аналог который работает с MySQL.
А можно просто найти сжимающиеся контейнеры (если они есть под линуксом, то и под виндой должны быть), просто я понимаю из тех кто принял участие в дискуссии никто с такими не работал (хотя я упомянул о STACKER под MS DOS, и о .ISZ от UltraISO)

Мишган-кабанчикА чем, автора не устраивает vhd-диск положенный на ntfs-том с сжатием?
2008, Win7 такое умеют - гугл знает.
О, похоже я уже реализовал и описал выше твою идею, взяв ImDisk Virtual Disk Driver и указав виндоусу что контейнер должен сжиматься. Хотя почитав в википедии про vhd-диск я не встретил упоминание о ImDisk (которая работает и на ХР).