SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Boot from any encrypted partition (luks) 2. Change the used space in the partition (delete or create files so you notice) 3. Open org.kde.partitionmanager and check that does not reflect the actually used space. OBSERVED RESULT Space used/free etc. does not reflect real one. Looks like it's stuck with vales read either at first launch or system boot. EXPECTED RESULT Work fine like gparted. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.26.3 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 Kernel Version: 6.0.9-1-MANJARO (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION
Created attachment 153881 [details] Space free / used reported by kde partition manager
Created attachment 153882 [details] Real used space reported by gparted
after reboot display new size
Created attachment 153883 [details] After reboot new size is displayed
This sounds a bit strange. Have you rescanned the drives (F5) after free space changed. KDE Partition Manager does not report any live info, it reads it when you start KDE Partition Manager and caches all info until you refresh. For ext4, KDE Partition Manager runs "dumpe2fs -h deviceNode", looks at "Block count:", "Free blocks:" and "Block size:" and then free space is returned as (blockCount - freeBlocks) * blockSize. So encryption shouldn't matter at all. If this was not due to lack of refreshing, could you try rerunning your test where KDE Partition Manager does not update the value until reboot and compare it with (blockCount - freeBlocks) * blockSize.
Refresh doesn't work I already tried. Will report with dumpe2fs again as soon as possible.
Tried running dumpe2fs before and after creating a 3.5GB file, and the output is EXACTLY the same for both commands before and after, so there's a bug in dumpe2fs. Gparted updates however. That only changes after reboot. How can I report a bug then?
Tried with Arch linux and the issue is exactly the same, with dumpe2fs 1.46.5 (30-Dec-2021). No Free blocks/inodes update until reboot. How can I report this to developer?
(In reply to Teddy from comment #8) > Tried with Arch linux and the issue is exactly the same, with dumpe2fs > 1.46.5 (30-Dec-2021). No Free blocks/inodes update until reboot. > How can I report this to developer? https://e2fsprogs.sourceforge.net seems to suggest that Theodore Ts'o seems to be maintining it. Maybe email him and ask where to report the bug (at least I don't seem to notice any info about reporting bugs on that website).
Will try to reach him.
This is Theodore's comment: That's working as intended. Dumpe2fs is reading from the superblock on disk, and the Linux kernel is quite deliberately not updating most fields in the superblock until the file system is unmounted. There are a couple of reasons for this. The first is that frequent updates of the superblock is costly in terms of wasted I/O; it requires taking a random seek to update the superblock on disk, and that I/O operation and throughput is better used for real work. The second is that updating some of the fields is simply costly. It would require taking a global lock to update the fields, which reduces the file system's scalability across a large number of CPU cores. The ext2 and ext3 file system (before it was removed from the kernel; the ext4 kernel code now provides ext3 support) used to update the total free blocks and free inodes, and this turned out to be a major Scalability bottleneck. This is why we don't do it any more. :-) Yes, it means that a system administrator which tries to monitor free blocks usage using dumpe2fs won't be able to do it any more. But the proper, and more portable way of getting that information was to use the df command.
(In reply to Teddy from comment #11) > This is Theodore's comment: > > That's working as intended. Dumpe2fs is reading from the superblock > on disk, and the Linux kernel is quite deliberately not updating most > fields in the superblock until the file system is unmounted. > > There are a couple of reasons for this. The first is that frequent > updates of the superblock is costly in terms of wasted I/O; it > requires taking a random seek to update the superblock on disk, and > that I/O operation and throughput is better used for real work. > > The second is that updating some of the fields is simply costly. It > would require taking a global lock to update the fields, which reduces > the file system's scalability across a large number of CPU cores. The > ext2 and ext3 file system (before it was removed from the kernel; the > ext4 kernel code now provides ext3 support) used to update the total > free blocks and free inodes, and this turned out to be a major > Scalability bottleneck. This is why we don't do it any more. :-) > > Yes, it means that a system administrator which tries to monitor free > blocks usage using dumpe2fs won't be able to do it any more. But the > proper, and more portable way of getting that information was to use > the df command. Thanks, so it might make sense to switch to df...