http://bugzilla.opensuse.org/show_bug.cgi?id=818373 http://bugzilla.opensuse.org/show_bug.cgi?id=818373#c11 Libor Pechacek <lpechacek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium CC| |lpechacek@suse.com Component|Basesystem |Kernel Version|Final |Current Product|openSUSE 12.3 |openSUSE Tumbleweed Severity|Major |Minor --- Comment #11 from Libor Pechacek <lpechacek@suse.com> --- 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; } -- You are receiving this mail because: You are on the CC list for the bug.