Skip to contentSkip to conversation

Ideas to do custom operation just after mount?

DISCUSSION Qu Wenruo 5 participants 8 messages Dec 17, 2015 – Dec 23, 2015 Btrfs file system

lore
Share & tools
lore

Qu Wenruo

author
#0 lore raw

Hi,

Will xfstests provides some API to do some operation just after mounting a filesystem?

Some filesystem(OK, btrfs again) has some function(now qgroup only) which needed to be enabled by ioctl instead of mount option.

Currently, for btrfs qgroup we added special test case enabling qgroup and do test.
But there is only less than 10 qgroup test case and we didn't test most of the rest cases with qgroup enable.

Things will get even worse if we are adding inband-deduplication.

So is there any good idea to do some operation just after mounting in xfstests?

Thanks,
Qu

#1 lore raw
Quoted 7 lines · Qu Wenruo

Hi,

Will xfstests provides some API to do some operation just after mounting a filesystem?

Some filesystem(OK, btrfs again) has some function(now qgroup only) which needed to be enabled by ioctl instead of mount option.

Irk.

Seriously, I need ot find some time to split all the fs specific stuff in common/rc into separate files and have each different filesystem implement it's own version of the relevant functions like _scratch_mkfs, _scratch_mount, etc.

That will enable btrfs to do truly hideous stuff like this that admins will hate you for requiring, and the rest of us won't have to care about it.

Quoted 2 lines

So is there any good idea to do some operation just after mounting in xfstests?

You're just going to have to wait a bit - the first piece of this is in the overlayfs support patches, and the rest of it is in my local work area in an incomplete state.

Cheers,

Dave.

Signature · 2 lines
Dave Chinner
[email protected]
author
#2 lore raw

Dave Chinner wrote on 2015/12/21 11:16 +1100:

Quoted 20 lines · Qu Wenruo
Quoted 7 lines

Hi,

Will xfstests provides some API to do some operation just after mounting a filesystem?

Some filesystem(OK, btrfs again) has some function(now qgroup only) which needed to be enabled by ioctl instead of mount option.

Irk.

Seriously, I need ot find some time to split all the fs specific stuff in common/rc into separate files and have each different filesystem implement it's own version of the relevant functions like _scratch_mkfs, _scratch_mount, etc.

That will enable btrfs to do truly hideous stuff like this that admins will hate you for requiring, and the rest of us won't have to care about it.

Quoted 6 lines
Quoted 2 lines

So is there any good idea to do some operation just after mounting in xfstests?

You're just going to have to wait a bit - the first piece of this is in the overlayfs support patches, and the rest of it is in my local work area in an incomplete state.

Glad to hear that, I'll just wait for the formal implement.

Thanks,
Qu

Quoted 5 lines

Cheers,

Dave.

author
#3 lore raw

Qu Wenruo wrote on 2015/12/21 10:25 +0800:

Quoted 22 lines

Dave Chinner wrote on 2015/12/21 11:16 +1100:

Quoted 19 lines · Qu Wenruo
Quoted 7 lines

Hi,

Will xfstests provides some API to do some operation just after mounting a filesystem?

Some filesystem(OK, btrfs again) has some function(now qgroup only) which needed to be enabled by ioctl instead of mount option.

Irk.

Seriously, I need ot find some time to split all the fs specific stuff in common/rc into separate files and have each different filesystem implement it's own version of the relevant functions like _scratch_mkfs, _scratch_mount, etc.

That will enable btrfs to do truly hideous stuff like this that admins will hate you for requiring, and the rest of us won't have to care about it.

BTW, any good idea for btrfs to do such operation like enabling/disabling some minor features? Especially when it can be set on individual file/dirs.

Features like incoming write time deduplication, is designed to be enabled/disabled for individual file/dirs, so it's not a quite good idea to use mount option to do it.

Although some feature, like btrfs quota(qgroup), should be implemented by mount option though. I don't understand why qgroup is enabled/disabled by ioctl. :(

Thanks,
Qu

Quoted 24 lines
Quoted 7 lines
Quoted 3 lines

So is there any good idea to do some operation just after mounting in xfstests?

You're just going to have to wait a bit - the first piece of this is in the overlayfs support patches, and the rest of it is in my local work area in an incomplete state.

Glad to hear that, I'll just wait for the formal implement.

Thanks,
Qu

Quoted 5 lines

Cheers,

Dave.

--
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

#4 lore raw
Quoted 6 lines

BTW, any good idea for btrfs to do such operation like enabling/disabling some minor features? Especially when it can be set on individual file/dirs.

Quoted 7 lines

Features like incoming write time deduplication, is designed to be enabled/disabled for individual file/dirs, so it's not a quite good idea to use mount option to do it.

Although some feature, like btrfs quota(qgroup), should be implemented by mount option though.
I don't understand why qgroup is enabled/disabled by ioctl. :(

mount option won't persist across systems/computers unless remembered by human.

Thanks, Anand

#5 lore raw

Am Mon, 21 Dec 2015 13:18:22 +0800
schrieb Anand Jain <[email protected]>:

Quoted 10 lines
Quoted 10 lines

BTW, any good idea for btrfs to do such operation like enabling/disabling some minor features? Especially when it can be set on individual file/dirs.

Features like incoming write time deduplication, is designed to be enabled/disabled for individual file/dirs, so it's not a quite good idea to use mount option to do it.

Quoted 7 lines
Quoted 3 lines

Although some feature, like btrfs quota(qgroup), should be implemented by mount option though.
I don't understand why qgroup is enabled/disabled by ioctl. :(

mount option won't persist across systems/computers unless remembered by human.

Valid point, tho here's an counter-example: space-cache is persisted. Once enabled, it's always there until you clear AND disable it during initial mount.

Signature · 4 lines
Regards,
Kai

Replies to list-only preferred.
#6 lore raw

Kai Krakow posted on Tue, 22 Dec 2015 01:14:24 +0100 as excerpted:

Quoted 18 lines

Am Mon, 21 Dec 2015 13:18:22 +0800 schrieb Anand Jain <[email protected]>:

Quoted 14 lines
Quoted 12 lines

BTW, any good idea for btrfs to do such operation like enabling/disabling some minor features? Especially when it can be set on individual file/dirs.

Features like incoming write time deduplication, is designed to be enabled/disabled for individual file/dirs, so it's not a quite good idea to use mount option to do it.

Although some feature, like btrfs quota(qgroup), should be implemented by mount option though.
I don't understand why qgroup is enabled/disabled by ioctl. :(

Quoted 6 lines
Quoted 2 lines

mount option won't persist across systems/computers unless remembered by human.

Valid point, tho here's an counter-example: space-cache is persisted. Once enabled, it's always there until you clear AND disable it during initial mount.

Data point. space_cache doesn't have to be manually enabled at all, unless it was turned off at some point; it's automatically enabled on mounting new btrfs.

At least, I've never specifically enabled (or disabled) space_cache on any of my btrfs here, yet they all have it enabled.

(Years ago, with my first btrfs experiments, a corrupted space_cache could cause the filesystem not to mount. But then I left btrfs alone for awhile, and I guess in the mean time it learned to auto-correct such problems, as I've never had to worry about a bad space-cache failing a mount since I returned to using it, and that itself was two and a half years ago, now. With the previous mount-blocker experience I was a rather nervous when I saw it enabled without me initially enabling it, but space_cache has basically "just worked" for me since then, tho I've had a few other mount-blocking bugs.)

Signature · 3 lines
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman
#7 lore raw
In reply to Anand Jain
Quoted 10 lines · Anand Jain
Quoted 10 lines

BTW, any good idea for btrfs to do such operation like enabling/disabling some minor features? Especially when it can be set on individual file/dirs.

Features like incoming write time deduplication, is designed to be enabled/disabled for individual file/dirs, so it's not a quite good idea to use mount option to do it.

Quoted 7 lines
Quoted 3 lines

Although some feature, like btrfs quota(qgroup), should be implemented by mount option though.
I don't understand why qgroup is enabled/disabled by ioctl. :(

mount option won't persist across systems/computers unless remembered by human.

So record the mount option you want persistent in the filesystem at mount time and don't turn it off until a "no-...." mount option is provided at mount time.

Cheers,

Dave.

Signature · 2 lines
Dave Chinner
[email protected]