Skip to content
This repository

KDE Space Free #112

Closed
behlendorf opened this Issue · 5 comments

2 participants

Brian Behlendorf devsk
Brian Behlendorf
Owner

Devsk is reporting that when using ZFS as the root filesystem that KDE reports there being much less free space than there really is. We need to look in to how KDE is calculating free space in the filesystem and adjust ZFS to accommidate it.

devsk

Here is the relevant code from KDE:

./kio/kfile/kdiskfreespaceinfo.cpp:    struct statvfs statvfs_buf;
./kio/kfile/kdiskfreespaceinfo.cpp:    if (!statvfs(QFile::encodeName(pathArg).constData(), &statvfs_buf)) {
./kio/kfile/kdiskfreespaceinfo.cpp:        const quint64 blksize = quint64(statvfs_buf.f_frsize); // cast to avoid overflow
./kio/kfile/kdiskfreespaceinfo.cpp:        info.d->available = statvfs_buf.f_bavail * blksize;
./kio/kfile/kdiskfreespaceinfo.cpp:        info.d->size = statvfs_buf.f_blocks * blksize;

Is the following field being provided correctly for ZFS:

fsblkcnt_t   f_bavail;  /* free blocks available to
                                      unprivileged user */

I think this probably should be same as f_bfree for ZFS because there is no concept of reservation for 'root' or 'admin' user.

Brian Behlendorf
Owner

Thanks for looking this up. So the matching code on the ZFS side is located in zfs_statvfs(). The problem looks to be that KDE is using f_frsize() which is defined to be the fragment size (512b) instead of f_bsize (128k) which is the block size. It's then multiplied by the number of blocks.

This isn't really the right usage but the API is confusing and inconsistent at best. It's probably best for us just to adjust how ZFS reports these values. We can either increase the fragment size to 128k, or drop the block size to 512 bytes. I'd like to try increasing the fragment size first, if you've got a minute please try this change to zfs_statvfs().

-   statp->f_frsize = 1UL << SPA_MINBLOCKSHIFT;
+   statp->f_frsize = zsb->z_max_blksz;
devsk

Brian, Can u please bundle this change with the patch you will have for the showstopper issue? I will try them both together.

Brian Behlendorf
Owner

Absolutely, so far I think I understand almost all of the issues which have been opened so I'll work to resolve as many of them as I can next week. Then I'll target an -rc2 candidate once we've gotten the first crop issues out of the way.

Brian Behlendorf
Owner

Increase fragment size to block size

The underlying storage pool actually uses multiple block
size. Under Solaris frsize (fragment size) is reported as
the smallest block size we support, and bsize (block size)
as the filesystem's maximum block size. Unfortunately,
under Linux the fragment size and block size are often used
interchangeably. Thus we are forced to report both of them
as the filesystem's maximum block size.

Closed by 05ff35c

Brian Behlendorf behlendorf referenced this issue from a commit in chaos/zfs
Brian Behlendorf behlendorf Increase fragment size to block size
The underlying storage pool actually uses multiple block
size.  Under Solaris frsize (fragment size) is reported as
the smallest block size we support, and bsize (block size)
as the filesystem's maximum block size.  Unfortunately,
under Linux the fragment size and block size are often used
interchangeably.  Thus we are forced to report both of them
as the filesystem's maximum block size.

Closes #112
05ff35c
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.