On Fri, Jun 26, 2020 at 11:30 AM Chris Adams <linux@xxxxxxxxxxx> wrote: > > Once upon a time, Ben Cotton <bcotton@xxxxxxxxxx> said: > > For laptop and workstation installs of Fedora, we want to provide file > > system features to users in a transparent fashion. We want to add new > > features, while reducing the amount of expertise needed to deal with > > situations like [https://pagure.io/fedora-workstation/issue/152 > > running out of disk space.] Btrfs is well adapted to this role by > > design philosophy, let's make it the default. > > So... I freely admit I have not looked closely at btrfs in some time, so > I could be out of date (and my apologies if so). One issue that I have > seen mentioned as an issue within the last week is still the problem of > running out of space when it still looks like there's space free. I > didn't read the responses, so not sure of the resolution, but I remember > that being a "thing" with btrfs. Is that still the case? What are the > causes, and if so, how can we keep from getting a lot of the same > question on mailing lists/forums/etc.? There's different kinds of enospc. Most have been bugs that are long since fixed (practically the entire enospc infrastructure was rewritten circa 2016, which itself then exposed some prior fixes that became new bugs). But like any bug we'd need to see more info: kernel version and the conditions. That's just sorta how a bug hunt goes, and they're all tedious. I haven't experienced enospc on btrfs in years. I also do not do any special incantations or scheduled maintenance to avoid it. I just use the file system normally, and if I were to hit enospc I'd collect a bunch of info and file a good bug report. And I know some folks aren't into that, and that's fine. Those I've seen elsewhere, the typical manifestation is it's a one off transient enospc and you try again and things are fine. The file system stays read-write, and there is no other side effect. Since Btrfs is copy-on-write it takes free space to delete files. A file deletion *consumes* free space in the form of metadata being read, modified to indicate the delete, and then written. Only after that succeeds is space freed up as a result of the delete. I have a few file systems I intentionally keep around at 99% full just because I'm a file system saboteur but also if I hit enospc, it's still a bug. I'm still gonna report it. I'm not going to make excuses like "oh it's 99% full, no wonder!" We'll probably hit some enospc edge cases somewhere in Fedora. It does even happen on ext4 and xfs sometimes, though less common because they don't need free space to update metadata. My inclination is always to not fix problems, collect data, and report them. So it's a valid question to say "no thanks, what is the incantation to fix it, please? i have work to do, not bug reports" should you run into it. And yes there are those things, and they can be done online without repairs or reboots. > I remember when btrfs was going to be the > one FS to rule them all, but then had issues, and specific weird cases > (like with VM images IIRC at one point), nodatacow on VM images, whether raw or qcow2 is still recommended. This can be done with 'chattr +C' on either the file while still zero length or on the directory and then it's inherited (for new files as created or copied). So the details of how to do this, who does it, is very much on-topic and a question. Should the installer set +C on /var/lib/libvir/timages? Or should libvirtd? What happens if you don't? Well depending on the guest, the image can get pretty fragmented. Curiously the *least* problematic combination is btrfs guest on raw on btrfs. And the worst is NTFS guest on qcow2 on btrfs (in a week, 51000+ extents for that one file). I can't say I notice the performance hit anecdotally but would a benchmark prove it's slower? Maybe, probably. That's a lot of extent tracking and it's only one week of aging. Technically it's in the category of a recommended optimization. The community can escalate this and say, it's a must have. Same for the compression option in the proposal. Same for anything really, it's a discussion. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
