Мышиная возня в коробке из под обуви.
Последнее время я постоянно сталкиваюсь с одной проблемой, о которой я раньше никогда особенно не задумывался. А именно – манипуляции с большим количеством «временных» файлов. Я не случайно взял в кавычки слово «временных». Время жизни этих файлов – от нескольких дней до нескольких недель. Объем – сотни гигабайт, миллионы файлов. В принципе не очень-то и внушительный объем, учитывая размеры современных жестких дисков. Тем не менее уже на таких объемах возникают сложности.
Постараюсь описать в чем тут закавыка. Для проекта, над которым я работаю, заведена отдельная ветка исходников 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, тоже помогает минимизировать количество операций с файлами.
Неужели вы сами не считаете, что тормознутость работы с файловой системой в Windows это то с чем, в конце концов, надо реально решить проблемы.
Вы сами можете настучать кому-то по голове в компании за этот ужас, или это такая внутренняя политика, не отнимать хлеб у изготовителей всяких супер оптимайзерских утилит?
Насколько мне известно, у NTFS с производительностью всё очень шоколадно. Вы можете привести другие данные? Я погуглил слегка, но Google меня сегодня не любит – не нашлось ни одного нормального сравнения, все в духе “у нас все классно, а конкуренты в ж.”:
Бенчмарк с сайта с сайта Microsoft (Windows бъёт всех и вся):
Держу пари, что ext3 по умолчанию использует 4KB блоки.
Бенчмарк с сайта с сайта Sun (Solaris рвет всех и вся):
Ну да, конечно. А быстрого форматирования не существует. И одна команда “format” гораздо сложнее чем две.
Хм… Пуст даже и так, но нафига для РедХата оставлять размер блока “по умолчанию”, а для для “наилюбимешего” виндаФс стервер “поднимать” ах до 64к? Несколько некорректно, не кажется ли? Ведь по умолчанию и в НТФС те же самые 4КБ блоки.
Не имеет значения, стало хуже или лучше для той же красной шапки, но такая подстава некорректна. Всё равно, что сравнивать мыло с триалоном.
Я об этом и написал. (смайлик пожимающий плечами).
PS: И, что характерно, обошелся без коверканья слов. Я уже говорил вам, что меня от этого коробит. Не надо этого больше делать.
Коробит в отношении к МС продуктам или не только?
P.S. Постараюсь сделать над собой это нечеловеческое усилие. Особенно сложно после прочтения “MinWin …для решения простейших задач операционная система может занимать очень мало памяти…”. Это 40 мегабай-то “очень мало памяти”? (я опустил http://www.securitylab.ru/news/305983.php, как полный бред: чего стоит только “MinWin занимает всего 25 Мбайт, в сравнении с Vista, которая занимает 4 Гб”:).
Припоминаю множество LiveFloppy (по аналогии с LiveCD), созданных еще годы назад и которые занимая место всего на одной дискете содержали и GUI и веэ-фтп- и прочие сервера.
P.S. Поиски только что привели к http://blogs.technet.com/austria/archive/2007/10/22/ausblick-auf-windows7-und-minwin.aspx. А там занятное нечто пишется про “MinWin soll auf einem sehr kleinen Kernel mit nur etwa 100 Dateien und 25MB Festplattenplatz basieren (im Vergleich: Windows Vista besteht aus etwa 5000 Dateien und 4GB core) und – natürlich ohne grafische Oberfläche – nur um die 33MB RAM verbrauchen.” Может переводчик всё таки прав?
Сделайте одолжение.
… и из этого следует вывод что…
Да собственно что может значить copy-past?
Тогда зачем copy-paste’ить? Я вполне серьезно спрашиваю – какой, по вашему мнению, можно сделать вывод из наличествующей информации? Мне так кажеться, что цифра 25MB также неинформативна, как и 250MB или 2.5MB. Вы же, по всей видимости, делаете какие-то выводы, судя по тому, что вы упоминаете LiveFloppy.
В Linux фоновая оптимизация файловой системы, это то, что само по себе есть и работает.
Когда я работаю под линукс я практически не слышу такого скрипа жесткого диска, какой мне постоянно приходится слышать под Windows, так как файловая подсистема прозрачно кешируется в оперативку.
Для того чтобы получить что-то подобное под Windows надо покупать у партнера Microsoft специальный драйвер http://www.superspeed.com/. Но эта система не контролирует и только увеличивает фрагментацию ФС, так что придется покупать ПО фоновой оптимизации.
Тем более под Linux мне не приходится иногда отходить в сторонку когда система вдруг без повода перестает реагировать, видимо от действий очередного маляра Шмиеля вдруг начинающего дрючить мой жесткий диск.
Антивирусник я бы и рад не использовать, но не могу себе этого позволить – т.к. сотни тысяч компьютеров подключенных к Интернет превращены в рассадники спама и заразы, не без помощи Internet Explorer и Outlook Express.
NTFS тут совсем ни при чем. Приведите набор служб/демонов на обеих машинах в соответствие, получите одинаковую нагрузку на диск. Отключите индексирование файлов, анимацию, thumbnails…
Рассмешили. И чем этот специальный драйвер поможет?
“маляра Шмиеля” – ? Если это человек, а не непонятный мне эмфемизм
, то зачем вы для него расшарили диск? Почему вы не сделали то же самое в Linux?
Чёрт, мне иногда даже жалко, что Open Source не доминирует. Как было бы здорово пнуть тот же Thunderbird за просто так, потому что так принято…
Про маляра:
http://www.joelonsoftware.com/articles/fog0000000319.html
No. This code uses the Shlemiel the painter’s algorithm. Who is Shlemiel? He’s the guy in this joke:
Shlemiel gets a job as a street painter, painting the dotted lines down the middle of the road. On the first day he takes a can of paint out to the road and finishes 300 yards of the road. “That’s pretty good!” says his boss, “you’re a fast worker!” and pays him a kopeck.
The next day Shlemiel only gets 150 yards done. “Well, that’s not nearly as good as yesterday, but you’re still a fast worker. 150 yards is respectable,” and pays him a kopeck.
The next day Shlemiel paints 30 yards of the road. “Only 30!” shouts his boss. “That’s unacceptable! On the first day you did ten times that much work! What’s going on?”
“I can’t help it,” says Shlemiel. “Every day I get farther and farther away from the paint can!”
ЗдОрово! Беру назад свои слова про расшаривание диска кому ни попадя.
“Руки прочь от NTFS!”, тем не менее. 
Не чертыхайтесь, а то получится Булгаковский пустой пиджак, подписывающий документы и отвечающий на телефонные звонки.
Ведь когда-то мс (вместе с OEM метками лицензий висты в BIOS) всё таки сдохнет и… мир спокойненько будет существовать дальше.
Да, ACL – это беда … Из explorer’а медленно и вешает всю оболочку надолго. С наследуемыми правами – единственый более-менее быстрый вариант.
А что это даст? В чем выйгрыш?
Не вижу особых проблем. Настолько массовые опреации с файлами медленны по своей природе. А каких-то известных проблем со скоростью у NTFS если мне не изменяет память нет.
С одной стороны да – сама Windows содержит только базовые инструменты, всё остальное отдано на откуп сторонним разработчикам. С другой стороны никаких супер оптимайзерских утилит не существует. Одних RAM-Cleaner’ов несть числа, но толку от них никакого, вы должны это знать, если вы хоть немножко в теме. Была хорошая статья на об этом, к сожалению сейчас не вспомню.
Indexing Service (Desktop Search и проч.) не будет пытаться индексировать содержимое файла при каждом изменении. Антивирус тоже надо задавить.
Весь вопрос в том, что считать базовыми инструментами. С инструментами, которые поставляются в коробке или доступны для скачивания можно сделать очень много. С другой стороны, чтоит что-то глобальное добавить в коробку – поднимается вой про монополизм.
А … Я грешным делом подумал, что Indexing Service надо включить. Поэтому и удивился, ибо я ее первым делом отключаю.
В рабочем окружении совсем задавить не получается, приходиться использовать довольно широкие списки исключений по типам файлов. Например тот же хелп Visual Studio.
Вполне согласен.
Да… Вспоминая историю с WMP и IE … Странные люди …
Черт, что-то я с тегами намудрил
…
P.S. Спасибо, что поправили мой предыдущий пост.
<blockquote>Цитата</blockquote>
В cite – указывается адрес цитируемой страницы, если есть.
фигня какая-то. домашний комп. server 2003. raid0 на двух sata самсунгах по 250 gb.
528232 file(s) and 36039 folder(s) — набрано из исходников и писем.
набиралось (копирование) — 16 минут.
установка атрибутов — 46 секунд.
установка пермишенов и владельца — 93 секунды.
удаление — 71 секунда.
ну скидка на фаерваре — множим на 3. это долго?
Про удаление я безбожно наврал.
Текст писался по памяти, специально я ничего не замерял. Только что попробовал: 502122 файлов в 141080 каталогах – около 6 минут. Долго, но даже близко не два часа. Разница выглядела весьма удручающе, пока я не вспомнил, что дело может быть в кешировании записи на диск. Для внешних дисков оно по умолчанию выключено и я помню, что в какой-то момент я специально лазил в настройки его включать.
Попробовал удаление с найсройками для диска по умолчанию (optimized for quick removal) – 15638 файлов в 281 каталогах – около 3 минут. Для 500K файлов это будет уже около 60-90 минут. Вполне вероятно, что память о долгом-долгом удалении у меня осталась с того времени. :-/ Зарубка себе на будущее – не доверять своим ощущениям и проверять о чем пишешь.
На всякий случай проверил копирование: около 4GB, более 14000 файлов в 208 каталогах – заняло около 16 минут. Получается около 4MB/sec. Совсем не густо. Гм.
Кстати, а вы не пробовали использовать для сборки ПО от этого производителя http://www.xoreax.com/main.htm? И если пробовали каковы ваши впечатления, на ваших масштабах?
Не пробовали. Мы не пользуемся проектами Visual Studio, только компилятором.
Добавлю мои 2c
.
Простое использование defrag НАМНОГО улучшает ситуацию. В разы. Я в этом году как раз над этом работал (3 месяца в Микрософте).
И скорость сильно зависит от количества файлов на директорию, и их размера. У perfteam и ntfsdevel есть подробные результаты, но, насколько я знаю, они не были опубликованы вне Microsoft.
В longhorn и vista sp1 скорость работы с большим количеством файлов будет намного лучше, как для больших директорий так и для файлов.
дефраг помагает только когда к диску обращается одна задача из одного потока. в любом другом случае — по барабану. всё равно все запросы к диску сортируются.
Не совсем так.. Директории ведь тоже фрагментированы, и все пробежки по MFT из одного конца в другой очень сильно замедляют систему.