Re: trouble with generic/081

["Theodore Ts'o" <tytso@mit.edu>]

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?  :-)