Wczoraj usunąłem 71 GB plików na moim serwerze domowym / medialnym.
Wolne miejsce przed: 117 GB
Wolna przestrzeń po: 126 GB
Więc zamiast 71 GB dodatkowego wolnego miejsca miałem tylko 9 GB. Sprawdziłem dwukrotnie, czy nie ma otwartych plików i naprawdę usunąłem 71 GB, a wolne miejsce naprawdę zwiększyło się tylko o 9 GB.
Próbowałem również zsynchronizować, ale bez efektu.
To nie pierwszy raz. Rzeczywiście, widziałem to zachowanie od lat co jakiś czas. Najpierw na ext3, teraz na ext4.
Gdy tak się stanie, mogę odzyskać wolne miejsce, odmontowując, a następnie ponownie instalując system plików. W takich przypadkach odmontowanie trwa do 2 minut, a nie prawie wcale.
Obecnie nie mogę łatwo odmontować i ponownie zainstalować systemu plików, ponieważ jest on stale zajęty przez moje oprogramowanie rejestratora wideo, serwer owncloud dla mojej rodziny i kilka innych usług, których dotychczas nie miałem. I nie chcę wstawać o trzeciej w nocy tylko po to, by odmontować i ponownie zamontować.
Nie, narzędzie „at” nie zadziała, ponieważ jedna z usług wykonuje długie zadania, które nie są w stanie wznowić, a zatem wymaga ręcznego sprawdzenia stanu, aby znaleźć dobry moment, kiedy można go wyłączyć, tj. Zadanie zostało właśnie zakończone.
Ale dziś rano zauważyłem, że przestrzeń została uwolniona z dnia na dzień. Wygląda na to, że nastąpiło jakieś oczyszczanie, a to może być to samo, co zajmuje dodatkowy czas podczas odmontowywania.
Do tej pory zauważyłem to zachowanie tylko podczas usuwania dużej ilości danych. Z drugiej strony nie jestem pewien, czy zdarza się to regularnie, a różnica jest zbyt mała, aby to zauważyć.
System plików został utworzony z 0% zarezerwowanym dla roota ( mkfs -m 0 ). Według fsck -f (Robię to zawsze między odmontowaniem i ponownym zainstalowaniem), system plików nie jest uszkodzony i zgodnie z S.M.A.R.T. rozszerzony test diagnostyczny, sprzęt jest również OK.
[EDYTOWAĆ]
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
[/EDYTOWAĆ]
Oto moje 2 pytania:
- Co tu się dzieje? Dlaczego miejsce jest zwolnione na umount lub z opóźnieniem zamiast natychmiastowego usunięcia?
- Czy jest coś, co mogę zrobić, aby zwolnić przestrzeń teraz bez demontażu i ponownego montażu?
lsof | grep -i deletedjest zazwyczaj najlepszym sposobem, aby to sprawdzić.