1

Я сканирую большой веб-сайт (более 200 тыс. Страниц) с помощью wget (есть ли лучший инструмент, кстати?). Wget сохраняет все файлы в один каталог.

Раздел HFS (я думаю), это вызовет проблемы, если у меня есть все файлы в одном каталоге? Предполагая, что я получу доступ ко всем из них только из консоли (я знаю, что в Finder есть проблемы с файлами dirs> 5k).

Или, возможно, есть способ создать микрораздел, который будет сжат и позволил бы быстрый и оптимизированный доступ к этому количеству файлов?

2 ответа2

1

Несмотря на осуществимость базовой файловой системы, вы ДЕЙСТВИТЕЛЬНО не должны хранить столько файлов в одном каталоге. Когда придет время просмотреть содержимое этого каталога, вы быстро обнаружите, что существует ОГРОМНАЯ задержка, в то время как ОС пытается создать список файлов и тому подобное. Это действительно создает значительную нагрузку на систему.

Большинство инструментов, которые выполняют любые виды «веб-архивирования», обычно создают структуру каталогов, аналогичную разметке сайта. Почти все веб-сайты не основывают все свое содержимое вне корневого каталога ... т.е. mydomain.com/document-1 ... они будут иметь некоторую материально-техническую базу, разделяющую его на несколько путей (по разным причинам) то есть изображения идут в mydomain.com/images и все о золотой рыбке в mydomain.com/goldfish/ и т.д ...

Существует несколько инструментов, которые могут и создадут такую структуру каталогов для вас. даже у wget есть опции для загрузки всего сайта. Лично я использовал « httrack » в прошлом, и он работал довольно хорошо. Есть также опции командной строки для загрузки всего сайта. Посмотрите на параметр -r (рекурсивный). Просто убедитесь, что вы настроили свой список доменов, чтобы не загружать ссылки бесконечно на нескольких сайтах. Лучше всего почитать на странице руководства wget.

-1

Википедия утверждает, что HFS имеет ограничение на размер файла 65535. Так что если ваш раздел действительно HFS, вы попадете на это.


Из Википедии:

Кроме того, ограничение в 65 535 блоков размещения привело к тому, что файлы имели "минимальный" размер, эквивалентный 1/65 535-му размеру диска.Таким образом, любой данный том, независимо от его размера, может хранить не более 65 535 файлов. Более того, любому файлу будет выделено больше места, чем ему нужно, вплоть до размера блока выделения. Когда диски были маленькими, это не имело большого значения, потому что размер отдельного блока выделения был тривиальным, но когда диски начали приближаться к отметке 1 ГБ, наименьший объем пространства, которое мог занимать любой файл (один блок выделения), стал чрезмерно большим , тратить значительное количество дискового пространства. Например, на диске размером 1 ГБ размер блока выделения в HFS составляет 16 КБ, поэтому даже файл размером 1 байт займет 16 КБ дискового пространства. Эта ситуация была меньшей проблемой для пользователей, имеющих большие файлы (такие как изображения, базы данных или аудио), потому что эти большие файлы тратили меньше места в процентах от их размера. С другой стороны, пользователи с большим количеством маленьких файлов могут потерять много места из-за большого размера блока выделения. Это делало разбиение дисков на меньшие логические тома очень привлекательным для пользователей Mac, поскольку небольшие документы, хранящиеся на меньшем томе, занимали бы гораздо меньше места, чем если бы они находились на большом разделе. Та же проблема существовала в файловой системе FAT16.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .