On Mon, Jan 09, 2017 at 04:11:08PM +0100, Zdenek Kabelac wrote: > > You have the case were application will write to 'different' filesystem, > while in other cases user will be able to continue to use their filesystem > and cause irreparable filesystem damage (whatever you want to believe > is failure if thin-pool or filesystem). Huh? Where do you get this fantasy that ENOSPC causes "irreparable file system damage"? We have tests in xfstests that repeatedly hammer file systems ENOSPC handling --- the file system is filled so it is almost full, and then one thread is constantly creating and deleting files to keep the file system almost full, and then backing off, while another thread is trying to continuously allocate space, and retrying when it gets ENOSPC. If the file system gets "irreparably damanged", it's a file system bug. I can't remember the last time ext4 or xfs has had file system issues with this. Btrfs has in the past had issues here --- but this is a file system bug. It should be fixed, or no responsible system administrator should be using btrfs on that enterprise distribution until it is fixed, Docker or no Docker. - Ted P.S. And no responsible enterprise distro provider should be shipping btrfs if it is hasn't had all of the bug fixes so it doesn't corrupt the file system on ENOSPC. Since I believe Red Hat is a responsible enterprise distro provider, what's the problem? :-) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
