On Sat, May 31, 2025 at 11:07:46AM +0200, Martin Steigerwald wrote: > 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.
Apparently this did break sshfs.
