А сколько у тебя памяти?

Возможно здесь злую шутку сиграл zfs

Во-первых, да. zfsonlinux хоть и развивается, но для серьезного использования не дорос ещё. Пробовал его использовать раза 2 или 3 за последние 3 года, в итоге всегда сталкивался с теми или иными багами в какой-то момент. В большинстве случаев, на ровном месте. Какое-то время использовал его вместо lvm для виртуалок - то есть как управление томами (zvol). Пожалуй, единственная фича с которой у меня пока не было проблем.

Перед активными действиями решил сделать резервный синк 3T Винта на 3T USB3 винт

Пару месяцев назад сталкивался с похожей проблемой сразу на нескольких внешних кейсах для 3.5 дюймовых HDD, как раз таки с интерфейсом UDB3.0. В какой-то момент операции записи на HDD сначала зависали на время, а потом внешний диск и вообще полностью переставал писать и весь процесс записи подвисал, попутно каким-то образом нехило нагружая всю систему. В итоге оказалось, что виноват контроллер Jmicron использовавшийся в адаптере sata->usb3.0.

Много лет назад, ещё во времена ядра 2.6 - я писал драйвера для нескольких USB устройств под Linux (на предприятии, устройства собственные), и в итоге пришел к пониманию, что реализация подсистемы USB в линуксе в общем более строгая и чувствительная к сбоям, чем в венде. Сам по себе USB как интерфейс весьма нестабилен, и венда походу дела забивает на очень многие сбои в его работе.

Вобщем, мой вам совет - если хотите нормальной работы с БОЛЬШИМИ внешними винтами, освойте e-Sata. Сколько я не пробовал синкать сотни гигов на внешние винты по USB - получить 100% ожидаемый результат во всех случаях мне так и не удалось.

не кро та

всё закономерно. общая говеность железных частей не выдержала элементарный тест на нагрузку.

Сейчас всё стало настолько «круто» что тяжело искать причины косяков, а если найдёшь остаётся лишь пинать создателей или отказаться от косячного.

а исправить не?

USB 3.0 — он такой.

kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for evaluate context command
kernel: xhci_hcd 0000:00:14.0: Stopped the command ring failed, maybe the host is dead
kernel: xhci_hcd 0000:00:14.0: Abort command ring failed
kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for a slot
kernel: xhci_hcd 0000:00:14.0: Abort the command ring, but the xHCI is dead.
kernel: xHCI xhci_free_dev called with unaddressed device
kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for a slot
kernel: xhci_hcd 0000:00:14.0: Abort the command ring, but the xHCI is dead.

А сколько у тебя памяти?

8G

Возможно здесь злую шутку сиграл zfs

Во-первых, да. zfsonlinux хоть и развивается, но для серьезного использования не дорос ещё. Пробовал его использовать раза 2 или 3 за последние 3 года, в итоге всегда сталкивался с теми или иными багами в какой-то момент. В большинстве случаев, на ровном месте. Какое-то время использовал его вместо lvm для виртуалок - то есть как управление томами (zvol). Пожалуй, единственная фича с которой у меня пока не было проблем.

Ну не знаю, у меня за пару лет лишь один раз посыпался раздел, но данные с него были считаны путём монтирования в read-only (по подсказке здесь). Ну ещё и от deduplicate пришлось отказываться - дикие тормоза. Ну

Перед активными действиями решил сделать резервный синк 3T Винта на 3T USB3 винт

Пару месяцев назад сталкивался с похожей проблемой сразу на нескольких внешних кейсах для 3.5 дюймовых HDD, как раз таки с интерфейсом UDB3.0. В какой-то момент операции записи на HDD сначала зависали на время, а потом внешний диск и вообще полностью переставал писать и весь процесс записи подвисал, попутно каким-то образом нехило нагружая всю систему. В итоге оказалось, что виноват контроллер Jmicron использовавшийся в адаптере sata->usb3.0.

У меня винту уже 3 года. Первый раз такое. Наверное в одной из подсистем что нибудь «улучшили».

Много лет назад, ещё во времена ядра 2.6 - я писал драйвера для нескольких USB устройств под Linux (на предприятии, устройства собственные), и в итоге пришел к пониманию, что реализация подсистемы USB в линуксе в общем более строгая и чувствительная к сбоям, чем в венде. Сам по себе USB как интерфейс весьма нестабилен, и венда походу дела забивает на очень многие сбои в его работе.

Так если более строгая - надо ошибки отрабатывать, а не виснуть.

Вобщем, мой вам совет - если хотите нормальной работы с БОЛЬШИМИ внешними винтами, освойте e-Sata. Сколько я не пробовал синкать сотни гигов на внешние винты по USB - получить 100% ожидаемый результат во всех случаях мне так и не удалось.

Спасибо за совет, но меня пока устраивает USB3. Под e-Sata надо и поддержку со стороны компьютера и для винта надо какой то бокс. USB3 может и в USB2 работать - Более универсальное решение.

Написал с утра я этот ответ в Firefox и stretch запущенный на P-III/1000 с RAM:512 доблестно замёрз. Весь день гонял комп в cpuburn, stress, memtest - всё в порядке. Вечером опять Mozilla и респект его создателям - а в том же тереде нажал «отетить» и мой текст появился. Дописал ещё пару строк и опять локап. Теперь пишу в epiphany. Посмотрим как он отработает.

Я конечно понимаю что у меня «говно мамонта», но нет в жизни счастья...

всё закономерно. общая говеность железных частей не выдержала элементарный тест на нагрузку.

Нифига, «тест на совместимость» не выдержали ни P-III ни Linux.
Впрочем что касается начального топика то похоже дело в OOM killer. zfs скушала всю память и OOM Killer убил и samba, и ssh и другие процессы позволяющие общаться с системой.
Пару месяцев аптайма на этом железе было как то, но крайний был всего пару дней.

а исправить не?

Увы, я не программер.
Но как тестер недавно помог исправить очень специфичную багу в grub (он трапался на Via C3). Теперь не должен, но я не проверял - там уже стоит lilo.

Увы, я не программер.

ну, грамотный багрепорт это уже полдела. А если автор багрепорта еще и не поленился софт пересобрать с дебагом и прогнать поглядеть на чем он вешается - то даже не половина, а 3/4 решенной проблемы

У меня винту уже 3 года.

А сам винт проверяли ? Как-бы 3 года для современных винтов это уже край.

ну, грамотный багрепорт это уже полдела. А если автор багрепорта еще и не поленился софт пересобрать с дебагом и прогнать поглядеть на чем он вешается - то даже не половина, а 3/4 решенной проблемы

Научишь?
В случае с grub - один из разработчиков связался и вместе мы выяснили в чём косяк. Писать с нуля полноценные баг-репорты не умею.

А сам винт проверяли ? Как-бы 3 года для современных винтов это уже край.

При чём тут это? ОС ОБЯЗАНА сообщить об ошибке, а не тупо виснуть.
Винт уже с ремапленными секторами, но после перезагрузки всё отработало. Контрольный проход длился: 2:36:07elapsed на полностью синхронных разделах. Как я уже выше предполагал - была ситуация ООМ (Недельный аптайм файрфокса, rsync с пакованного zfs на пакованный zfs) и OOM Killer прибил критичные процессы.

Кстати только rsync крайний раз висел 3мя процессами каждый из которых кушал 500мб резидентной. Итого 1.5Gb и с недельным файрфоксом кушающем гига 4 резидентной и гиг 7 виртуальной есть конкретный OOMдаже с 8G Рамы...

В общем совокупный косяк - прибились те процессы - которые должны оставаться. Надо было просто файрфокс убить и всё... а не ssh,sh,samba.

ну, грамотный багрепорт это уже полдела.

Кстати на счёт баг-репорта. Есть простой баг репорт - но не знаю как и кому. В общем надо чтобы инсталлер Debian ставил не -pae ядро на тех процах что его не держат.

По другому я не могу это объяснить. Сейчас пишу с P-III/1000. Третье сообщение и пока не виснет. Всего то поставил не -pae ядро, а pae удалил. Пишу из файфокса.

Сначала думал висняк из за железа. Всё мазал, чистил, тестил.

Ошибок нет, а виснет... Потом заметил что pae ядро и решил заменить. 20 минут - полёт нормальный.

XScreensaver может быть удалён из Debian (комментарий)

XScreensaver может быть удалён из Debian (комментарий)

Да это голимый холивар любителей разных дистров.
Я тоже когда то начинал с RedHat, но переполз на Debian и вполне доволен. Менять дистрибутив через несколько лет работы это жесть.
Банально я не знаю можно ли RedHat/CentOS поставить на lvm живущем на софтверном RAID5 ? Все системные настройки живут в других местах... Привычные приложения работают «не так». Столкнулся с этим когда на работе затребовали поднять CentOS как бесплатную и на которую можно было поставить коммерческий биллинг собирающийся только под CentOS. К нему надо было прикрутить массу костылей для взаимодействия. После Debian это показалось жестоким...

мне после убунты (linux mint точнее, не переношу unity) debian кажется какой-то недоделкой школьинка

не знаю как вы это терпите

мне после убунты (linux mint точнее, не переношу unity) debian кажется какой-то недоделкой школьинка
не знаю как вы это терпите

«Самая короткая дорога - знакомая».
По мне убунта - это одни свистелки да перделки. Красиво, но лопает проц. Mint пока не пробовал.
В Debian пока всё работает, пусть не со свистелками и перделками, и иногда требуется напильник - но работает.

Банально я не знаю можно ли RedHat/CentOS поставить на lvm живущем на софтверном RAID5 ?

В таких случаях, обычно, берётся виртуалка и проверяется.

ОС ОБЯЗАНА сообщить об ошибке, а не тупо виснуть.

Собственно, она вам и сообщила об ошибке, когда произошло OOM, вы ведь потом в журнале как-то прочитали об этом неприятном событии, так ? Вот вам и репорт о нештатной ситуации. А какое именно сообщение об ошибке вы хотели-бы увидеть в таком критическом случае ? Где вы его хотели-бы увидеть ? На экране ? СМС на телефон отправить ? Пуш-уведомление ? Вы предварительно озаботились тем чтобы сделать и настроить себе такой канал для отсылки уведомлений ? Проверили его на стабильность ? Это ведь вам не венда - никто за вас ничего не настроит.

Винт уже с ремапленными секторами, но после перезагрузки всё отработало.

То есть винт уже полу-дохлый. Контроллеры usb->sata, которые либо идут отдельной платкой во внешних боксах, либо просто припаиваются к винту в случае отдельных внешних винтов, в основной своей массе не слишком хорошо работают при возникновении ошибок у винтов. Сама ОС и ZFS рассчитывают на определённое поведение электроники винтов и определённую реакцию при возникновении проблем с носителем. Если носитель при выходе из строя сможет грамотно репортнуть об этом ОС - то всё ок, если не сможет, то может произойти что угодно. Даже многие полноценные внутренние винты не очень хорошо работают при возникновении ошибок: когда, например, у меня сдохла плата электроники в Seagate ST3500320AS, она что-то непотребное сделала со всем sata интерфейсом, так что комп вообще не видел никаких носителей, пока я его не подержал выключенным минут 5. По этой причине многие и любят внешние raid контроллеры, которые дают некий дополнительный уровень защиты на уровне электроники (да и то не всегда). А как поведёт себя в случае ошибки внешний носитель - неизвестно вообще никому (зачастую даже китайцам разрабатывающим контроллер usb->sata). При этом, опять-же, вы вообще проверяли как себя ведёт та-же zfsonlinux при возникновении ошибок на носителях ? Информацию какую-либо в сети искали ДО того как начать использовать нестабильную ФС у себя в своём домашнем продакшене ? Хоть немного поизучали баг-репорты и свежие ошибки вашей версии драйвера ? Изучали-ли вы чужой опыт использования перед применением у себя ? Но да, когда ваша шарманка использующая подобные нестабильные компоненты внезапно сдохла при нагрузке - виноват линукс, его разрабы, да и вообще кто угодно, а не вы. По мне так это эталонный случай ССЗБ, уж извините.

OOM Killer прибил критичные процессы.

Вы вот всё ругаете ОС, а по мне так она сделала именно то что и должна была сделать. Системные процессы от ZFS (жрущие овердофига памяти, кстати говоря), она точно не могла убить. А вот ssh,sh,samba - с точки зрения ОС - точно такие-же процессы как и файрфокс. Вы предварительно замерили какие из них жрут больше памяти ? Настраивали приоритеты OOM-Killer'а чтобы он не убивал, скажем, SSH ( загуглите oom killer settings ) ? Хоть как-то указали ОС - что «вот эти пользовательские процессы убивать нельзя (через /proc/<PID>/oom_adj». Так что ОС сделала ровно то что и должна была сделать по документации - убить неактивные и неиспользуемые фоновые процессы с максимальным потреблением памяти (тот-же файрфокс-то по статистике ОС точно больше времени процессорного сожрал и чаше использовался, чем SSH). Настроили-бы OOM по другому - он бы и отработал так как вы хотели, а не так как было по дефолту настроено.

Ошибок нет, а виснет... Потом заметил что pae ядро и решил заменить. 20 минут - полёт нормальный.

Stretch таки опять замёрз. Перебрался на Jessie. Пишу в ней. Похоже 4 ядро уже не катит на старых процах...

Где читать куда слать репорты по ядру? Или не ядру?
Пока на Jessie 25 минут - полёт нормальный. И сюда пишу, и в свой wordpress написал...

Stretch таки опять замёрз. Перебрался на Jessie. Пишу в ней. Похоже 4 ядро уже не катит на старых процах...

Stretch и ядро видимо не при чём. Проблема в GPU или AGP. Jessie на 44 минуте тоже «замёрзла». Сейчас другая видюха и AGP уменьшил до 2x. Аптайм пока 7:35. Надеюсь проблема найдена и обойдена...

Хотел изменить, но истёк срок возможности изменения :(

Впрочем это уже оффтопик, топик был про потерю компа с Jessie в результате rsync. Предположение про OOM логи не подтвердили, или не там искал (Нет строк «Out of Memory» в /var/log/*). Но при детальном рассмотрении лога во время происшествия увидел:

-----
Jun 25 09:05:41 Zer0 kernel: [928920.320872] rsync           D ffff880056790668     0 24687  24686 0x00000000
Jun 25 09:05:41 Zer0 kernel: [928920.320874]  ffff880056790210 0000000000000086 0000000000012f00 ffff880055c73fd8
Jun 25 09:05:41 Zer0 kernel: [928920.320877]  0000000000012f00 ffff880056790210 ffff8802255e2368 ffff8802255e2220
Jun 25 09:05:41 Zer0 kernel: [928920.320879]  ffff8802255e2370 0000000000000000 ffff8802255e2320 ffff8800519ca000
Jun 25 09:05:41 Zer0 kernel: [928920.320881] Call Trace:
Jun 25 09:05:41 Zer0 kernel: [928920.320886]  [<ffffffffa06895d5>] ? cv_wait_common+0xd5/0x110 [spl]
Jun 25 09:05:41 Zer0 kernel: [928920.320888]  [<ffffffff810a7e60>] ? prepare_to_wait_event+0xf0/0xf0
Jun 25 09:05:41 Zer0 kernel: [928920.320906]  [<ffffffffa077235b>] ? txg_wait_open+0xbb/0x100 [zfs]
Jun 25 09:05:41 Zer0 kernel: [928920.320921]  [<ffffffffa072f2f0>] ? dmu_tx_wait+0x370/0x380 [zfs]
Jun 25 09:05:41 Zer0 kernel: [928920.320935]  [<ffffffffa072f39b>] ? dmu_tx_assign+0x9b/0x510 [zfs]
Jun 25 09:05:41 Zer0 kernel: [928920.320949]  [<ffffffffa07a9d58>] ? zfs_write+0x3c8/0xb70 [zfs]
Jun 25 09:05:41 Zer0 kernel: [928920.320953]  [<ffffffff811bc4c5>] ? core_sys_select+0x1e5/0x280
Jun 25 09:05:41 Zer0 kernel: [928920.320966]  [<ffffffffa07bf58b>] ? zpl_write_common_iovec+0x7b/0xd0 [zfs]
Jun 25 09:05:41 Zer0 kernel: [928920.320978]  [<ffffffffa07bf778>] ? zpl_write+0x78/0xa0 [zfs]
Jun 25 09:05:41 Zer0 kernel: [928920.320982]  [<ffffffff811a88b2>] ? vfs_write+0xb2/0x1f0
Jun 25 09:05:41 Zer0 kernel: [928920.320984]  [<ffffffff811a93f2>] ? SyS_write+0x42/0xa0
Jun 25 09:05:41 Zer0 kernel: [928920.320987]  [<ffffffff81514a0d>] ? system_call_fast_compare_end+0x10/0x15
-----

Попробую откомментировать длинный текст.

Банально я не знаю можно ли RedHat/CentOS поставить на lvm живущем на софтверном RAID5 ?

В таких случаях, обычно, берётся виртуалка и проверяется.

Где ещё на всё это взять время...

ОС ОБЯЗАНА сообщить об ошибке, а не тупо виснуть.

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

Нет, я просто предположил. Залез в журнал и там нет OOM, но есть другое (чуть выше привёл).

Вот вам и репорт о нештатной ситуации. А какое именно сообщение об ошибке вы хотели-бы увидеть в таком критическом случае ? Где вы его хотели-бы увидеть ? На экране ? СМС на телефон отправить ? Пуш-уведомление ? Вы предварительно озаботились тем чтобы сделать и настроить себе такой канал для отсылки уведомлений ? Проверили его на стабильность ? Это ведь вам не венда - никто за вас ничего не настроит.

Даже винду одного производителя умельцы перекраивают так что после установки она имеет разный вид, а уж в Линуксе с его обилием дистрибутивов наверняка где то предусмотрено. Вот сейчас придут и скажут: «Выкиньте этот ваш Дебиан - у нас в „XXX“ это всё есть...». Если у компа есть экран - то на нём должна быть возможность видеть диагностику. Даже когда всё умерло (включая логи) - экран чаще всего доступен.

Винт уже с ремапленными секторами, но после перезагрузки всё отработало.

То есть винт уже полу-дохлый. Контроллеры usb->sata, которые либо идут отдельной платкой во внешних боксах, либо просто припаиваются к винту в случае отдельных внешних винтов, в основной своей массе не слишком хорошо работают при возникновении ошибок у винтов. Сама ОС и ZFS рассчитывают на определённое поведение электроники винтов и определённую реакцию при возникновении проблем с носителем. Если носитель при выходе из строя сможет грамотно репортнуть об этом ОС - то всё ок, если не сможет, то может произойти что угодно. Даже многие полноценные внутренние винты не очень хорошо работают при возникновении ошибок: когда, например, у меня сдохла плата электроники в Seagate ST3500320AS, она что-то непотребное сделала со всем sata интерфейсом, так что комп вообще не видел никаких носителей, пока я его не подержал выключенным минут 5. По этой причине многие и любят внешние raid контроллеры, которые дают некий дополнительный уровень защиты на уровне электроники (да и то не всегда). А как поведёт себя в случае ошибки внешний носитель - неизвестно вообще никому (зачастую даже китайцам разрабатывающим контроллер usb->sata). При этом, опять-же, вы вообще проверяли как себя ведёт та-же zfsonlinux при возникновении ошибок на носителях ? Информацию какую-либо в сети искали ДО того как начать использовать нестабильную ФС у себя в своём домашнем продакшене ? Хоть немного поизучали баг-репорты и свежие ошибки вашей версии драйвера ? Изучали-ли вы чужой опыт использования перед применением у себя ? Но да, когда ваша шарманка использующая подобные нестабильные компоненты внезапно сдохла при нагрузке - виноват линукс, его разрабы, да и вообще кто угодно, а не вы. По мне так это эталонный случай ССЗБ, уж извините.

Именно виноват. Надо предусмотреть неотключаемое средство диагностики с консоли. Даже на нормальном сервере в датацентре - есть консоль для разборок, и порой ip консоль.

OOM Killer прибил критичные процессы.

Это я «погорячился»

Вы вот всё ругаете ОС, а по мне так она сделала именно то что и должна была сделать. Системные процессы от ZFS (жрущие овердофига памяти, кстати говоря), она точно не могла убить. А вот ssh,sh,samba - с точки зрения ОС - точно такие-же процессы как и файрфокс. Вы предварительно замерили какие из них жрут больше памяти ? Настраивали приоритеты OOM-Killer'а чтобы он не убивал, скажем, SSH ( загуглите oom killer settings ) ? Хоть как-то указали ОС - что «вот эти пользовательские процессы убивать нельзя (через /proc/<PID>/oom_adj». Так что ОС сделала ровно то что и должна была сделать по документации - убить неактивные и неиспользуемые фоновые процессы с максимальным потреблением памяти (тот-же файрфокс-то по статистике ОС точно больше времени процессорного сожрал и чаше использовался, чем SSH). Настроили-бы OOM по другому - он бы и отработал так как вы хотели, а не так как было по дефолту настроено.

Не знаю в чём была проблема, но записей OOM я не нашел. При этом комп был жив, мыргал винтом, рисовал экран с мышкой, но ни с клавы ни по ssh ни по samba доступен не был.
Вот Alt-PrtSCR+K я не попробовал - не знал тогда о нём.

А вообще топик про «нет в жизни счастья». Компьютерную техноллогию так накрутили - что ИИ творит чему научили...

мне после убунты (linux mint точнее, не переношу unity) debian кажется какой-то недоделкой школьинка

Debian взрослая ОС работающая на самом широком спектре оборудования. А ваши мяты скажем не поставятся на моём P-III/1000 с CD-ROM ибо нет компактного имиджа для записи на CD, а с USB эта машинке грузиться не умеет.

не знаю как вы это терпите

Мы в этом работаем. Пусть порой с напильником, но оно ставится и на VIA C6 и удалённо на Hetzner-овский сервак. И на LVM поверх Программного RAID5. И с этого даже грузится.

Ну а взять тот же CentOS 7 - оно хочет лишь x64 - потому фсад.
Всякие Gentoo конечно везде встанут - но думаю собирать пакеты на древних компах весьма унылое занятие. Остальное в основном форки Debian,RedHat,Gentoo,Arch.
Я лучше останусь с Дистром работающем практически везде. Чем радоваться свистелкам и перделкам на современном оборудовании.

Просвятите пожалуйста как это нужно трактовать

Трактовать call-trace в достаточно несложно: это список функций, выполняемых в момент сбоя. Какого именно сбоя - не совсем понятно, вы случаем не вырезали несколько строчек СВЕРХУ данного сообщения об ошибке ? Тут показана вложенность вызовов. Заметьте, что в момент сбоя у вас выполнялась непосредственно функция модуля spl (является частью zfsonlinux). Это, конечно, не говорит, однозначно, о баге в zfs, а скорее просто как-бы намекает. В идеале надо под отладчиком смотреть, где именно rsync крашнулся (крашнулся-ли?) во время какого именно вызова (полагаю что он завис на вызове cv_wait_common), и что именно пошло не так.

Хотя я полагаю, что всё таки виноват именно zfs. Так как по запросу в гугле «cv_wait_common+0xd5/0x110» - выдаются практически такие-же трейсы как и у вас, точно с такой-же вложенностью. И с такими-же симптомами «я что-то там писал-писал на диск, а оно зависло» : https://github.com/zfsonlinux/zfs/issues/475

В общем, переходите на нормальную фс и не мучайтесь. ZFS ещё слишком бажная.

Трактовать call-trace в достаточно несложно: это список функций, выполняемых в момент сбоя. Какого именно сбоя - не совсем понятно, вы случаем не вырезали несколько строчек СВЕРХУ данного сообщения об ошибке ?

Я выбрал то что начиналось с «rsync D» и до «lwresd D». Там ещё масса процессов посыпалось до и после rsync.

Тут показана вложенность вызовов. Заметьте, что в момент сбоя у вас выполнялась непосредственно функция модуля spl

spl илиzpl?

(является частью zfsonlinux). Это, конечно, не говорит, однозначно, о баге в zfs, а скорее просто как-бы намекает. В идеале надо под отладчиком смотреть, где именно rsync крашнулся (крашнулся-ли?) во время какого именно вызова (полагаю что он завис на вызове cv_wait_common), и что именно пошло не так.

Я не понял из за чего крашнулась толпа процессов - в их числе и rsync. Но ни samba ни ssh там нет, а я не мог ими воспользоваться.

Хотя я полагаю, что всё таки виноват именно zfs. Так как по запросу в гугле «cv_wait_common+0xd5/0x110» - выдаются практически такие-же трейсы как и у вас, точно с такой-же вложенностью. И с такими-же симптомами «я что-то там писал-писал на диск, а оно зависло» : https://github.com/zfsonlinux/zfs/issues/475

Ну ладно, пусть будет zfs.

В общем, переходите на нормальную фс и не мучайтесь. ZFS ещё слишком бажная.

Пусть бажная, но разделы с марта 2014и данные пока живы.
Использовать начал потому что не хватало 2T и хотелось упаковки на лету. Такую возможность имели лишь zfs и btrfs. btrfs не прошел тест драйва. Не помю что - но косячило. zfs прошел.
У zfs свои феньки и в плане упаковки и в плане монтирования.
Доходило до того что я /var/spool загонял в zfs и монтировал в /var/spool. При этом система нормально грузилась и работала. Там можно спокойно создать подтом в томе zfs и смонтировать его куда надо, выставить нужные параметры (ну скажем упаковку).

На этом разделе у меня 5971965 файлов (rsync отрапортовал на последнем синке). Я даже не знаю альтернативную fs. Продакшн ext4 имеет хороший оверхид на больших разделах. btrfs как то неадекватно в тестах отработал. Остаются jfs и xfs и на обеих в своё время огребал косяки - та же фрагментация просаживает производительность. В то время (лет 8 назад) на разделах в 600G уже были тормоза - вот и решил поюзать новую ФС. 2 года пока держится. Купило то что идеология разрабатывалась давно, архитекторами крупной компании и показала свою зрелость - а открытую реализацию рано или поздно допилят.

В плане ошибок - резерв рулит. У меня конечно не полноценный инкрементальный бэкап - просто синкаю время от времени на USB3 3T. Кстати пустой синк (нет изменений) занимает 2:36

Так пока и живу. Барахла много а удалять не люблю...
Но надо - из 3T осталось лишь 10G, а дочь с женой из крайней поездки привезли флешку фоток...

spl илиzpl?

SPL. Solaris Porting Layer. https://github.com/zfsonlinux/spl . Является частью zfsonlinux.

Пусть бажная, но разделы с марта 2014и данные пока живы.

Есть такое выражение: «редко, но метко». Впрочем, если у вас есть актуальный бекап, то всё не так страшно, конечно.

Продакшн ext4 имеет хороший оверхид на больших разделах. btrfs как то неадекватно в тестах отработал.

А вы сами проверяли ? Неужели, оверхид настолько большой по сравнению с ZFS, который ещё и чексуммы хранит к каждому блоку данных ?

В общем, решайте сами что использовать. У всех разные требования к надежности, производительности ФС и остальному. По мне так - EXT4 сейчас единственная ФС на которую я более-менее могу положиться в плане надежности. У XFS, например, не отключается delalloc (хотя хз, может уже сделали, я год назад последний раз искал), и свежие данные могут находиться только в оперативке часами. Много раз на этом уже обжигался, особенно когда памяти у машины действительно много (там 8, 16, 32 гига, например). btrfs временами превращается в тыкву, со всеми данными, jfs устарел ещё лет 10 назад.

spl илиzpl?

SPL. Solaris Porting Layer. https://github.com/zfsonlinux/spl . Является частью zfsonlinux.

Увидел, я просто не там смотрел.

Пусть бажная, но разделы с марта 2014и данные пока живы.

Есть такое выражение: «редко, но метко». Впрочем, если у вас есть актуальный бекап, то всё не так страшно, конечно.

Ну бэкап не совсем актуальный, но есть.

Продакшн ext4 имеет хороший оверхид на больших разделах. btrfs как то неадекватно в тестах отработал.

А вы сами проверяли ? Неужели, оверхид настолько большой по сравнению с ZFS, который ещё и чексуммы хранит к каждому блоку данных ?

Я не помню в цифрах, но я тупо взял 500G, синкнул туда около 500G барахла и посмотрел оставшееся место (df), затем то же сделал на zfs, но сейчас я конечно понимаю в чём косяк. ext4 ведь 5 чтоли процентов кушает резервом для рута (при формате по умолчанию). Это видимо не оверхид и можно отформатить без этого резерва - но тогда не знал, а перемерять пока некогда - да и желания нет.
Что касается zfs - слышал что там два файла по границам чуть ли не в один сектор упаковываться могут. (т.е. конец одного файла и начало другого в одном секторе) - но это лишь:слышал.

В общем, решайте сами что использовать. У всех разные требования к надежности, производительности ФС и остальному. По мне так - EXT4 сейчас единственная ФС на которую я более-менее могу положиться в плане надежности.

Тем не менее там иногда случаются fsck и на большом разделе это долго.

У XFS, например, не отключается delalloc (хотя хз, может уже сделали, я год назад последний раз искал), и свежие данные могут находиться только в оперативке часами. Много раз на этом уже обжигался, особенно когда памяти у машины действительно много (там 8, 16, 32 гига, например).

Ну да, суровый у них кэш...

btrfs временами превращается в тыкву, со всеми данными,

Вот и у меня что то подобное было при стресс-тесте когда я при рсинке питание рубанул.

jfs устарел ещё лет 10 назад.

Да его разрабатывали в 90х, опять же известная фирма. Я начал её использовать ещё в горячо любимой OS/2.
В Linux тоже начал использовать как появилась - но там нет дефрагментации и фрагментация серьёзно просаживает производительность, однако данные на ней ни разу не терял.
Надёжная как танк...

Это видимо не оверхид и можно отформатить без этого резерва

Можно с помощью tune2fs на отмонтированной ФС установить такой процент какой нужно. В любой момент времени

Тем не менее там иногда случаются fsck и на большом разделе

FSCK через какое-то количество монтирований или временной интервал, настраивается тем-же самым tune2fs.

А вот в процессе создания ФС Ext4 - можно настроить количество inode'ов (и сэкономить место занимаемое служебными данными, уменьшив лимит на максимальное количество файлов на файловой системе), указать размер журнала, уменьшить количество копий суперблоков, изменить количество «групп» размещения (и опять сэкономит на служебных данных), и проинициализировать большую часть служебных данных сразу во время создания ФС.

Так что не так уж и много вся эта служебная инфа будет жрать места, если всё настроить правильно. Конечно, ни упаковки «хвостов» файлов, ни сжатия, в ext4 нет. Но и данные в тыкву не превращаются.

Надёжная как танк...

Угу. Перестал ей пользоваться когда этот самый «танк» ушел в вальгаллу прихватив с собой всю бухгалтерию. Хорошо что бекап был. jfs был очень хорош в своё время, но в какой-то момент перестал развиваться а потом и адекватно поддерживаться в линуксе. Не уверен даже, что поддержка JFS сейчас во всех дистрах включена в ядре.

FSCK через какое-то количество монтирований или временной интервал, настраивается тем-же самым tune2fs.

Мне он вообще не нужен, лучше без него.

А вот в процессе создания ФС Ext4 - можно настроить количество inode'ов (и сэкономить место занимаемое служебными данными, уменьшив лимит на максимальное количество файлов на файловой системе), указать размер журнала, уменьшить количество копий суперблоков, изменить количество «групп» размещения (и опять сэкономит на служебных данных), и проинициализировать большую часть служебных данных сразу во время создания ФС.

Кстати да, забыл про АД инодов... была у меня ситуация когда они закончились. Весьма неприятно, в продакшне кстати закончились...

Так что не так уж и много вся эта служебная инфа будет жрать места, если всё настроить правильно. Конечно, ни упаковки «хвостов» файлов, ни сжатия, в ext4 нет. Но и данные в тыкву не превращаются.

Но если ошибёшься в настройках - геморрой обеспечен.

pae везде

В общем надо чтобы инсталлер Debian ставил не -pae ядро на тех процах что его не держат.

если оно новее pentuim, то pae в нём есть.

ненадо pae винить. возможно дело в памяти. для некро-железа особенно характерно.

просто для pae в памяти хранится таблица транслитерация адресов, оверхед там незначетельный по месту.

Сначала думал висняк из за железа. Всё мазал, чистил, тестил.
Ошибок нет, а виснет... Потом заметил что pae ядро и решил заменить. 20 минут - полёт нормальный.

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

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

посему, предлагаю изначально исходить из допущения, что проблема в железе, если не доказано обратное. софт - это самая надежная часть коньпутера, особенно если речь ОС.

ненадо pae винить. возможно дело в памяти. для некро-железа особенно характерно.

Я в других сообщениях писал:

Stretch и ядро видимо не при чём. Проблема в GPU или AGP. Jessie на 44 минуте тоже «замёрзла». Сейчас другая видюха и AGP уменьшил до 2x. Аптайм пока 7:35. Надеюсь проблема найдена и обойдена...

Пока больше не висло.

видоекарта шарит кусок памяти. размер задается в настройках bios-a (и обычно зависит от модели)

просто видимо разное ядро по-разному выделяет эти куски памяти. или видеокарта использует его по-разному.

имхо, от памяти плясать надо.