Про кол-во файлов в папках

Как то в 2004 я удивлялся папке с почти 300-ми тысячами файлов. Давеча пришлось натолкнуться на другую “папочку”. Ls и find файлы никак не хотели посчитать. Помогла MC-шка :). Входила туда три дня, но таки вошла.

Capture1

 

Кол-во файлов: 10 769 779. Ух!

Перешел на Яндекс

Наконец то перешел на Яндекс, как на основной поисковик и браузер, вообще то давно пора было :). Поводом стало дичайшее торможение FF после апдейта на 18 версию около месяца назад. Сам поисковик тоже, субъективно, шустрее, все, кажется, стало в 100500 раз быстрее. Посмотрим, как родная компания справится в основном с англоязычным технологическим поиском.

Коннект к DB2 из под Ubuntu/PHP, ошибка SQLSTATE=57017

После установки DB2/ODBC модуля по Php/Ubuntu вылазила ошибка

[unixODBC][IBM][CLI Driver] SQL0332N Character conversion from the source code page "819" to the target code page "UNKNOWN" is not supported. SQLSTATE=57017

Очевидно проблема с локалями. Заметил, что для клиента важна переменная LANG, которая в коммандной строке  LANG=en_US.UTF-8, а из под апачей LANG=C.

Для фикса достаточно заменить в /etc/apache2/envvars export LANG=C на . /etc/default/locale.

Ископаемый сервер на факультете

Пока его не заменили Микротиком, хотелось бы запечатлеть.

  • Диск 3 Гб
    jetman@morpheus:~$ df -h
    Filesystem            Size  Used Avail Use% Mounted on
    /dev/hda1             2,6G  1,2G  1,3G  49% /
    Aug 13 22:20:41 morpheus kernel: hda: ST33210A, ATA DISK drive
    Aug 13 22:20:41 morpheus kernel: hda: 6346368 sectors (3249 MB) w/256KiB Cache, CHS=787/128/63
  • Версия линукса
    jetman@morpheus:/home$ cat /etc/motd
    Linux morpheus 2.4.18 #3 17 15:10:59 EEST 2003 i686 GNU/Linux
    [Debian GNU/Linux 3.0 _Woody_ – fsn.hu’s i386 Binary-1 (20020329)
  • Дата установки
    Apr 12  2002
  • Процессор и память
    Aug 13 22:20:40 morpheus kernel: Detected 634.787 MHz processor.
    Aug 13 22:20:40 morpheus kernel: CPU: Intel Celeron (Coppermine) stepping 06
    Aug 13 22:20:40 morpheus kernel: Memory: 255052k/262080k available (1194k kernel code, 6640k reserved, 878k data, 236k init, 0k highmem)
  • Мало того. Он еще и всю маршрутизацию на себе держит. 10 лет назад его уже ставили “временно” в работу в достаточно пожилом возрасте.

Google Spreadsheet SQL – это просто

Я в восторге! Оказывается в гугловых таблицах можно прямо внутри ячеек писать SQL-подобные запросы обращаясь к данным в таблицах. Функция QUERY. Описание языка тут – коротко и предельно ясно. Для меня, как человека очень хорошо понимающего SQL и мало чего понимающего в вывернутом мире таблиц, данная фича становится шикарным инструментом!

P.S. Если в таблице стоит русская или украинская локаль, не забываем, что параметры в функциях разделяются точкой с запятой, а не запятой. Наступил на эти грабли N-нный раз.

Принудительное оживление секторов под Linux

Только вчера писал про замену винчестеров, сегодня выяснилось, что и второй диск сервера умирает. MD массив раздела /boot не хотел взлетать на оба крыла, кусочек с нового диска переходил в состояние Spare, так как при попытке синхронизации на основном куске, который на старом и уже тоже помирающем диске, были не читаемые сектора. Мне повезло: данных на секторах не было, что, тем не менее, не позволяло успешно просинхронизироваться. На всякий случай сделал dump -0 -f somefile /boot, для бекапа данных и попробовал реанимировать сектора по статье: http://www.sjvs.nl/?p=12. Последовательность такая:

  1. Убираем раздел из массива (который новый и не может встроиться, так как старый с битыми секторами) mdadm –manage /dev/md1 –remove /dev/sda2.
  2. Очищаем его суперблок, что бы заново добавить mdadm –zero-superblock /dev/sda2.
  3. Пытаемся еще раз добавить  mdadm –manage /dev/md1 –add /dev/sda2. Наблюдаем как процесс в /proc/mdstat подвисает, в это время можно погрепать tail -f /var/log/kern.log | grep sector. Увидев сообщение … end_request: I/O error, dev sdb, sector 68151475, выписываем номер сектора.
  4. Проверяем, что сектор действительно не читается  hdparm –read-sector 68151475 /dev/sdb.
  5. Перезаписываем сектор hdparm –write-sector 68151475 –yes-i-know-what-i-am-doing /dev/sdb.
  6. Перепроверяем, что сектор начал читаться предыдущей командой.
  7. Заново повторяем пункты 1, 2, 3, пока не найдем и перезапишем все сектора. После нахождения массив нормально поднимется.

Далее можно внимательно проанализировать SMART состояние диска smartctl -a /dev/sdb и принять решение о замене.