[HDI] Поиск и очистка inodes в Linux

Как известно, каждому файлу в Linux’е соответствует не только место на диске, но и некоторое количество inode. Как и место на диске, inod’ы тоже могут заканчиваться, и результат примерно тот же — создавать новые файлы становится невозможно.

Узнать, сколько inodes уже использовано можно с помощью команды

df -i

Но если узнать, кто занял все место — несложно, то понять, кто съел inode’ы чуть посложнее. Обычно они пропадают из-за большого количества мелких, как правило, временных файлов, которые кто-то не убрал за собой

С определением места, где все это добро хранится, может помочь такой вот несложный скриптик:


#!/bin/bash
# count_em - count files in all subdirectories under current directory.
echo 'echo $(ls -a "$1" | wc -l) $1' >/tmp/count_em_$$
chmod 700 /tmp/count_em_$$
find . -type d -print0 | xargs -0 -n1 /tmp/count_em_$$ | sort -n
rm -f /tmp/count_em_$$

Скрипт показывает, сколько inode использованы различными папками. Анализируются папки, начиная с той, откуда был запущен скрипт. То есть для поиска по всей файловой системе нужно запускать скрипт из корня.

P.S. своровано отсюда: http://stackoverflow.com/questions/653096/howto-free-inode-usage

Рунглиш. Новояз. Жаргон.

Когда я впервые после учебы пришел работать в серьезную IT-компанию, мне, безусловно, пришлось учиться быстро и многому. И прежде всего мне пришлось учится понимать речь своих новых коллег. В первую неделю, натурально, я понимал от силы треть, когда ребята обсуждали между собой какие-то рабочие моменты. Общаясь со мной, они старались говорить попроще, но и тогда половина слов и их сочетаний оставались непонятными.

К концу первой недели я начал-таки понимать основы этого нового языка, и вторая неделя прошла под знаком перевода: я мог понять, что говорят люди вокруг только прикладывая осознанные и значительные усилия по трансформации их речи в понятные мне образы и сущности. Дальше все было попроще, и через пару месяцев я сам разговаривал на работе фразами, в которых от русского языка были только предлоги — остальные слова или сменили значение, или были какими-то неологизмами, или кальками с английского. Я-то привык быстро, а вот домашние удивлялись моей речи, если мне вдруг звонили с работы.

Профессиональный жаргон — дело не новое, и думаю большинство с ним сталкивалось в своей работе, а уж в сфере IT — просто все. Жаргон свойственен любой профессии; где-то его больше, где-то меньше. В IT обилие жаргона связано, на мой взгляд, прежде всего с тремя аспектами:

  1. Нет общения с посторонними. Чаще всего айтишники общаются с себе подобными. К ним не приходят люди с улицы заполнять бланки. Для общения с заказчиками зачастую есть специальный человек, и программисты, тестировщики и т.д. могут позволить себе речь отличающуюся от повседневной средней нормы чуть менее чем полностью.
  2. Высокий уровень абстракции. Айтишники работают с тем, что невозможно потрогать руками; в лучшем случае можно посмотреть на строчки кода или нарисовать диаграмму, записать последовательность действий или сделать скриншот. Поэтому в разговоре приходится либо оперировать длинными и сложнопроизносимыми понятиями, либо заменять их одинм словом, понятным далеко не всем. Обычно выбирается второе — так быстрее. Кстати, я тоже пишу «айтишники» вместо «люди, работающие в сфере информационных технологий» — по той же причине.
  3. Заимствование терминов. Многие термины и жаргонные слова, используемые айтишниками, заимствованы либо скалькированы из английского языка. Это понятный и естественный процесс: поскольку вся документация доступна прежде всего на английском языке, то зачастую проще использовать английский термин, чем придумывать или вспоминать адекватный перевод, причем еще неизвестно — поймет ли собеседник этот перевод. Так, в предыдущем абзаце я написал «скриншот», хотя мог бы написать «снимок экрана». Многие айтишники даже отказываются от использования русифицированных версий программ, ибо «мало ли, как они там в меню Options перевели».

Итог, конечно, со стороны выглядит ужасно: люди чирикают на своем птичьем языке, понять их неподготовленному человеку решительно невозможно. А ведь нередко нужно еще и как-то решить, платить ли этим людям за разработку сайта/приложения или лучше к другим уйти.

В оправдание айтишников можно упомянуть, что заказчик нередко тоже говорит на собственном языке (используя, например, жаргон нефтегазовой отрасли), и его тоже еще надо суметь понять.  Впрочем, я в любом случае не призываю к ликвидации жаргона и общению на чистом литературном русском языке.

У жаргона есть свои преимущества, и главное из них — ускорение общения. Нам же не шашечки нужны, а ехать. Важно, чтобы разработчики (программисты, тестировщики, технические писатели и т.д.) быстро и верно поняли друг друга обсуждая ту или иную проблему, а говорят ли они при этом языком тургеневских персонажей — дело десятое. Другое дело, что жаргон стоит оставлять на работе, не использовать его разговаривая с продавцом в магазине или соседом по балкону. Но, вообще говоря, не так много шансов его использовать вне работы: темы совершенно другие, и слова их описывающие тоже.

Конечно, порой жаргон оказывается вреден, самый очевидный пример — уже упоминавшееся общение с заказчиком. Не случайно рекомендуют к общению с заказчиками привлекать специальных людей (их по-разному могут называть), которые будут говорить с клиентом на его языке, а потом перескажут все программистам в понятных им терминах.

Но на самом деле тут все несложно, нужно просто помнить о двух вещах: роли жаргона и личности собеседника. Основная роль жаргона, как уже упоминалось, ускорение коммуникации. Если сам жаргон начинает, наоборот, тормозить общение — значит нужно от него отказаться. А тормозить общение он начинает когда собеседник с этим жаргоном не знаком (или, тоже интересный вариант, знаком с похожим жаргоном, в котором употребляются схожие слова, вот только значения у них другие).

Другое дело, что выяснить, какой же язык понятен собеседнику — куда сложнее, чем то, что ваша обычная речь повергает его в изумление.

В целом же, повторюсь, все просто. Достаточно немного следить за собой, чтобы использовать жаргон только тогда, когда он действительно необходим. В остальных же случаях можно и по-человечески разговаривать.

P.S. Конечно, жаргон порой используется и для других целей — подавления собеседника неизвестными терминами, демонстрации своей учености/крутости, укрывания сути проблемы за непонятным набором слов, и т.п. Я не хочу здесь останавливаться на этих моментах подробно, поскольку меня сейчас интересует конструктивное использование жаргона, а не борьба с его темными сторонами.

[HDI] Создание ISO-файла в Linux

Создание ISO файла из подключённого CD/DVD диска

dd if=/dev/cdrom of=/cdrom_image.iso

где

  • dd == «disk dump» — утилита для побитового копирования
  • if == «input file» — устройство, откуда читать
  • of == «output file» — файл, куда писать

 

Создание ISO файла из папки

mkisofs -D -iso-level 4 -o ./myimage.iso ./myfolder/

где

  • -D — позволяет работать с деревьями папок глубокой вложенности
  • iso-level 4 — позволяет работать с длинными именами файлов
  • /myimage.iso  — путь к создаваемому ISO-файлу
  • ./myfolder/ — путь к папке, содержимое которой надо поместить в ISO-файл.

Скучная работа

Disclaimer.

Есть несколько классических холиваров, в которых рано или поздно (а чаще — время от времени) должен поучаствовать каждый тестировщик. Как-то: важность тестирования в процессе разработки ПО; уровень квалификации, небходимый тестировщику; место и роль автоматического тестирования и т.д.

Чтобы уже не возвращаться больше к холиварам в этом году, сегодня пост на одну из таких вечных тем, а именно — насколько интересна работа в отделе тестирования.

Необходимое классическое вступление.

Бытует мнение, что тестирование ПО — занятие скучное и нетворческое. Сидят, дескать, тестировщики, кликают кнопки, ползают по интерфейсу, растрачивают молодость впустую. Нет у них ни свободы, ни силы воли, ни способности сделать нечто, не упомянутое в тест-кейсе. Были бы они чуть умнее — давно бы робот вместо них работал, но нет среди них умных. Убогое царство.

А что, не так, что ли?

Вообще говоря, многие виды деятельности со стороны выглядят глуповато. Агроном все лето только и делает, что по полям гуляет; бездельник, что ты. Программист, тестировщик, верстальщик целыми днями мышку таскают да клавишами шуршат; любая обезьяна так может. Токарь точит и точит свою бесконечную гайку. А что токари бывают шести разных разрядов — так это дело известное: чего только люди ни придумают от безделья.

Но это так, присказка.

Как вообще понять, интересная работа или нет? Я вижу три способа:

  1.  Попробовать и понять. Хочешь понять, вкусна ли жареная форель, — закажи в ресторане и съешь. Хочешь понять, интересно ли тестирование, — поработай тестировщиком. Тут конечно есть опасность, что в данном ресторане просто не умеют готовить форель, но мы этот случай рассматривать пока не будем.
  2.  Спросить и поверить. Можно спросить людей, которые уже работают тестировщиками или знакомы с тестировщиками, нравится ли им их работа. Правда, придется полагаться на мнение других людей. А они, может, вообще рыбу не любят, не только форель.
  3.  Узнать и подумать. Попытаться понять, из чего все-таки состоит работа тестировщика, и подумать, интересна ли подобная деятельность. Тут тестирование выгодно отличается от форели, и какие-то объективные данные таки можно получить.

Собственно, я и хочу привести некий обобщенный, но неполный список того, чем занимается отдел тестирования.

Список

  • оценка затрат на тестирование и проверку (того или иного функционала или требований)
  • планировние тестирования (что и когда будет делаться)
  • обсуждение новых фич и их спецификаций с заинтересованными лицами (роль тестировщиков может варьироваться от пассивного чтения документа до полноправного участия в создании спецификации. Какая роль будет в реальности во многом зависит от самих тестировщиков)
  • тестирование новой функциональности (с использованием различных подходов)
  • создание тестовой документации (в соответствии с принятым в компании стандартом. Да, возможно — и разработка этого стандарта)
  • создание артефактов необходимых для тестирования функциональности (тестовые данные, скрипты и т.п.)
  • исследование и описание найденных дефектов (что обычно требует глубокого понимания тестируемой области)
  • проверка исправленных дефектов (здесь тоже без понимания того, что нужно проверить, никуда. А хорошо бы еще и вокруг посмотреть)
  • автоматизация имеющихся тестов (причем вполне возможно, что далеко не каждый из имеющихся тест-кейсов имеет смысл автоматизировать. Кстати, какой язык программирования будем использовать?)
  • выбор средств автоматизации и создание фреймворка для автоматизации тестов (либо выбор и покупка существующего готового решения с последующим допиливанием. А без единого фреймворка и смысла в автоматизации нет. Ох, его еще и поддерживать/развивать придется)
  • проведение нагрузочного тестирования (что так же включает в себя выбор средств для создания/имитации нагрузки, создание скриптов и программ выполняющих тестирование и анализирующих данные. И — да, нагрузочные тесты для разной функциональности часто не имеют между собой почти ничего общего)
  • проведение регрессионного тестирования (включая автоматизированные и неавтоматизированные тест-кейсы)
  • проведение usability-тестирования (для различных интерфейсов, например API и GUI)
  • проведение тестирования безопасности (права доступа, инъекции, бэк-доры и т.д.)
  • проверка пользовательской документации (документация — часть продукта. Мы же тестируем продукт, а не программу, верно?)
  • организация и настройка среды тестирования (тестовых стендов для всех видов тестирования — функционального, нагрузочного и т.п. в соответствии с нуждами и здравым смыслом. Системы бэкапов для критичных данных. Служебных серверов для различных нужд. Сети. И так далее)
  • обслуживание среды тестирования (заказ, покупка, починка серверов. планирование апгрейдов имеющегося железа и ПО, etc)
  • разработка, внедрение и поддержка внутренних сервисов облегчающих разработку (wiki, баг-трекеры, таск-трекеры и многое другое)
  • анализ дефектов, пропущенных отделом и найденных клиентами (бывает и такое, нужно же понять, почему оно бывает)
  • анализ успехов и неудач (чтобы знать, где мы молодцы, а что можно и нужно улучшать. А также разработка и внедрение улучшений в процесс тестирования, а то и разработки в целом)
  • регулярное предоставление информации о состоянии и качестве продукта другим заинтересованным лицам и отделам (а это значит, что это состояние регулярно каким-то образом измеряется и оценивается. Каким образом? Это тоже придется решить)

Вот такой кратенький список, всего-то 19 пунктов. Из них от силы три (тестирование функциональности, описание и проверка дефектов) вспоминают те, кто заводят речь о скуке тестирования. Кстати, вся эта деятельность происходит не в пыльной отдельной коробке, а при активном взаимодействии с кучей разных людей — программистов, техподдержки, сисадминов, менеджеров и т.д. И без постоянного изучения новых технологий и продуктов тоже дело редко обходится.

Резюме.

Такая вот скучная профессия.