I think I captured the crux of this pretty well. If anybody suggests that there could be value to exposing any information related to the nature of the "thinly provisioned block devices", you suggest that the only route forwards here is BTRFS and ZFS. You are saying directly and indirectly, that anybody who disagrees with you should switch to what you feel are the only solutions that are in this space, and that LVM should never be in this space.

I think I understand your perspective. However, I don't agree with it. I don't agree that the best solution is one that fails at the last instant with ENOSPC and/or for the file system to become read-only. I think there is a whole lot of grey possibilities between the polar extremes of "BTRFS/ZFS" vs "thin+XFS/ext4 with last instant failure".

What started me on this list was the CYA mandatory warning about over provisioning that I think is inappropriate, and causing us tooling problems. But seeing the debate unfold, and having seen some related failures in the Docker LVM thin pool case where the system may completely lock up, I have a conclusion that this type of failure represents a fundamental difference in opinion around what thin volumes are for, and what place they have. As I see them as highly valuable for various reasons including Docker image layers (something Red Hat appears to agree with, having targeted LVM thinp instead of the union file systems), and the snapshot use cases I presented prior, I think there must be a way to avoid the worst scenarios, if the right people consider all the options, and don't write off options prematurely due to preconceived notions about what is and what is not appropriate in terms of communication of information between system layers.

There are many types of information that *are* passed from the block device layer to the file system layer. I don't see why awareness of thin volumes, should not be one of them.

For example, and I'm not pretending this is the best idea that should be implemented, but just to see where the discussion might lead:

The Linux kernel needs to deal with problems such as memory being swapped out due to memory pressures. In various cases, it is dangerous to swap memory out. The memory can be protected from being swapped out where required using various technique such as pinning pages. This takes up extra RAM, but ensures that the memory can be safely accessed and written as required. If the file system has particular areas of importance that need to be writable to prevent file system failure, perhaps the file system should have a way of communicating this to the volume layer. The naive approach here might be to preallocate these critical blocks before proceeding with any updates to these blocks, such that the failure situations can all be "safe" situations, where ENOSPC can be returned without a danger of the file system locking up or going read-only.

Or, maybe I am out of my depth, and this is crazy talk... :-)

(Personally, I'm not really needing a "df" to approximate available storage... I just don't want the system to fail badly in the "out of disk space" scenario... I can't speak for others, though... I do *not* want BTRFS/ZFS... I just want a sanely behaving LVM + XFS...)

--