On Fri, 26.07.13 22:13, Miloslav Trmač (mitr@xxxxxxxx) wrote: > Hello all, > with thin provisioning available, the total and free space values > reported by a filesystem do not necessarily mean that that much space > is _actually_ available (the actual backing storage may be smaller, or > shared with other filesystems). > > If your package reports disk space usage to users, and bases this on > filesystem free space, please consider whether it might need to take > LVM thin provisioning into account. > > The same applies if your package automatically allocates a certain > proportion of the total or available space. > > A quick way to check whether your package is likely to be affected, is > to look for statfs() or statvfs() calls in C, or the equivalent in > your higher-level library / programming language. Well, I am pretty sure the burden must be on the file systems to report a useful estimate free blocks value in statfs()/statvfs(). Exporting that problem to userspace and expecting userspace to work around this is just wrong. In fact, this would be quite an API breakage if applications cannot rely that the value returned is at least a rough estimate on how much data can be stored on disk. journald will scale how much disk usage it will use of /var/log/journal based on the file system size and free level. It will also module the per-service rate limit levels based on the amount of free disk space. If you break the API of statfs()/statvfs(), then you will end up break this and all programs like it. Note that btrfs RAID is broken in a similar way: it will return the amount of actual free blocks to the user. Since if RAID is enabled each file however requires twice (or some other factor) the number of blocks the value is completely bogus. The btrfs RAID userspace API is simply broken. The accepted way to get an estimate how much disk space is still available is statfs()/statvfs(), applications and admins rely on the values it returns. You cannot just break that and think you can get away with it. The thin provisioning folks need to find a way to make this work, not userspace programmers. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
