Bug 1397569

Summary: wrong space needed calculation with ZFS
Product: [Fedora] Fedora Reporter: fulminemizzega
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: kardos.lubos, mluscon, mmraka, novyjindrich, packaging-team-maint, pknirsch, pmatilai, pnemade, rpm-software-management, vmukhame
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-29 11:09:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description fulminemizzega 2016-11-22 20:29:25 UTC
Description of problem:
I have a 18gb zfs dataset and a 15gb ext4 partition, mounted at /f25zfs and /mnt/ext4. Running "dnf --installroot=/f25zfs groupinstall 'Fedora Workstation'" leads to an error: "At least 949MB more space needed on the / filesystem."
Instead, if installroot=/mnt/ext4 everything works fine.

How reproducible:
Boot a fedora live iso, install zfs on linux, create a dataset (of about 18gb), create a zvol (of about 15gb). Format the zvol with ext4, then try to run dnf on the two different targets.

Steps to Reproduce:
0. Using a VM
1. Boot a f24 live cd (I changed rd.live.overlay.size on boot, see [1])
2. Install zfs [2]
3. #zpool create f25zfs /dev/sda2 (sda2 is a 19.5gb partition)
4. #for i in compression=lz4 acltype=posixacl xattr=sa atime=off;\
      do zfs set $i f25zfs; done
5. #dnf --installroot=/f25zfs groupinstall 'Fedora Workstation'
6. See it fail
7. #zfs create -V 15G f25zfs/ext4
8. #parted /dev/zd0, create gpt + a single ext4 partition from 0% to 100%
9. mkfs.ext4 /dev/zd0p1 and mount to /mnt/ext4
10. #dnf --installroot=/mnt/ext4 groupinstall 'Fedora Workstation'



Actual results:
The installation works fine in the ext4 partition, it fails in the zfs dataset.

Expected results:
dnf should work fine in both, given there actually is enough space, as in this case.

Additional info:
I used an updated fedora live image: http://dl.fedoraproject.org/pub/alt/live-respins/F24-x86_64-WORK-20161120.iso. Dnf version is 1.1.10-1, kernel is 4.8.8
[1] https://fedoraproject.org/wiki/LiveOS_image
[2] https://github.com/zfsonlinux/zfs/wiki/Fedora

Comment 1 Michael Mráka 2016-11-28 13:24:16 UTC
"At least 949MB more space needed on the / filesystem." is an error message coming from an rpm transaction.

Reassigning to rpm guys, maybe they have an idea why it differs on zfs vs. ext4.

Comment 2 Panu Matilainen 2016-11-28 13:34:16 UTC
What does 'stat -f /f25zfs' output?

Comment 3 fulminemizzega 2016-11-28 15:00:12 UTC
I can't stat that directly, I changed the dataset structure a bit... I still get the same error anyway, now the dataset where dnf puts everything is f25zfs/ROOT/default,
mounted to /mnt.

#stat -f /mnt
  File: "/mnt"
    ID: d1ecd6bc00301e25 Namelen: 255     Type: zfs
Block size: 131072     Fundamental block size: 131072
Blocks: Total: 154737     Free: 142457     Available: 142457
Inodes: Total: 36484651   Free: 36469042

This is my actual setup now:
#zfs list
NAME                  USED  AVAIL  REFER  MOUNTPOINT
f25zfs               1.50G  17.4G    19K  /mnt/f25zfs
f25zfs/ROOT          1.50G  17.4G    19K  none
f25zfs/ROOT/default  1.50G  17.4G  1.50G  /mnt
f25zfs/data            38K  17.4G    19K  none
f25zfs/data/home       19K  17.4G    19K  /mnt/home

I disabled auto-mounting for f25zfs, so right now it is not mounted to /mnt/f25zfs.

Comment 4 Panu Matilainen 2016-11-28 15:10:05 UTC
(In reply to fulminemizzega from comment #3)
>     ID: d1ecd6bc00301e25 Namelen: 255     Type: zfs
> Block size: 131072     Fundamental block size: 131072
> Blocks: Total: 154737     Free: 142457     Available: 142457

As I suspected, there's a large, bogus block size involved. This is essentially a dupe of bug 847960 - the bigger the (fake) block size the bigger the miscalculation by rpm.

Comment 5 Panu Matilainen 2016-11-28 15:18:50 UTC
Oh and BTW, you should be able to work around by changing the ZFS recordsize (which is not the same as block size but what fstat and rpm see) from the default 128k to eg 4k with something like:

# zfs set recordsize=4k <your-fs>

Comment 6 fulminemizzega 2016-11-28 15:38:03 UTC
wow... bug 847960 is ancient...
Thanks a lot, the work around works, just finished installing everything.
So... if rpm/dnf/yum don't work that well with zfs, what happens with docker and a zfs backstore?
Is this just the wrong distribution to try to run zfs on? Does this stuff affect even CentOS/RHEL?

Comment 7 Panu Matilainen 2016-11-29 05:32:41 UTC
Bug 847960 is not ancient, its not even old by rpm standards - the block-based disk space calculation in rpm is. So yes it will behave this way in every old rpm-based distro. With the exception of recent Suse perhaps, they have a patch to normalize strange block sizes to 4k, we'll probably adopt that upstream too. In the meanwhile you have a very simple workaround for zfs.

Comment 8 Panu Matilainen 2016-11-29 11:09:19 UTC

*** This bug has been marked as a duplicate of bug 847960 ***