Зависание графического окружения до окончания копирования по HDD

[eyakubovskiy]

Доброго дня.
Господа, столкнулся я на днях с неприятной ситуацией. При копировании образа виртуальной машины с одного HDD на другой зависло графическое окружение GNOME 3 пока не завершилось копирование.
Есть предположение, что это произошло из-за низкого приоритета процессов GNOME.

Кто-нибудь сталкивался с таким? Как решаете?
В чем может быть дело?
Согласны ли вы с идеей того, что системное программное обеспечение должно работать с более высоким приоритетом чем остальной софт?
Приоритет каких процессов имеет смысл повысить для проверки имеющейся теории?


Спасибо.

[alang]

GDM

Что ты под этим подразумеваешь?

[victor00000]

блок питания не хватает.

[Tear]

В чем может быть дело?

Bug 12309?

[eyakubovskiy]

Цитата: eyakubovskiy от 26 Сентябрь 2018, 19:28:16
GDM

Что ты под этим подразумеваешь?

Да, ошибся. Процессы не GDM, а GNOME. Исправил. Спасибо.
Пользователь добавил сообщение 28 Сентября 2018, 07:37:17:

блок питания не хватает.

Это маловероятно. В другой ОС все работало без проблем. А после перехода на 10 версию все стало работать еще лучше. Не системные процессы там стали существенно реже подвешивать графическое окружение. И чтобы так как у меня случилось в GNOME недвано - совсем небыло.
Очень напомнило как раньше при форматировании дискет было))))
Пользователь добавил сообщение 28 Сентября 2018, 07:56:45:

В чем может быть дело?

Bug 12309?

Скорее всего... читаю о проблеме. Спасибо

[victor00000]

Код: [Выделить]

grep -rsh "DRDY" /var/log/
?

[eyakubovskiy]

Код: [Выделить]

grep -rsh "DRDY" /var/log/
?

Пусто

Пользователь добавил сообщение 28 Сентября 2018, 18:10:31:Ситуация похожа на https://forum.ubuntu.ru/index.php?topic=299593.30
У меня тоже был перенос с NTFS на EXT4
Пользователь добавил сообщение 28 Сентября 2018, 19:14:27:Сегодня не воспроизводится. Если объявится - буду искать варианты решения.
Пока как вариант решения начитал про изменение параметров буфера записи на носитель.
vm.dirty_bytes=2097152
vm.dirty_background_bytes=2097152
Соответственно если воспроизведется - буду в первую очередь играться с этими параметрами.

[ALiEN]

vm.dirty_bytes=2097152
vm.dirty_background_bytes=2097152

Дополню - cовет вреден для btrfs. Cкорость записи на раздел упадет чуть ли не до нуля.

Пользователь добавил сообщение 30 Сентября 2018, 01:08:35:

(Нажмите, чтобы показать/скрыть)

$: dd if=/dev/urandom of=test1 bs=1M count=100                 
100+0 записей получено
100+0 записей отправлено
104857600 байт (105 MB, 100 MiB) скопирован, 0,561363 s, 187 MB/s
$: sudo sysctl -w vm.dirty_bytes=2097152           
vm.dirty_bytes=2097152
$: sudo sysctl -w vm.dirty_background_bytes=2097152           
vm.dirty_background_bytes = 2097152
$: dd if=/dev/urandom of=test1 bs=1M count=100     
100+0 записей получено
100+0 записей отправлено
104857600 байт (105 MB, 100 MiB) скопирован, 85,8212 s, 1,2 MB/s

[Sly_tom_cat]

cовет вреден для btrfs.

У ТС EXT4 же ....

Сори за оффтоп, но а почему такая фигня в btrfs? Где почитать?

[eyakubovskiy]

cовет вреден для btrfs

Читал, что на btrfs вроде как и нет таких проблем.

[victor00000]

Sly_tom_cat,
+1

[ALiEN]

Sly_tom_cat, да я видел, что ext4. Но форум-то многие читают, предупреждение тем, кто вдруг btrfs захочет так "оптимизировать".

Как я однажды так "поэкспериментировал", потом сутки голову ломал - почему у меня система по 40 минут обновляется..

[Sly_tom_cat]

ALiEN175, а удалось понять в чем суть этой проблеммы с BTRFS? Гуглеж что-то ничего не дал... А тема довольно любопытная...