Заметки

Года с 2008 я ленился обрабатывать накопленные raw-файлы, потому что от виндовой проги Canon для обработки у меня портится настроение и болят руки (а на Fuji я вообще не снимал равки, потому что там прога совершенно садистская), да и вообще у меня ни одного нормального компьютера с Виндовс давно нет, виртуальная машина отдельная мука сама по себе, а для Linux производители камер ничего не сделали (и Adobe тоже, насколько я знаю). И тут внезапно обнаружил, что уже есть вполне адекватный конвертер для Линукса: Darktable, причём он даже входит в репозиторий Убунту (sudo apt install darktable - и готово). А что ещё лучше, у него есть вариант для командной строки darktable-cli, которым можно одним махом перегнать целый каталог с raw-файлами в PNG или TIFF и просто свалить их в архив и выборочно (то что того стоит) редактировать уже привычным Гимпом. Уже проверил - результат после пары движений в Гимпе получается не хуже фирменного конвертера и намного лучше JPEG из камеры, по крайней мере для 40D, из которого у меня и лежит основная непроявленная масса. Для полного счастья не хватает только поддержки 16-битного вывода в darktable-cli в настоящий момент - если фотка сильно не попала по экспозиции то её всё-таки придётся обрабатывать самим Darktable. Сама прога успешно пишет в любой битности, так что, в принципе, можно просто гуёвым Darktable перегнать целый каталог в 16-битный TIFF - не совсем Linux-way, но пойдёт.

https://www.darktable.org/

Симптомы - с определённой периодичностью виртуальная машина съедает на несколько минут 100% от каждого выданного ей процессора (т.е. на 4 ядра - загрузка 400% и т.п.), при этом хост притормаживает, а виртуалка вообще неуправляема, т.к. даже движения мышки отрабатываются с огромной задержкой. В это время внутри виртуалки нет процессов, занимающих столько CPU. При этом, на хостах AMD такой проблемы нет. После долгих мучений, рабочий ответ, наконец, найден тут:

This actually is an IOMMU issue and the solution involves enabling it at the kernel command line. Enabling VT-d (the Intel IOMMU kernel driver) in the firmware isn't enough and tinkering with compaction_proactiveness and swappiness only constrain this behavior without addressing the underlying cause.
...
So, for GRUB, edit /etc/default/grub to add the above string to GRUB_CMDLINE_LINUX_DEFAULT, e.g.,

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on"

Save and close the file, then run:

# update-grub

Reboot to take effect.

https://unix.stackexchange.com/a/713470/415520

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

iotop

Если ввод-вывод активный и идёт прямо сейчас, достаточно просто посмотреть на sudo iotop -o
Если ввод-вывод идёт небольшими порциями, то используем: sudo iotop -bktoqqq -d .5
Пояснение: -b - пакетный режим вывода, -k - килобайты, -t - показывать время, -o - показывать только потоки, которые занимаются вводом-выводом, -qqq - отключить заголовки, -d 0.5 - период обновления в секундах.
Поймав, какой процесс занимается работой с диском, можно посмотреть на его открытые файлы: lsof -p $PID (замените $PID на номер интересующего процесса).

fatrace

Это намного более удобный способ для отслеживания редких операций (программа есть в репозитории Убунты). Сразу печатает кто, в какой файл лазит и какой доступ (чтение или запись).
cd /mnt/каталог_куда_смонтирован_винт
sudo fatrace -c -t

P.S. Типичные злодеи - индексаторы файловой системы, их можно выпилить так: sudo apt remove locate mlocate plocate. См. askubuntu. Также постоянным желанием писать на диск страдает Yandex.Disk - демона синхронизации можно гасить, когда он не нужен.

ВК перешёл на фотографии в формате webp в мобильном клиенте, но когда вы их сохраняете в галерею он пишет их с разрешением jpg. В результате, некоторые программы работают с этими файлами неправильно. Вот этот небольшой скриптик позволяет рекурсивно пройти каталог с такими неправильно названными файлами и переименовать их правильно:

·· [Read more · Читать дальше] ·· »»»

Это не универсальная инструкция, просто шпаргалка для себя. Мог что-то упустить

1. Форматируем новый винт. Записываем (копируем в текстовый редактор и т.п.) UUID будущего корневого раздела. Делаем этот раздел загрузочным (активным) (включаем флаг "boot").
2. Монтируем его, например, в /mnt/tmp.
3. Копируем файлы: cd /mnt/tmp && sudo cp -apxuR /* .
   Можно добавить -v для печати имён файлов в процессе работы, но это сильно замедляет копирование.
4. Правим /mnt/tmp/fstab (заменяем UUID для "/" на новый).
5. Правим /mnt/tmp/boot/grub/grub.cfg (заменяем UUID корневого диска на новый).
6. Проецируем системные каталоги в /mnt/tmp, чтобы сделать chroot:
   sudo mount -o bind /dev/ /mnt/tmp/dev
   sudo mount -t proc none /mnt/tmp/proc
   sudo mount -t sysfs none /mnt/tmp/sys
7. sudo chroot /mnt/tmp
8. sudo grub-install /dev/sdXXXX (Имя устройства, а не раздела!) Примечание: на некоторых машинах grub-install может занять несколько минут, а то и полчаса. Прерывать его не нужно, дайте доработать.

После этого перезагружаемся, выбирая при необходимости новый диск в качестве стартового в BIOS. Если всё ОК, можно отключать или форматировать и переиспользовать старый диск.