Hello Eric, thank you for the quick reply and the explanations.> dumpe2fs -h output might show us that.Filesystem volume name: <none> Last mounted on: /opt/ssd Filesystem UUID: 75d6aae6-1746-4260-994b-148dfdb5af95 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: 29310976 Block count: 117212886 Reserved block count: 5860644 Free blocks: 115322570 Free inodes: 29310965 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 996 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 16 Filesystem created: Wed Apr 16 06:31:53 2014 Last mount time: Wed Apr 16 06:48:26 2014 Last write time: Wed Apr 16 06:48:26 2014 Mount count: 1 Maximum mount count: -1 Last checked: Wed Apr 16 06:31:53 2014 Check interval: 0 (<none>) Lifetime writes: 133 MB 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 First orphan inode: 8388637 Default directory hash: half_md4 Directory Hash Seed: a094608e-671f-4a9c-81e8-81bb72eb4516 Journal backup: inode blocks Journal features: journal_incompat_revoke Journal size: 128M Journal length: 32768 Journal sequence: 0x001d92ff Journal start: 27755> It could also be open but unlinked files, or unprocessed orphan inodes > after a crash. Have you run e2fsck?No, not yet. Shoud I do this routinely? Running sudo e2fsck -fn /dev/sdc gives as result: Warning! /dev/sdc is mounted. Warning: skipping journal recovery because doing a read-only filesystem check. Pass 1: Checking inodes, blocks, and sizes Deleted inode 8388637 has zero dtime. Fix? no Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: -(9255--9422) -(33793--33801) -(33808--33870) ... (really long list) Fix? no Free blocks count wrong (115322570, counted=14605339). Fix? no Inode bitmap differences: -8388637 Fix? no Free inodes count wrong (29310965, counted=29310750). Fix? no /dev/sdc: ********** WARNING: Filesystem still has errors ********** /dev/sdc: 11/29310976 files (272.7% non-contiguous), 1890316/117212886 blocks So I assume the best thing to do here would be to unmount the disk and do a e2fsck? Best regards, Roland
On 8/17/14, 2:05 PM, Roland Olbricht wrote:> Hello Eric, > > thank you for the quick reply and the explanations. > >> dumpe2fs -h output might show us that. > > Filesystem volume name: <none>...> Filesystem created: Wed Apr 16 06:31:53 2014 > Last mount time: Wed Apr 16 06:48:26 2014 > Last write time: Wed Apr 16 06:48:26 2014 > Mount count: 1 > Maximum mount count: -1 > Last checked: Wed Apr 16 06:31:53 2014 > Check interval: 0 (<none>) > Lifetime writes: 133 MB > 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 > First orphan inode: 8388637... Ok, pretty standard, and it appears that you mkfs'd it in april, mounted it, and have never unmounted it. (Nor has it ever crashed, apparently). Also, the last line above shows that there is at least one orphan inode, meaning it's open but unlinked. Blocks aren't freed until it's closed; that may be where all the space is.> >> It could also be open but unlinked files, or unprocessed orphan inodes >> after a crash. Have you run e2fsck? > > No, not yet. Shoud I do this routinely? Running > > sudo e2fsck -fn /dev/sdc > > gives as result: > > Warning! /dev/sdc is mounted. > Warning: skipping journal recovery because doing a read-only filesystem check.and so the rest isn't useful. You'd have to unmount it to check it. ...> So I assume the best thing to do here would be to unmount the disk and do a e2fsck?Probably so, or figure out who has that orphan inode open... if that process lets go, the space may free up; if it doesn't let go, you won't be able to unmount... -Eric
* Roland Olbricht <roland.olbricht@gmx.de> hat geschrieben: Hi Roland> Reserved block count: 5860644 > Block size: 4096Makes >20 GB. df doesn't show reserved clusters as free. That's why I always mke2fs -m 0 [...]. Tip: It's a tunable parameter, but as for e2fsck, you *really* should umount first. Also, not mentioned yet: Files big enough, that not all cluster pointers / extents fit in the inode itself, will take up additional meta data clusters. However, for ext2 with extents feature (which you have), this shouldn't really be much, I guess much much less than 1 GB. Regards, Bodo
Hello Eric,> Ok, pretty standard, and it appears that you mkfs'd it in april, > mounted it, and have never unmounted it. (Nor has it ever crashed, > apparently). > > Also, the last line above shows that there is at least one orphan > inode, meaning it's open but unlinked. Blocks aren't freed > until it's closed; that may be where all the space is.Thank you. That was indeed the cause of the problem. There was a single file that has been deleted some month ago, but the process which kept it open was still alive. I'll add a check for open deleted files to my checklist. Best regards, Roland