KDE Space Free

[behlendorf]

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.

[behlendorf]

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.

[behlendorf]

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.

[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.

Closed by 05ff35c602827a0f03659ec974c67b3fb5bf1c0b