Косяк: аппаратный или программный?

Раз хост пингуется — косяк не аппаратный, нечего и проверять.

Что делать? Не пользоваться левым софтом, который, скорее всего, течет.

2 TБ

Meld

аааааааа

diff же!

Но потом решил проверить, как оно бекапнулось, сравнив побайтово с помощью софтины Meld, которой давно пользуюсь.

Спасибо, добрый человек! А то я, как идиот, хэшам доверял...

Как вдруг заметил, что мышь начала двигаться странными рывками, а потом и вовсе примерзла к своему месту.
Понажимал всякие кнопки на экране - не жмутся.
Жмакнул Ctrl-Alt-Del - никакой реакции.
Попытался перейти в консоль Ctrl-Alt-F2 - не переходит.

Сразу надо было Ctrl-Alt-Del или Ctrl-Alt-F2, а там kill сам знаешь какую программу... А ты потерял драгоценные мгновения :(

Но может, и программные траблы тоже могут так себя вести, что полностью замораживают систему?

Да

Не сталкивался еще с таким еще.

Вот ты и «спалился»... Троллишь стало быть...

Что делать? Не пользоваться левым софтом, который, скорее всего, течет.

Неужели утечка софта может быть такой, что внешне выглядит как чистейший аппаратный трабл?

А про diff, конечно, в курсе, он хотя и рассчитан в основном на сравнение тектсовых файлов, но емнип, с ключом --brief он сравнивает их как двоичные, а с ключом -r и каталоги с подкаталогами.
Но допустим, diff сравнит файлы без сбоев, но это все равно не говорит о том, что нет аппаратной проблемы, потому что может виноватой оказаться битая память, в которую Meld залазит глубже, набивая буфер до отказа, вплоть до системного стека, а diff ведет себя более скромно, довольствуя малыми порциями в буфере.

2 TБ
Meld

аааааааа

А на что вы тут тут так хитро намекали? :) Что Meld выше 2 ТБ не понимает. или что?

Раз хост пингуется — косяк не аппаратный, нечего и проверять.

А разве не может быть такое - центральный проц «отъехал», а микруха в Ethernet вполне себе рабтает автономно, т.е. пингуется.
А отклика по ssh нет, потом что проц заморозился.

Спасибо, добрый человек! А то я, как идиот, хэшам доверял...

Я тоже доверяю хешам, но сначала их надо заиметь, а для этого надо потратить тоже время, что и на банальное побайтовое сравнение (если не больше).

Ok. Срач так срач.

Как «делают» хэш

• считывают «что-то» из файла
• скармливают «что-то» функции, считающей хэш
• всё это повторяется много-много раз

Как «делают» побайтовое сравнение

• считывают «что-то» из 1-го файла
• считывают «что-то» из другого файла
• «сравнивают»
• всё это повторяется много-много раз

Мне одному кажется, что во 2-случае потребление памяти больше будет? Что бывает с системой когда память кончается ты уже знаешь...

Что meld для красивого отображения и для примитивного ручного слияния. Он и на 200 МБ дереве небыстр.

А на что вы тут тут так хитро намекали? :) Что Meld выше 2 ТБ не понимает. или что?

Meld is a visual diff and merge tool targeted at developers

Это обозначает, что на бинарные файлы скорее всего никто не расчитывал и не проверял.

По симптомам кто-то (наверное meld) просто сожрал всю память. В линухе такое поведение при нехватке ОЗУ - норма.

Что meld для красивого отображения и для примитивного ручного
слияния. Он и на 200 МБ дереве небыстр.

Почитал офсайт, но нет никаких упоминаний, что он базируется на diff, rsync или еще на чем-то системном, классическом и надежном.
Неужели они замутили работу с ФС на чем-то своем, орижинальном?
Тогда, конечно, они козлы не удивлюсь, что они в нем накосячили.

Это обозначает, что на бинарные файлы скорее всего никто не расчитывал и не проверял.

Ну и опровержения этому тоже на офсайте не нашлось.

По симптомам кто-то (наверное meld) просто сожрал всю память. В линухе такое поведение при нехватке ОЗУ - норма.

Позвольте, а как же своп?? И вообще - неужто LInux до сих пор не способен отслеживать нехватку памяти и соответствующим образом сигнализировать об этом, а не тупо фризить??

Тогда я под столом :( Как-никак, Линуксу исполнилось 25 лет, и что бы до сих пор такой баг не пофиксить, это надо очень постараться :((

не способен отслеживать нехватку памяти и соответствующим образом сигнализировать

лимиты, cgroups, userspace oom killer-ы

Тогда я под столом :( Как-никак, Линуксу исполнилось 25 лет

Это фича ибо copy-on-write. При помощи sysctl можно сделать чтоб было как в винде, но тогда своп придётся делать гигантский, т.к. некоторые погроммисты выделяют себе невероятное кол-во виртуальной памяти.

Это фича ибо copy-on-write.

И что дает эта фича?

лимиты, cgroups, userspace oom killer-ы

Это как - вместо того, чтобы разработчики дистров сразу настроили их так, чтобы с переполнением памяти не было проблем, я должен вместо них елозить рашпилем?
Сомнительное удовольствие.

Косяк: аппаратный или программный?

косяк у тебя мозговой.

Это фича ибо copy-on-write.

И что дает эта фича?

https://ru.wikipedia.org/wiki/Копирование_при_записи

разработчики дистров сразу настроили их так

Всем по-разному надо. В случае userspace oom ничем елозить особо не надо.

А вообще - «это линукс, детка» (ц)

Ладно. Главное, что отсюда вынес - надо придерживаться классики, входящей в дистрибутив, и держаться подальше от Meld и других новоявленных программ.

Всем спасибо!

Кстати - Meld сравнивал бекап на 2 ТБ порядка ~10 часов.

Пока с вами тут общался, запустил сравнение с помощью Rsync, т.е. с ключиками -nc
Так он сравнил эти массивы всего за .... real = 225m36,088s!!!

Я просто офигел от этой скорости ;-O
И никаких глюков при этом!

Получается, этот Meld не только косячное, но и жутко тормозное у.е.!!!
В-общем - фтопку его.

Ща еще с diff попробую.

заменил старые SATA-кабели на заведомо качественные на 6 ГБ

К слову, не бывает 6GB SATA-кабелей.

Своп включен на компе? Судя по всему, meld сожрал всю память, а свопа нет.

так это же обычное поведение линукса, когда оперативка заканчивается, развп нет? так что волноваться неочем - ЭТО НОРМА!

Ну не знаю, как точно называются современные как бы «двойные» черные кабели.
Раньше использовал обычные старые - красные в общей оболочке.

Ну а как же! Писал же за своп, который почему-то не помог.
Своп у меня 9 ТБ, оперативки 8 ТБ -

Mem:              7           1           0           0           5           5
Swap:             9           0           9

Кстати, кто хорошо разбирается в логике сравнения файлов с помощью команды diff ?

Хотя изначально она предназначена для проверки тестовых файлов, но если использовать ключик --q / --brief, то она сравнивает также и (имхо) бинарные файлы, и как только доходит до первого несравнения файлов, тут же сообщает об этом, прекращает проверку пары и переходит к проверку следующей пары файлов, потому что и так понятно, что текущая пара неравна.
А значит, это дает громадный выигрыш по времени сравнения.
Но - нет уверенности, что diff умеет корректно сравнивать не только текстовые, но и бинарные файлы.

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

Это лишь мои скромные догадки, поэтому буду признателен, если поправите мои ошибки.

Ни фига себе оперативки... Нафига тогда тебе диски такие - грузись и работай из RAM.

Не пользоваться левым софтом, который, скорее всего, течет.

Но это же форум про линукс, те про пользование таким софтом.

Своп у меня 9 ТБ, оперативки 8 ТБ

У тебя реально

Своп у меня 9 ТБ, оперативки 8 ТБ

?!

Тогда понятно почему ты никогда не видел фризов в системе...

Хард сдох.

На пинг отвечает ОС а не контролёр.

Ребята, простите - так уж повелось, что я вечно путаю мегабайты с гигабайтами и терабайтами :)
Не по незнанию, конечно, а из-за невнимательности.

Конечно же, оперативки всего 8 ГБ


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

Я с точностью до секунды знаю, когда система заморозилась, потому что его видно по «замерзшим» часикам в трее.
И внимательно изучая логи в окрестностях этого времени, я не обнаружил ничего крамольного!
Вполне благополучный лог просто обрывается и все, далее идет новая загрузка.

Вот это - совершенно непонятно :(

Мегабайты, Гигабайты, Терабайты...

Как там у Высоцкого?

"... Королей я путаю с тузами,
А с дебютом путаю дуплет!

:))

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

Сначала рано паниковать, а потом поздно... Например, я сегодня тоже «доигрался»: поставил большой файл на загрузку и запустил на тот же раздел архивацию большого массива файлов. Когда консоль разродилась «no space on device» было уже поздно что-либо делать — команды не проходят или нет свободной памяти для запуска процесса (даже kill сначала должен занять немного оперативки)

Сейчас уже несколько часов система не отзывается и не упала пока что. Наверное своп ещё не закончился. Остаётся только с другой машинки LOR читать...

Наверное, и вы не дождетесь у моря погоды, и вам тоже придется жать великий и могучий Reset :))

Впрочем, может вам и повезет, если зайдете по SSH ?

Выбор у меня не велик: Reset или ... случиться чудо и «падут X-ы». Подожду, чего-там. Сам виноват, не надо было отвлекаться. «Аппарат» старый и слабый. Но основная причина нынешнего фриза моя невнимательность.

SSH — что-то не тянет меня проверять сработает или нет...

P.S. Сейчас посмотрел: «машинка» ещё видна роутеру, но уже не пингуется. Только индикатор диска в бешенном темпе мигает.

Попробуй в следующий раз открыть JSON на 2 ТБ в vim.

диска в бешенном темпе мигает.

Мигает - значит, еще как-то функциклирует

SSH — что-то не тянет меня проверять сработает или нет...

Почему же? Вы ничем не рискуете.

Попробуй в следующий раз открыть JSON на 2 ТБ в vim

Нет уж, уж лучше вы к нам! :) В смысле - сами откройте :))

Зачем какой-то непонятный meld, когда есть rsync -c?

А разве не может быть такое - центральный проц «отъехал», а микруха в Ethernet вполне себе рабтает автономно, т.е. пингуется. А отклика по ssh нет, потом что проц заморозился.

Да, ещё как не может.