Ideas to do custom operation just after mount?

Ideas to do custom operation just after mount?

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

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

Ideas to do custom operation just after mount?

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

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

Re: Ideas to do custom operation just after mount?

[Dave Chinner]

On Thu, Dec 17, 2015 at 09:55:14AM +0800, Qu Wenruo wrote:
> 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.

> 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.
-- 
Dave Chinner
david@fromorbit.com

Re: Ideas to do custom operation just after mount?

[Qu Wenruo]

Dave Chinner wrote on 2015/12/21 11:16 +1100:
> On Thu, Dec 17, 2015 at 09:55:14AM +0800, Qu Wenruo wrote:
>> 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.
>
>> 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

>
> Cheers,
>
> Dave.
>

Re: Ideas to do custom operation just after mount?

[Qu Wenruo]

Dave Chinner wrote on 2015/12/21 11:16 +1100:
> On Thu, Dec 17, 2015 at 09:55:14AM +0800, Qu Wenruo wrote:
>> 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.
>
>> 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

>
> Cheers,
>
> Dave.
>

Re: Ideas to do custom operation just after mount?

[Qu Wenruo]

Qu Wenruo wrote on 2015/12/21 10:25 +0800:
>
>
> Dave Chinner wrote on 2015/12/21 11:16 +1100:
>> On Thu, Dec 17, 2015 at 09:55:14AM +0800, Qu Wenruo wrote:
>>> 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

>>
>>> 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
>
>>
>> Cheers,
>>
>> Dave.
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ideas to do custom operation just after mount?

[Qu Wenruo]

Qu Wenruo wrote on 2015/12/21 10:25 +0800:
>
>
> Dave Chinner wrote on 2015/12/21 11:16 +1100:
>> On Thu, Dec 17, 2015 at 09:55:14AM +0800, Qu Wenruo wrote:
>>> 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

>>
>>> 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
>
>>
>> Cheers,
>>
>> Dave.
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ideas to do custom operation just after mount?

[Anand Jain]

> 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. :(


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


Thanks, Anand

Re: Ideas to do custom operation just after mount?

[Kai Krakow]

Am Mon, 21 Dec 2015 13:18:22 +0800
schrieb Anand Jain <anand.jain@oracle.com>:

> 
> 
> > 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. :(
> 
> 
> 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.

-- 
Regards,
Kai

Replies to list-only preferred.

Re: Ideas to do custom operation just after mount?

[Kai Krakow]

Am Mon, 21 Dec 2015 13:18:22 +0800
schrieb Anand Jain <anand.jain@oracle.com>:

> 
> 
> > 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. :(
> 
> 
> 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.

-- 
Regards,
Kai

Replies to list-only preferred.

Re: Ideas to do custom operation just after mount?

[Duncan]

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

> Am Mon, 21 Dec 2015 13:18:22 +0800 schrieb Anand Jain
> <anand.jain@oracle.com>:
> 
> 
>> 
>> > 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. :(
>> 
>> 
>> 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.)

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

Re: Ideas to do custom operation just after mount?

[Dave Chinner]

On Mon, Dec 21, 2015 at 01:18:22PM +0800, Anand Jain wrote:
> 
> 
> >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. :(
> 
> 
> 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.
-- 
Dave Chinner
david@fromorbit.com