Skip to contentSkip to conversation

btrfs: fix default compression value when set by SETFLAGS ioctl

PATCH In review David Sterba 3 participants 3 messages Oct 31, 2017 – Nov 1, 2017 Btrfs file system

lore
Share & tools
lore

David Sterba

author maintainer
#0 lore raw

PATCH 1/1 btrfs: fix default compression value when set by SETFLAGS ioctl

The current default for the compression file flag is 'zlib', the zstd patch silently changed that to zstd. Though the choice of zlib might not be the best one, we should keep the backward compatibility.

The incompat bit for zstd is not set, so this could lead to a filesystem with a zstd compression in the extents but no flag for the filesystem.

Fixes 5c1aab1dd5445ed8bd ("btrfs: Add zstd support")
CC Nick Terrell <[email protected]>
---
 fs/btrfs/ioctl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
fs/btrfs/ioctl.c +3 -3
index fd172a93d11a..0ce9a895931a 100644
@@ -309,10 +309,10 @@ static int btrfs_ioctl_setflags(struct file *file, void __user *arg)
 
 		if (fs_info->compress_type == BTRFS_COMPRESS_LZO)
 			comp = "lzo";
-		else if (fs_info->compress_type == BTRFS_COMPRESS_ZLIB)
-			comp = "zlib";
-		else
+		else if (fs_info->compress_type == BTRFS_COMPRESS_ZSTD)
 			comp = "zstd";
+		else
+			comp = "zlib";
 		ret = btrfs_set_prop(inode, "btrfs.compression",
 				     comp, strlen(comp), 0);
 		if (ret)
Signature · 1 line
2.14.0
Tested-by on v1 1/1
#1 lore raw
Quoted 3 lines · David Sterba

The current default for the compression file flag is 'zlib', the zstd patch silently changed that to zstd. Though the choice of zlib might not be the best one, we should keep the backward compatibility.

Sorry about that, I didn't intentionally change it. I checked over my patch, and the only other place where an "else" was changed is the other place in ioctl.c, which looks okay to me.

I'm trying to expose the buggy case in 4.14-rc7. However, since fs_info->compress_type defaults to ZLIB when -compress is not passed, and when -compress=no is passed, fs_info->compress_type is not modified, I don't know how to get fs_info->compress_type to be BTRFS_COMPRESS_NONE. Is there a way that fs_info->compress_type can be BTRFS_COMPRESS_NONE?

I modified -compress=no to set fs_info->compress_type=BTRFS_COMPRESS_NONE and the ioctl() call set the compression type to zstd before your patch, and zlib after, as expected.

Quoted 6 lines

The incompat bit for zstd is not set, so this could lead to a filesystem with a zstd compression in the extents but no flag for the filesystem.

Fixes 5c1aab1dd5445ed8bd ("btrfs: Add zstd support")
CC Nick Terrell <[email protected]>

���{.n�+�������+%�����ݶ��w��{.n�+����{���k~���^n�r���z���h����&���z��z�ޗ�+��+zf���h���~����i��������z_��j:+v���)ߣ�m

#2 lore raw
Quoted 9 lines · Nick Terrell
Quoted 3 lines · David Sterba

The current default for the compression file flag is 'zlib', the zstd patch silently changed that to zstd. Though the choice of zlib might not be the best one, we should keep the backward compatibility.

Sorry about that, I didn't intentionally change it. I checked over my patch, and the only other place where an "else" was changed is the other place in ioctl.c, which looks okay to me.

Quoted 5 lines

I'm trying to expose the buggy case in 4.14-rc7. However, since fs_info->compress_type defaults to ZLIB when -compress is not passed, and when -compress=no is passed, fs_info->compress_type is not modified, I don't know how to get fs_info->compress_type to be BTRFS_COMPRESS_NONE. Is there a way that fs_info->compress_type can be BTRFS_COMPRESS_NONE?

And it turns out that this is not possible, fs_info::compress_type will always be one of lzo/zlib/zstd. This is zlib by default, so any chattr +c will set zlib. In order to set zstd by chattr, there would have to be at least one mount with zstd or defrag -czstd. And this will set the incompat bit.

Quoted 3 lines

I modified -compress=no to set fs_info->compress_type=BTRFS_COMPRESS_NONE and the ioctl() call set the compression type to zstd before your patch, and zlib after, as expected.

I must have assumed that mounting with -o compress=no will reset the compress_type. So unless I missed something else, the default will not change and the feature flags match the actual filesystem state. False alert, sorry. At least I don't have to send a late pull request.