June 26th, 2011

glider

Trace Windows 7 boot/shutdown/hibernate/standby/resume issues

Наткнулся на интересный пост с форума MSFN. Оказывается, в Windows SDK есть Windows Performance Toolkit, который позволяет запрофайлить процессы загрузки, шатдауна и саспенда/хибернейта.

Профайлинг происходит следующим образом:
1) Скачиваем тулкит (до семерки его можно скачать с сайта MS, для семерки он есть только на дисках с SDK).
2) Запускаем xbootmgr -trace <what> -traceFlags <flags> -resultPath <folder>.
3) После того, как профилируемый процесс завершится, в папке, указанной в resultPath, появится бинарный лог.
4) Специальной командой этот лог можно преобразовать в XML, который описывает высокоуровневые шаги процесса и их тайминг.
5) По результирующему XML можно проанализировать слабые места системы. В сабжевом посте достаточно детально объяснены этапы стартапа и шатдауна - может быть полезно для понимания происходящего.

Лично я, даже не вдаваясь в матан, смог разобраться почему так долго вырубается операционка. Дело было в том, что сервис TeamViewer выгружался больше пяти секунд. Винда даже успевала показать окошко "программа тормозит загрузку: выкосить или подождать еще?". Но, так как проблема была в сервисе, окошко было пустое, поэтому без профайлинга я бы ни в жизни не догадался.
glider

убунта, часть 4: интероп с виндой

часть 1: первый взгляд
часть 2: установка
часть 3: софт
часть 4: интероп с виндой
часть 5: обратно на винду

Главным вопросом для меня в плане интеропа была организация партишена, общего и для убунты, и для винды. Есть три вида файловых систем, которые хорошо поддерживаются на обеих платформах: FAT, NTFS и ext. Первый вариант отпадает сразу ибо он не журналируется, остаются два.

Вначале я решил использовать NTFS, тем более, что существующие данные уже лежали на виндовом партишене. Немного погуглил и выяснил, что драйвер ntfs-3g под убунту считается довольно стабильным. В файловом менеджере убунты мой NTFS-диск подмаунтился без всяких проблем, поэтому я решил не париться и оставить все как есть. В процессе тестовой эксплуатации выяснилось следующее:
1) Скорость работы с NTFS через убунту примерно в полтора раза хуже скорости через винду.
2) Если с помощью виндового партишен-менеджера делать динамические NTFS-партишены, то есть неплохой шанс, что ntfs-3g откажется их хавать. Возможно, у этой проблемы есть цивилизованные решения, но мне пришлось форматировать диск.

Так как для используемого каждый день хранилища данных эти проблемы уж слишком жестокие, было принято решение мигрировать на ext. На текущий момент есть два драйвера, которые дружат винду с ext: ext2fsd и ext2ifs. Первый достаточно оживленно разрабатывается (последний релиз был в феврале этого года), поэтому сразу поставил я именно его. Однако в процессе использования проявились неприятные моменты. Во-первых, параметры маунтинга ext-разделов не сохраняются между ребутами (автор так и написал в релиз нотах: "это не баг, просто не было времени прикрутить"). Во-вторых, дефолтный режим маунтинга - только на чтение, поэтому после каждой перезагрузки приходилось переподключать диск, что неприятно. В-третьих, даже в режиме r/w я ловил глюки с записью: например, в папках, созданных под убунтой я мог создавать новые файлы, но не мог редактировать старые.

В итоге, пришлось остановиться на ext2ifs. Почему пришлось? Да потому, что последний релиз этой софтины случился почти 3 года назад, и, кроме того, она не поддерживает ext4. Также выяснилось, что софтина не поддерживает размеры inode, большие, чем 128 байт. Юмор ситуации заключается в том, что по умолчанию убунта форматирует ext с ключом -I 256, а поменять размер айнода можно, только пересоздав файловую систему. Ладно, ок - заново забэкапил данные и отформатировал партишен под ext3 -I 128. После этого меня ждал последний бастион: ext2ifs не умеет автомаунтить диск при загрузке системы (или умеет, но эта фича не работает в семерке). Впрочем, это починилось через написание автозагрузочного bat-файлика, который юзает mountvol. Дальше все заработало как часы.

Пару слов про симлинки. ntfs-3g умеет читать симлинки NTFS, но зато не умеет их создавать. Вернее, умеет, но создает их в линуксовом формате, который не распознается виндой. Кроме того, симлинки между NTFS-партишенами у меня не заработали (ессно, я пытался их заюзать, когда оба партишена были подмаунчены). У ext2ifs та же проблема. Читать он умеет, а создавать нет - когда я попробовал заюзать виндовый mklink, он мне написал, что сабжевая файловая система не поддерживает симлинки. Впрочем, симлинки с ext на NTFS, равно как и симлинки с NTFS на ext - работают на ура.

Чтобы два раза не вставать, упомяну еще и самбу. Без проблем получилось расшарить папку из-под убунты и заюзать ее из винды, а также наоборот. Впрочем, и здесь случилась одна загадочная ситуация, причем я пока что не смог ее разрулить. Дано: на десктопе убунта, на ноуте убунта. Если копировать файлы на ноут, то скорость 9-10 MB/s. Если копировать в обратном направлении, то всего лишь 4 MB/s. Вначале я думал, что это из-за того, что ноут пускает данные по wi-fi, но, даже после отключения wi-fi, остались все те же четыре метра в секунду. Загадки во тьме.

Есть и однозначно хорошие новости. И виндовый, и убунтовый дропбоксы прекрасно работают с одной и той же папкой. Причем убунтовый дропбокс корректно сохраняет юниксовые права доступа на файлы, а виндовый дропбокс их не отфигачивает.
glider

Вопрос насчет make

Решил обновить дрова к сетевой карте, скачал с сайта вендора, распаковал и сделал make. Бац - ошибка "/bin/sh: Syntax error: "(" unexpected". Ясно, блин - забыли заквотить PWD. Смотрю makefile, а там:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD)/src modules
Попробовал обернуть SUBDIRS в двойные и одинарные кавычки - ничего не получилось, попробовал эскейпить в $(PWD) специальные символы с помощью string substitution баша - ничего не получилось. Погуглил на тему "make whitespace in paths". Самый лучший ответ, который я нашел: "thanks all on your help but i have decided not to go on with this cause it is normal thing on linux not to make spaces in paths, folder names".

Что делать, как жить дальше?