Вчора я видалив 71 Гб файлів на своєму домашньому / медіа-сервері.
Вільний простір до: 117 ГБ
Вільний простір після: 126 ГБ
Тож замість 71 ГБ додаткового вільного місця у мене було лише 9 ГБ. Я двічі перевірив, що жодних файлів не було, і я дійсно видалив 71 ГБ, а вільний простір дійсно збільшився лише на 9 ГБ.
Я також намагався синхронізувати, але ефекту немає.
Це відбувається не вперше. Справді, я спостерігаю таку поведінку з багатьох років. Спочатку на ext3, зараз на ext4.
Коли це станеться, я можу повернути вільний простір, демонтувавши та повторно переправивши файлову систему. У цих випадках відключення займає до 2 хвилин, а не майже часу.
Сьогодні я не можу легко відключити та перезавантажити файлову систему, оскільки вона постійно зайнята моїм програмним забезпеченням для відеореєстратора, сервером owncloud для моєї родини та ще кількома сервісами, яких у мене до цього часу не було. І я не хочу вставати о 3 годині ночі, аби лише зняти їх і переказати.
Ні, утиліта "at" не буде робити, тому що одна з служб виконує не відновлювані тривалі завдання, і тому потрібна перевірка стану вручну, щоб знайти вдалий момент, коли її можна буде вимкнути, тобто завдання було щойно закінчене.
Але сьогодні вранці я помітив, що простір звільнився за ніч. Мені здається, ніби якась очистка була, і це може бути те саме, що займає додатковий час при демонтажі.
Поки що я помітив таку поведінку лише при видаленні великої кількості даних. З іншого боку, я не впевнений, якщо це відбувається регулярно, і різниця просто занадто мала, щоб помітити.
Файлова система була створена з 0%, зарезервованим для root ( mkfs -m 0). Відповідно до fsck -f(я це роблю завжди між відключенням та повторним замовленням), файлова система не пошкоджена, і згідно з розширеним тестом діагностики SMART, апаратне забезпечення також у порядку.
[EDIT]
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
[/ EDIT]
Тож ось два мої питання:
- Що тут відбувається? Чому простір звільняється при кількості або із затримкою, а не відразу при видаленні?
- Чи є що - то я можу зробити , щоб викликати звільнення простору прямо зараз без від'єднання і перемонтажа?
lsof | grep -i deletedзазвичай це найкращий спосіб перевірити це.