byobu - поля статуса не скрываются, когда I / O становится нулевым - ошибка или как ожидалось?
У меня еще нет dm-crypt с настройкой TRIM, но я также заинтересован в проверке этого. Сначала следует сказать, что это может быть невозможно, в зависимости от вашего SSD (см. Https://serverfault.com/a/401506/60525).
Предполагая, что у вас есть правильный тип SSD, Я вижу пару различных вариантов:
Проверьте это на очень маленьком блочном устройстве. Создайте зашифрованный раздел размером 20 МБ так же, как и для всей системы. Обязательно сначала заполните раздел случайными байтами. Затем создайте, напишите, очистите и удалите файл 10 Мб на зашифрованном fs. Запустите fstrim на установленном fs. Если все работает, вы должны увидеть около половины раздела 20Mb, заполненного нулевыми байтами. В качестве альтернативы вы можете убедиться, что через подсистему scsi выдается либо команда UNMAP, либо WRITE SAME scsi. Единственный способ, которым я нашел, чтобы увидеть пакеты scsi без использования аппаратного устройства или взломать ядро, - включить ведение журнала пакетов scsi: echo $ BITMASK> / sys / module / scsi_mod / parameters / scsi_logging_level Использование 9216, поскольку BITMASK было достаточно для меня, чтобы WRITE SAME cdbs отправлялись после fstrim ext4 fs, находящегося непосредственно на диске (без шифрования). Вы можете использовать либо fstrim на уровне fs, либо sg_unmap / sg_write_same на уровне устройства, чтобы вызвать TRIM. Когда вы найдете либо UNMAP, либо WRITE SAME, используйте scsi docs на t10.org, чтобы декодировать пакет и выяснить, на каком диске он ссылается. Затем проверьте, что диск имеет все нули в этом секторе (секторах).Последний подход более сложный, но он имеет преимущество в работе над уже существующими установками и намного проще при работе с файловыми системами с нестандартным размером. Вам может показаться достаточно, чтобы послать команду UNMAP или WRITE SAME (вам все равно, есть ли нули или нет?) Обратите внимание, что последний подход, скорее всего, не будет работать, если TRIM выполняется с помощью команды ata DATA SET MANAGEMENT, он не должен появляться в журнале scsi, и я не вижу способ получить ata cdbs. Но я бы сказал, что это менее 0,01% случаев.
Последнее решение может быть каким-то автоматическим, поэтому нам не пришлось бы декодировать пакет вручную. Любые получатели?
И насколько я сейчас не могу получить сопоставление зашифрованного блочного адреса с адресом блока устройства без взлома dm-crypt.c Итак, если вы хотите увидеть, что блоки удаленный файл на обрезанной fs на карте зашифрованного блочного устройства на нулевые сектора на устройстве, вы находитесь в мире боли.
1 ответ
Проницательность оригинального автора (Dustin Kirkland), мне удалось узнать, что моя версия byobu (5.17) была ошибкой, и что получение последней версии из службы ppa (5.33) разрешило ее. [!d0 ]
Debian byobu upgrade, официальный метод
Официальный метод обновления byobu - это фактически использовать какой-то репозиторий «Debian unstable»: https://answers.launchpad.net/byobu/+question / 184981
Debian byobu upgrade, официальный метод :
sudo wget http://blog.anantshri.info/content/uploads/2010/09/add-apt-repository.sh.txt -O /usr/bin/add-apt-repository
sudo chmod +x /usr/bin/add-apt-repository
# Followed by the "Ubuntu" commands below
Примечание: очевидно, что установка пакетов Ubuntu в Debian - это ваш собственный риск , Это случилось с моей системой TurnKeyLinux на основе Debian 6.0
Debian byobu upgrade, официальный метод :
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys F430BBA5
sudo add-apt-repository ppa:byobu/ppa
sudo apt-get update
sudo apt-get install byobu