July 2nd, 2011

9may

Open Web Platform

Не следует привлекать новые сущности
без самой крайней на то необходимости.

Уильям Оккам


Сейчас веб-разработка сталкивается с большой проблемой - сверхнизкое повторное использование кода.

Как происходит, когда разработчик начинает делать свой проект, скажем, на PHP. Сначала он идет, например, на PHP Classes. Там очень много классов. Все разные. Каждый написано по-своему. У некоторых внешний интерфейс через один класс, у других через пять, у третьих через десять и два конфига. В результате требуется изучать архитектуру каждого класса, и, что самое важное, сайт из таких “компонентов” быстро не построишь.

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

Collapse )
Morda

Как я победил бэд-блок

Несколько колов времени назад я жаловался на проблему с бэд блоками на дисковом массиве.

Меня тут же стали пугать всякими ужасами насчет "если бэдблоки полезли за смарт" и "восстановления данных из битых lvm".  На самом деле, smartctl показывает Reallocated_Sector_Ct 12, и это количество не росло.  Также не росло и количество плохих блоков.
Все это продолжалось больше месяца, но сообщения в логах и опасения, что будет, если на эти бэды попадут метаданные, все-таки заставили меня действовать.

Я попытался разлить данные по другим машинам, запустил tar ... | ssh ... dd of=musom.tar.bz2 и обнаружил файл, чтение которого давало i/o error (tar говорил file truncated to ... и продолжал дальше).  Как я и подозревал, это был старый бэкап, потерю которого я вполне мог перенести. 
Я запустил dd if=[Этот файл] of=/dev/zero conv=noerror и получил пять сообщений i/o error, ровно по числу бэдов, находимых через badblocks и smartctl.
Дальше я запустил
dd conv=notrunc,noerror if=/dev/zero of=badblock.file count=61577512
Смысл в том, чтобы перезаписать данные файла нулями в надежде, что либо смарт редиректнет эти блоки, либо, если это софтовые бэды, что они исчезнут при записи.
Приблизительно в районе первого бэда, dd подвис (не реагировал на SIGUSR1), в логе появилось сообщение о сбросе дискового контроллера, потом dd отвалился с сообщением i/o error (оказывается, conv=noerror работает только на ошибки чтения).
Я еще раз запустил
dd conv=notrunc,noerror seek=27957670 if=/dev/zero of=badblock.file count=33619842
В логе прошли еще пять сообщений о сбросе контроллера, но dd прошел нормально и прописал остаток файла нулями до конца.
Сообщения в логе об Offilne Sectors прекратились. badblocks ничего не показывает.  Что меня больше удивило, Reallocated_Sector_Ct не увеличился, из чего я делаю вывод, что это были "софт бэды", а вовсе не дефект поверхности.

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