Очередное утро началось с чтения письма от smartd. Один из дисков сервера, который используется для резервного копирования всех остальных серверов, начал свой путь в лучший мир. В письме говорилось о появлении одного pending sector, но пока я ехал в офис от smartd пришло второе письмо, в котором говорилось, что этот сектор уже перешел в разряд offline uncorrectable. А вот это уже плохо, значит с большой долей вероятности считать данные из этого сектора уже не удастся.
Заметки о Linux, системном администрировании, программировании, электронике и не только
четверг, 18 июля 2013 г.
среда, 17 июля 2013 г.
JMicron JM20337 USB combo bridge - несовместимость с дисками Advanced Format
Собрался стереть суперблоки старого raid массива перед добавлением дисков в сервер. Подключил 2TB WDC WD20 EARX диск через USB переходник ([152d:2338] JMicron JM20337 Hi-Speed USB to SATA & PATA Combo Bridge). Но при попытке выполнить
получил ошибку (к сожалению саму ошибку я не сохранил, возможно добавлю в пост позже).
Полез в логи
Оказывается через USB мост информация о жестком диске искажена и вместо 512/4096 (размер логического/физического сектора) получилось 4096/4096. Тут и тут нашлись аналогичные жалобы на работу этого моста и дисков с advanced format.
$ sudo mdadm --zero-superblock /dev/sdb{1,2}
получил ошибку (к сожалению саму ошибку я не сохранил, возможно добавлю в пост позже).
Полез в логи
[184450.592853] usb 1-3.1.3: new high speed USB device using ehci_hcd and address 8 [184450.685697] usb 1-3.1.3: New USB device found, idVendor=152d, idProduct=2338 [184450.685700] usb 1-3.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [184450.685703] usb 1-3.1.3: Product: USB to ATA/ATAPI bridge [184450.685704] usb 1-3.1.3: Manufacturer: JMicron [184450.685705] usb 1-3.1.3: SerialNumber: 000001D91CA8 [184450.685794] usb 1-3.1.3: configuration #1 chosen from 1 choice [184450.686383] scsi10 : SCSI emulation for USB Mass Storage devices [184450.686474] usb-storage: device found at 8 [184450.686475] usb-storage: waiting for device to settle before scanning [184455.684536] usb-storage: device scan complete [184455.685016] scsi 10:0:0:0: Direct-Access WDC WD20 EARX-00PASB0 PQ: 0 ANSI: 2 CCS [184455.685496] sd 10:0:0:0: Attached scsi generic sg1 type 0 [184455.687848] sd 10:0:0:0: [sdb] 488378646 4096-byte logical blocks: (2.00 TB/1.81 TiB) [184455.690581] sd 10:0:0:0: [sdb] Write Protect is off [184455.690585] sd 10:0:0:0: [sdb] Mode Sense: 28 00 00 00 [184455.690587] sd 10:0:0:0: [sdb] Assuming drive cache: write through [184455.691505] sd 10:0:0:0: [sdb] 488378646 4096-byte logical blocks: (2.00 TB/1.81 TiB) [184455.692239] sd 10:0:0:0: [sdb] Assuming drive cache: write through [184455.692245] sdb: sdb1 sdb2 [184456.128375] sdb: p2 size 30585128320 exceeds device capacity, enabling native capacity
Оказывается через USB мост информация о жестком диске искажена и вместо 512/4096 (размер логического/физического сектора) получилось 4096/4096. Тут и тут нашлись аналогичные жалобы на работу этого моста и дисков с advanced format.
вторник, 16 июля 2013 г.
Узнать свой текущий IP адрес
Чтобы узнать свой текущий IP адрес можно воспользоваться услугами DynDNS http://checkip.dyndns.com/. Вывод страницы простой и легко поддается разбору в скриптах.
среда, 3 июля 2013 г.
Ошибка при удалении снапшота LVM: Can't remove open logical volume
Выкроил пару часов времени чтобы переписать скрипты резервного копирования на работу с LVM снапшотами.
В процессе работы скрипт создает снапшоты для всех точек монтирования, которые нужно бэкапить и которые расположены на LVM. У меня это все, кроме /boot.
Снапшот создается как обычно
Затем идет логика резервного копирования и по завершении снапшоты удаляются. Вот тут меня и поджидали грабли.
Ошибка проявляется не всегда, что наводит на мысли о гонке. Пробую гуглить и натыкаюсь на обсуждение аналогичной проблемы. Оказывается корень проблемы в установленном udisks, который использует современный десктопный софт в Linux.
Как вариант, можно закомментировать строкукостыльworkaround в свой скрипт, который несколько раз повторяет действие, если была ошибка.
В процессе работы скрипт создает снапшоты для всех точек монтирования, которые нужно бэкапить и которые расположены на LVM. У меня это все, кроме /boot.
Снапшот создается как обычно
# lvcreate --snapshot --name rootfs-backup --size 500M /dev/VolGroup0/rootfs
Затем идет логика резервного копирования и по завершении снапшоты удаляются. Вот тут меня и поджидали грабли.
# lvremove -f /dev/VolGroup0/rootfs-backup Can't remove open logical volume "rootfs-backup"
Ошибка проявляется не всегда, что наводит на мысли о гонке. Пробую гуглить и натыкаюсь на обсуждение аналогичной проблемы. Оказывается корень проблемы в установленном udisks, который использует современный десктопный софт в Linux.
Как вариант, можно закомментировать строку
KERNEL=="dm-*", OPTIONS+="watch"
в файле /lib/udev/rules.d/80-udisks.rules, но вместо этого я добавил for i in rootfs usr var home do for j in 1 2 3 4 5 6 7 8 9 10 lvremove -f /dev/VolGroup0/${i}-backup && break sleep 3 done if [ -e /dev/VolGroup0/${i}-backup ]; then echo "Failed to remove LVM snapshot VolGroup0/${i}-backup" exit 1 fi done
понедельник, 1 июля 2013 г.
Анонимные комментарии
Сегодня окончательно решил отключить анонимное комментирование. Причин для этого действия несколько:
- мне лень разбираться в какофонии, которую порой генерируют анонимные комментаторы. Одно дело, когда оставленный комментарий не подразумевает диалога и другое дело, когда несколько человек одновременно что-то спрашивают и ждут ответа - поди разберись что и кому писать;
- сегодня у большинства есть аккаунты, позволяющие комментировать не регистрируясь в моем блоге (google, facebook, openid, etc);
- сетевые партизаны мне не интересны.
Подписаться на:
Сообщения (Atom)