Вчера я удалил 71 ГБ файлов на своем домашнем / медиа сервере.
Свободное пространство до: 117 ГБ
Свободное место после: 126 ГБ
Таким образом, вместо 71 ГБ дополнительного свободного места у меня было только 9 ГБ. Я дважды проверил, что файлы не были открыты, и я действительно удалил 71 ГБ, а свободное пространство действительно увеличилось только на 9 ГБ.
Я тоже пытался синхронизировать, но безрезультатно.
Это не первый раз, когда это происходит. Действительно, я видел такое поведение с годами время от времени. Сначала на ext3, теперь на ext4.
Когда это происходит, я могу освободить свободное место, отмонтировав, а затем перемонтировав файловую систему. В этих случаях размонтирование занимает почти 2 минуты, а не почти без времени.
В настоящее время я не могу легко размонтировать и перемонтировать файловую систему, потому что она постоянно занята моим программным обеспечением видеомагнитофона, сервером owncloud для моей семьи и несколькими другими службами, которых у меня до сих пор не было. И я не хочу вставать в 3 часа ночи только для того, чтобы размонтировать и перемонтировать.
Нет, утилита «at» не подойдет, потому что одна из служб выполняет не возобновляемые долгосрочные задачи и, следовательно, нуждается в ручной проверке состояния, чтобы найти подходящий момент, когда ее можно закрыть, то есть задача только что была завершена.
Но сегодня утром я заметил, что место освободилось за одну ночь. Мне кажется, что была какая-то очистка, и это может быть то же самое, что требует дополнительного времени при размонтировании.
Пока что я заметил это только при удалении большого количества данных. С другой стороны, я не уверен, что это происходит регулярно, а разница слишком мала, чтобы заметить.
Файловая система была создана с 0% зарезервированным для root (mkfs -m 0). Согласно fsck -f (я делаю это всегда между размонтированием и перемонтированием), файловая система не повреждена, и в соответствии с расширенным тестом диагностики SMART, оборудование также в порядке.
[РЕДАКТИРОВАТЬ]
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name: bigdata
Last mounted on: /bigdata
Filesystem UUID: 6aebd17a-e064-41dc-9c68-c9a3acbe4f66
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 121413632
Block count: 485645568
Reserved block count: 0
Free blocks: 29081276
Free inodes: 121382378
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 908
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Tue Dec 25 23:42:35 2012
Last mount time: Fri Jan 3 17:37:36 2014
Last write time: Fri Jan 3 17:37:36 2014
Mount count: 37
Maximum mount count: -1
Last checked: Thu Apr 18 17:03:40 2013
Check interval: 0 (<none>)
Lifetime writes: 14 TB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: be2b977e-5127-4843-9123-fe33b6d7b573
Journal backup: inode blocks
[/РЕДАКТИРОВАТЬ]
Итак, вот мои 2 вопроса:
- Что здесь происходит? Почему место освобождается в размонтированном виде или с задержкой, а не сразу при удалении?
- Есть ли что-то, что я могу сделать, чтобы вызвать освобождение места прямо сейчас без демонтажа и перемонтирования?