Btrfs: add ioctl to set compress or cow per file/dir

Data compression and data cow are controlled across the entire FS by mount options right now. ioctls are needed to set this on a per file or per directory basis. This has been proposed previously, but VFS developers wanted us to use generic ioctls rather than btrfs-specific ones.

We need to fit these into the existing per-inode flags, and to use the generic FS_IOCTL_SETFLAGS ioctl. For data compression, there are the existing compression flags of vfs inode, while for datacow, there is no flag to indicate it, which we need to add.
So, what we will do is to add datacow flag in vfs inode flags and then to set or to unset btrfs compress/cow flag on the corresponding btrfs inode's flag per file or per directory. Moreover, we also add a compression type ioctl to make this feature more flexible.

I really expect some advices and comments on the followings:

- In this patch, I made a special ioctl to set compress type, and to record the compress_type per inode on disk, I've consumed some reserved space of btrfs_inode_item, so is this acceptable?

Meanwhile, I got another idea from my collegue, could we just owe the whole compress type thing to new proper mount options, ie,
mount xxx xxx -o compress=a,inode_compress=b?
Seems that this makes mount more flexible.

- When we are inclined to set inode's compression type, should it be a "force" mode?
This is much like the difference between mount as compress and mount as compress-force.

- For directory basis, after compress/cow ioctl on it, any files that are created or renamed in it, or moved into it, will inherit the directory's compress and datacow attribute.
Here comes to some disputes, is it right that renamed and moved files also inherit the father directory's compress & datacow attribute? And if what we are dealing with is directory, should this behaviour be recursive or not?
I'm inclined to leave these recursive things to btrfs-progs if this is necessary.

Excerpts from liubo's message of 2011-02-24 04:40:55 -0500:

Quoted 14 lines

Data compression and data cow are controlled across the entire FS by mount options right now. ioctls are needed to set this on a per file or per directory basis. This has been proposed previously, but VFS developers wanted us to use generic ioctls rather than btrfs-specific ones.

We need to fit these into the existing per-inode flags, and to use the generic FS_IOCTL_SETFLAGS ioctl. For data compression, there are the existing compression flags of vfs inode, while for datacow, there is no flag to indicate it, which we need to add.
So, what we will do is to add datacow flag in vfs inode flags and then to set or to unset btrfs compress/cow flag on the corresponding btrfs inode's flag per file or per directory. Moreover, we also add a compression type ioctl to make this feature more flexible.

Quoted 5 lines

I really expect some advices and comments on the followings:

- In this patch, I made a special ioctl to set compress type, and to record the compress_type per inode on disk, I've consumed some reserved space of btrfs_inode_item, so is this acceptable?

I don't expect people to mix compression types on the disk. There really should just be one true compression method (probably LZO once it has been established for a while). So, I'd prefer that we store this in the super, and just have flags in the inode for enabling or disabling compression.

Quoted 5 lines

Meanwhile, I got another idea from my collegue, could we just owe the whole compress type thing to new proper mount options, ie,
mount xxx xxx -o compress=a,inode_compress=b?
Seems that this makes mount more flexible.

It does make it more flexible, but I think sometimes extra flexibility leads to more QA time and isn't often used by the actual users ;)

Quoted 5 lines

- When we are inclined to set inode's compression type, should it be a "force" mode?
This is much like the difference between mount as compress and mount as compress-force.

I'd store this as flags in the super too.

Quoted 10 lines

- For directory basis, after compress/cow ioctl on it, any files that are created or renamed in it, or moved into it, will inherit the directory's compress and datacow attribute.
Here comes to some disputes, is it right that renamed and moved files also inherit the father directory's compress & datacow attribute? And if what we are dealing with is directory, should this behaviour be recursive or not?
I'm inclined to leave these recursive things to btrfs-progs if this is necessary.

I'd say that if we rename a file into a directory it does inherit, but not make it recursive.

-chris

include/linux/fs.h struct inodes_stat_t { · line 358

Quoted 4 lines

#define FS_DIRECTIO_FL 0x00100000 /* Use direct i/o */

include/linux/fs.h +2 -0

+#define FS_NOCOW_FL            0x00200000 /* Do not cow file */
+#define FS_COW_FL            0x00100000 /* Cow file */
 #define FS_RESERVED_FL            0x80000000 /* reserved for ext2 lib */

I'm assuming that FS_COW_FL should not be the same as FS_DIRECTIO_FL?

Excerpts from Andreas Dilger's message of 2011-02-24 13:37:52 -0500:

Quoted 6 lines · liubo

include/linux/fs.h struct inodes_stat_t { · line 358

Quoted 4 lines

#define FS_DIRECTIO_FL 0x00100000 /* Use direct i/o */

include/linux/fs.h +2 -0

+#define FS_NOCOW_FL            0x00200000 /* Do not cow file */
+#define FS_COW_FL            0x00100000 /* Cow file */
 #define FS_RESERVED_FL            0x80000000 /* reserved for ext2 lib */

I'm assuming that FS_COW_FL should not be the same as FS_DIRECTIO_FL?

No, we can do DIRECTIO with COW.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html