Comment # 11 on bug 818373 from Libor Pechacek

Replicated with Tumbleweed 20161226, kernel 4.9.0-2-default.

Contemplating about the FS_IOC_SETFLAGS IOCTL behavior, the logic
ioctl.c:check_flags() looks ill to me. My thinking is that with FS_COMPR_FL I
am telling kernel that I am willing to accept performance hit on file read and
write operations in exchange for lower disk space consumption. It goes without
saying that I don't know how much space I save and the savings can be anywhere
between 0% to 99.9%. Therefore kernel pushing back against my request with
-EINVAL, in the 0% savings scenario, makes absolutely no sense to me.

It looks to me like the piece of code should be dropped.  Opinions?

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 33f967d30b2a..8c9c5aa445dc 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -206,9 +206,6 @@ static int check_flags(unsigned int flags)
               FS_NOCOW_FL))
         return -EOPNOTSUPP;

-    if ((flags & FS_NOCOMP_FL) && (flags & FS_COMPR_FL))
-        return -EINVAL;
-
     return 0;
 }