Kent Overstreet - 31.05.25, 01:16:04 CEST: > On Fri, May 30, 2025 at 11:19:32PM +0200, Martin Steigerwald wrote: > > Summary: I am curious why "ls -l" reports 16 EiB as the size of a > > directory entry. As to what I can see the filesystem is perfectly > > fine. > > > > Kernel 6.15, self compiled. 320 GiB BCacheFS on LUKS encrypted LVM. > > Checksums are xxhash. Filesystem was created recently on self compiled > > 6.15-rc7 with self-compiled bcachefs tools from git tag 1.25.2. > > "bcachefs" reports 1.25.1 as version number. > > > > I have a directory entry that according to ls -l is quite big: > > > > drwxrwxr-x 5 martin martin 18446744073709551400 DATE DIRECTORY > > Yes, this is due to a leftover from the directory i_size patchset that > had to be reverted. As long as it's not causing issues it'll be a bit > before I get to it, I've got higher priority bugs I'm working on right > now (as usual).
The filesystem is perfectly fine to as far as I can say. And I have no software in use on that filesystem that relies on any specific value or calculation there¹, so absolutely no hurry from my point of view. [1] I am not even sure whether it is save to assume anything for directory size in user space apps. "du" for example does not seem to take it into account – at least it does not pick up the 16 EiB –, not even with "--apparent-size". BTRFS shows some value there that appears to go up with the amount of directory entries. ext4 and XFS do as well, divisible through 4096. Best, -- Martin
