Изменение размера раздела на слишком маленькое значение после уменьшения файловой системы
Пакет ffmpeg доступен на jessie-backports , чтобы установить его;
Отредактируйте свой sources. list, добавив следующую строку:
deb http://ftp.debian.org/debian jessie-backports main
Обновите и установите ffmpeg и qt4-dev-tools:
sudo apt-get update
sudo apt-get -t jessie-backports install ffmpeg
sudo apt-get install qt4-dev-tools
Скачайте исходники из здесь и соберите вашу программу:
git clone https://github.com/MaartenBaert/ssr/
cd ssr
./configure --without-pulseaudio --without-jack
make -j8
sudo make install
Запустите ssr из терминала через :
simplescreenrecorder
Я изменил размер раздела до слишком маленького значения, что привело к повреждению файловой системы?
Это маловероятно в вашем случае, тем более, что вы были достаточно любезны, чтобы остановить убийцу fs (c), но вы не можете исключить возможность полностью.
Например, повреждение происходит, когда это логический раздел внутри расширенного раздела таблицы разделов msdos. Логические разделы представляют собой связанные списки, поэтому между логическими разделами есть сектор, указывающий на следующий раздел в списке. Если вы уменьшите / измените размер такого логического раздела, то где-то в середине диска будет перезаписан (частично) сектор.
Также некоторым программам разметки может понравиться обнуление данных. То же самое и с LVM, при каждом lvcreate он обнуляется, как первый 4K созданного LV, и, кроме того, нет никакой гарантии, что изменение неверного lvresize вернет вам те же экстенты, которые использовались ранее. Если вам не повезет, LV может быть физически расположен в другом месте, поэтому вы можете отменить такие аварии только с помощью vgcfgrestore чего-то из / etc / lvm / {backup, archive} / , которое было создано ранее. lvresize.
В SSD есть такая причуда TRIM, которая заставляет всевозможные программы выдавать на SSD необоснованные команды TRIM. LVM делает это, если issue_discards = 1 в lvm.conf (всегда устанавливайте значение 0), чтобы надеяться, что различные программы разбиения никогда не примут такое поведение.
Достаточно ли успешного запуска e2fsck, чтобы быть уверенным, что данные не были повреждены?
Большинство файловых систем не в состоянии обнаружить повреждение данных вне их собственных метаданных.Обычно это не проблема, потому что нельзя выполнять подобные трюки. Если у вас есть резервная копия, вы можете сравнить временные метки / контрольные суммы файлов с тем, что есть в ваших резервных копиях.
Я не смонтировал файловую систему в течение всего процесса (и даже не смонтировал ее).
Вы можете смонтировать его только для чтения, например:
mount -o loop,ro /dev/sdn1 /mnt/somewhere
, а затем проверить файлы.
Цикл , ro сообщает mount создать устройство цикла только для чтения и смонтировать его. Удивительно, но ro сам по себе не гарантирует доступность только для чтения для некоторых файловых систем, включая ext4 . (А для файловых систем с несколькими устройствами, таких как btrfs , цикл , ro тоже не работает, потому что он влияет только на одно устройство, а не на все).