Re: Debian 8.1 ext4 directory sizes
On Tue 10 Nov 2015 at 16:08:21 (+0100), Thomas Schmitt wrote:
> i am riddling about the size of directories in Jessie's ext4,
> as listed with ls -ld. They always grow and never shrink, even
> if they become completely empty. My record holder had 7.5 MB,
> currently i am having an empy one of 1.5 MB.
I think we've been here before; starts at
https://lists.debian.org/debian-user/2015/04/msg00651.html
> Processing times of programs which interpret the directory
> content are very long, as if the directories would contain
> tenthousands of files (which they probably once did).
> My extreme specimen all have the job to buffer large numbers
> of files until they get processed and deleted.
Perhaps ~125,000 files.
> Is this a known property of ext4 directories ?
>
> If so: Are there other means to shrink them except rmdir ?
>
> I read about a hash tree in
> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries
> but this text does not say that such a tree cannot shrink.
> Does anybody know how to inquire inode properties like
> EXT4_INDEX_FL ?
"Existing filesystems can have checksumming added by running
tune2fs -O metadata_csum against the underlying device. If
tune2fs encounters directory blocks that lack sufficient empty
space to add a checksum, it will request that you run e2fsck -D
to have the directories rebuilt with checksums. This has the
added benefit of removing slack space from the directory files
and rebalancing the htree indexes. If you _ignore_ this step,
your directories will not be protected by a checksum!"
This implies that rebalancing is not routine. My understanding
(not much) is that rebalancing carries a performance penalty.
Is it worth it for "normal" usage? Alternatively, when do you
want to take the hit? Or is it better to think about the way
in which you're caching these files?
Cheers,
David.
Reply to: