Мышиная возня в коробке из под обуви.
Последнее время я постоянно сталкиваюсь с одной проблемой, о которой я раньше никогда особенно не задумывался. А именно – манипуляции с большим количеством «временных» файлов. Я не случайно взял в кавычки слово «временных». Время жизни этих файлов – от нескольких дней до нескольких недель. Объем – сотни гигабайт, миллионы файлов. В принципе не очень-то и внушительный объем, учитывая размеры современных жестких дисков. Тем не менее уже на таких объемах возникают сложности.
Постараюсь описать в чем тут закавыка. Для проекта, над которым я работаю, заведена отдельная ветка исходников Windows. Из них периодически собирается вся система в 6-ти вариантах: free и checked версии для каждого из поддерживаемых процессоров: x86, x64 и ia64. В процессе сборки генерируется множество файлов: объектные файлы, бинарники, символы, вагон и маленькая тележка скриптов, конфигурационные файлы, готовый образ инсталляционного диска и т.д. и т.п. Многие из них уничтожаются сразу после завершения сборки, например объектные файлы. Остальные должны где-то храниться, пока данный билд тестируется и отлаживается.
Далее, «большие» ветки, которыми пользуются целые группы или несколько групп сразу, обычно обслуживаются целой батареей серверов в лаборатории. К ним приставляется инженеры, которые поддерживают ежедневный билд, решают проблемы с инфраструктурой и всячески облегчают жизнь разработчикам. Для небольших проектов, над которыми работает пара человек, все выглядит по-другому. Для них выделяется одна-две машины (довольно мощных и в кучей места на дисках), а все проблемы решаются самим разработчиками.
Так вот, проблема заключается в том, что когда количество файлов переваливает за полмиллиона, а их объем – за сотню гигабайт, выясняется что их копирование и удаление, изменение прав и атрибутов на всех файлах может легко потребовать нескольких часов. Учитывая, что в сутках только 8 рабочих часов, это начинает сильно мешать.
Сразу скажу, что при правильной организации процесса эти проблемы либо не возникают, либо их влияние можно свести к минимуму. Ну в самом деле, права на файлах можно выставить заранее на соответствующей директории и тогда они будут автоматически унаследованы создаваемыми файлами; при отлаженном процессе ежедневной сборки файлы не тасуются с диска на диск, чтобы освободить место; никто не таскает внешний диск от машины к машине.
Удаление.
Upd: как оказалось, про удаление я загнул. “Два часа” ниже нужно поделить на 20.
Как вы уже догадались, удаление сотен тысяч файлов может затянуться надолго. «Надолго» получается ещё дольше, если раздел расположен на паре IDE дисков, собранных в RAID0 и подключенных по FireWire. Зачем нужны внешние IDE диски, если есть возможность подключить внутренние SCSI? Затем, что возможность есть, а дисков – нет. :-) Их нужно заказывать, а это долго. А IDE диски - вот они, бери - не хочу. Кроме того, IDE дешевле, соответственно получается больше места.
Ускорить удаление помогает нехитрый трюк: “format x: /q”. Быстрое форматирование занимает пару минут, “rmdir /q /s” – пару часов. Естественно, чтобы это работало нужно заранее позаботится чтобы на форматируемый раздел попали только нужные файлы. Вернее ненужные. Другая сложность – при быстром форматировании теряется информация о испорченных кластерах. Опять же, почему не выбросить сбойный диск? Потому что этот диск – один из немногих SCSI дисков которые есть здесь и сейчас, билд тоже нужен здесь и сейчас, а заказать новый диск – смотри первый пункт. :-)
Копирование.
Файлы копируются ничуть не быстрее чем удаляются. Ускорить этот процесс практически никак нельзя. Всякие хитрости с многопоточным копированием может и дадут прирост в 10-20%, но это не путь настоящего джедая. Настоящий джедай воспользуется тем фактом, что диск-то внешний. Если очень невтерпеж и никак подождать до завтра не получается, то диск с нужными файлами можно перенести на ту машину, где они нужны. Более того, если копировать все-таки надо, то пропускная способность FireWire в 4 раза выше, чем 100Mb Ethernet.
Права, атрибуты файлов.
К сожалению не могу предложить ничего лучше, чем позаботится от этом заранее – выставить нужные права на каталоге, где будут создаваться файлы; позаботится о Indexing attribute. Если все же припёрло к стенке, то консольные утилиты справляются с такой работой лучше, чем Explorer. Для выставления нужных прав на файлах, например, я пользуюсь утилитой subinacl. Стандартная практика, когда на каждую комбинацию «тип доступа/ресурс» создается отдельная локальная группа, которые и указываются в ACL, тоже помогает минимизировать количество операций с файлами.
Cross-posted from blog.not-a-kernel-guy.com.
