LINUX.ORG.RU

Стоит ли держать там VPS?

 , ,


1

4

Всем бобра.
на хецнере сегодня немного посрался с ТП.
я утверждал, что это их ссд бажный,
а они говорили, что у тебя ФС навернулась и в бекапах тоже сохранилась поломанная.
Переустановил, устав переписываться. Ошибка больше не проявлялась.
Я вообще не понимаю, как такой косяк мог появится на стабильной ext4. С тюнингом ФС не баловался, сайтики тихо ковырял...
утром включаю комп - сквид не работает. Захожу на впс - нельзя сквид стартануть,systemd ругается что корень RO. От рута выполняю sudo mount / -o remount,rw
не даёт, пишет ФС read only! У меня такое первый раз с ext4 было.

После проверки в rescue-режиме развёрнутых бекапов...невозобранно пропадал /usr/share. Что же такое могло, так весело повлиять на обычную ВПСку?


В логах творилось такое:

[ 1116.603306] EXT4-fs error (device sda1): ext4_iget:4783: inode #4252: comm joe: checksum invalid
[ 1117.606811] EXT4-fs error (device sda1): ext4_iget:4783: inode #4252: comm joe: checksum invalid
[ 1117.618006] EXT4-fs error (device sda1): ext4_iget:4783: inode #4252: comm joe: checksum invalid
[ 1118.030495] EXT4-fs error (device sda1): ext4_iget:4783: inode #4252: comm joe: checksum invalid
[ 1118.034489] EXT4-fs error (device sda1): ext4_iget:4783: inode #4252: comm joe: checksum invalid
[ 1118.038846] EXT4-fs error (device sda1): ext4_iget:4783: inode #4252: comm joe: checksum invalid

★★★★★

Последнее исправление: darkenshvein (всего исправлений: 1)

плюс, после разворачивания бекапа сквид сразу не мог стартовать из-за той же ошибки. то есть, и пары секунд после старта не проходило. А тут несколько дней бекапы делались, и сквид точно работал на какбы RO ФС по утверждению техподдержки. неверю!(ц)

darkenshvein ★★★★★
() автор топика
Ответ на: удаленный комментарий

Ты бы ещё btrfs накатиле и жаловалесь.

Внезапно, но она ведёт себя стабильнее, чем EXT4. Держу VPS на ней.

commagray ★★★★★
()
Ответ на: комментарий от commagray

Внезапно, но она ведёт себя стабильнее, чем EXT4.

а теперь мы достанем код обеих ФС, и культурна нах, а не как гуманитарии поясним, почему ext4 может потерять где-то данные, а btrfs нет, на примере демонстрирования поведения ФС, которое привело к потере данных.

darkenshvein ★★★★★
() автор топика

Да неудачно они ноду с твоей ВПС по питалову дернули. А бэкапы - какие-нибудь снепшоты LVM, вот и всё.

Deleted
()
Ответ на: комментарий от Deleted

После проверки в rescue-режиме развёрнутых бекапов...невозобранно пропадал /usr/share

...
прогона fsck то есть.
что же так криво ext4 написана, что из-за потери электричества каталоги теряет? да ладно

darkenshvein ★★★★★
() автор топика
Ответ на: комментарий от darkenshvein

ну если бы сквид не гонял, то можно было бы что-то ковырять.
Но сквид... прохладно же. Так что 50/50 кто-то там напортачил.

Deleted
()
Ответ на: комментарий от darkenshvein

Кстати, у тебя есть AMD FX-8350? Это ты бенчмарк шифрования на 5ГГц разгона выкладывал?

(в пределах текущих 3-4 годков?)

Deleted
()
Ответ на: комментарий от Deleted

А то вспомнил я это дело в теме про замену i5->Xeon

Deleted
()

Да всё норм же. У меня на совсем другом хостинге аналогичная история была. Техподдержка придерживалась мнения «сам – дурак».

Deleted
()
Ответ на: комментарий от Deleted

шифрования

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

darkenshvein ★★★★★
() автор топика
Ответ на: комментарий от darkenshvein

Любая ФС при определенных обстоятельствах может потерять каталог. Тем более, что здесь, скорее всего, хостер использует writeback. И рубанул электричество он в не самый удачный момент, когда у твоей ВПС много чего было позаписано на диски, как она думала, а на самом деле всё это было в кэше. А бэкап - снепшот, который в общем-то, тоже стал инконсистентным, так как опять же writeback.

Deleted
()
Ответ на: комментарий от Deleted

Тебе одного инода тупо хватило.

не понял вот это момент.
начнём с того, что это системный каталог ОС, создаваемый и наполняемый при установке ОС. Как он мог остаться только в кеше и не быть записанный на диск?

darkenshvein ★★★★★
() автор топика
Ответ на: комментарий от darkenshvein

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от slamd64

вот хз. не интересовался, какая там вышестоящая инфраструктура

darkenshvein ★★★★★
() автор топика
Ответ на: комментарий от slamd64

может писал о причинах более подробно где-то...

darkenshvein ★★★★★
() автор топика

Стоит. Живу там и горя не знаю.

Hertz ★★★★★
()

даже за питание дергать не надо, достаточно контейнер non-gracefully пару раз ребутнуть чтобы кровь кишки разэтосамое, не трогая при этом ноду.

slowpony ★★★★★
()
Ответ на: комментарий от slowpony

ну и на EXT4-fs error надо вовремя реагировать, логчек какой-нибудь настрой с фильтрами

slowpony ★★★★★
()
Ответ на: комментарий от slowpony

да были, ЧСХ, там бекапы. уже упоминал. восстановление из бекапа - тоже ломанная ФС.
Там два вида резервных копий, снапшоты и бекапы.
чем отличаются на хецнере, особо не вдавался в подробности. если снапшоты умеют в целостность ФС, тогда да, надо было юзать их.
я просто подключил «backups»

darkenshvein ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.