Лучше всего не только размонтировать, но и дополнительно отключить резервную копию.
Вы, вероятно, ожидаете, что ваша резервная копия защитит вас в случае, если (например) кто-то случайно загрузит крипто-локатор. Или кто-то взламывает (компрометирует) вашу систему. Или странный сбой системы, повреждающий файловые системы. Или молниеносный выброс, который сжигает все ваши подключенные электронные устройства. Кто-то / что-то, что делает это, ограничено:
вы должны выбрать, от каких угроз вы собираетесь защищаться, с учетом затрат / неудобств.
Также помните о риске нежелательного раскрытия информации, а не только о риске нежелательной потери данных. Также вы можете создать несколько резервных копий, чтобы объединить преимущества. Например, может быть, каждый месяц вы переключаете жесткие диски USB - теперь у вас есть удобство, что он всегда подключен, но если кто-то рутировал машину и стирал ее, у вас была резервная копия за прошлый месяц в целости и сохранности.
@WumpusQ.Wumbley указал причину в комментарии:расширенные атрибуты .
Для полноты картины ответы представлены ниже.
Расширенные атрибуты , в данном случае примененные Dropbox(getfattr
возвращают user.com.dropbox.attributes
), используют дополнительные блоки для хранения. Без этих расширенных атрибутовls
(и других команд )возвращает:
$ ls -Gghs
total 136K
4,0K drwxr-xr-x 2 4,0K dec 22 20:11 empty_dir
0 -rw-r--r-- 1 0 dec 22 20:11 empty_file
4,0K -rw-r--r-- 1 1 dec 22 20:12 one_char
128K -rw-r--r-- 1 127K dec 22 20:13 several_blocks
Как и ожидалось.
Кроме того, stat
для единственного интересного случая several_blocks
возвращает:
$ stat several_blocks
File: several_blocks
Size: 129760 Blocks: 256 IO Block: 4096 regular file
...
Что также ожидаемо, поскольку 256 *512 -129760 = 1312 < 4096, т. е. дополнительный блок не используется.
«Дополнительные блоки» появились не из-за какой-то несогласованности в конфигурации. (Гипотетически это всегда может быть неправильно по какой-то другой причине. Как космические лучи, которые испортили код вашего ядра :-)).
Я говорю это потому, что нет возможности вручную настроить детали расчета использования диска для этих команд. Команды только преобразуют использование диска в другие единицы путем умножения или деления. Использование диска можно получить, вызвав системный вызов stat (). Ядро возвращает несколько синтетических «блоков», которые всегда имеют размер 512 байт. Также нет никаких параметров ядра, влияющих на то, как stat ()вычисляет количество блоков.
Я могу сказать вам, что блок, содержащий inode, не должен учитываться в вашей файловой системе ext4. В целом, Джайлз говорит, что это не учитывается ни в одной из известных ему файловых систем. Возможно, отчасти из-за поднятого вами вопроса :-). Иноды, как правило, меньше, чем 512 -байтовых блоков, о которых сообщает stat
. ext4 по умолчанию имеет 256 -байтовых инодов; ext3 по умолчанию имеет размер 128 байт.
Если мы просмотрим соответствующие вопросы (правую боковую панель ), мы заметим один случай, когда могут быть дополнительные блоки. Дерево экстентов (или косвенные блоки, если экстенты отключены ), считаются на ext4.(Почему разница в размере файла и его размера на диске превышает 4 КиБ?)
Второй ответ на связанный вопрос предполагает другой случай. Некоторые варианты использования fallocate ()могут позволить создавать файлы со сколь угодно большой разницей между их размером и количеством выделенных для них блоков.
Тем не менее, я подозреваю, что вышеизложенного недостаточно, чтобы объяснить любой из ваших примеров.