Hide Forgot
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
"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.
What does 'stat -f /f25zfs' output?
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.
(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.
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>
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?
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.
*** This bug has been marked as a duplicate of bug 847960 ***