From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Cc: fstests@vger.kernel.org
Subject: Re: Ideas to do custom operation just after mount?
Date: Tue, 22 Dec 2015 09:28:15 +0000 (UTC) [thread overview]
Message-ID: <pan$a07c5$8ea63042$e035dc2a$bbe2f2c1@cox.net> (raw)
In-Reply-To: 20151222011424.03247982@jupiter.sol.kaishome.de
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
next prev parent reply other threads:[~2015-12-22 9:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-17 1:55 Ideas to do custom operation just after mount? Qu Wenruo
2015-12-17 1:55 ` Qu Wenruo
2015-12-21 0:16 ` Dave Chinner
2015-12-21 2:25 ` Qu Wenruo
2015-12-21 2:25 ` Qu Wenruo
2015-12-21 2:38 ` Qu Wenruo
2015-12-21 2:38 ` Qu Wenruo
2015-12-21 5:18 ` Anand Jain
2015-12-22 0:14 ` Kai Krakow
2015-12-22 0:14 ` Kai Krakow
2015-12-22 9:28 ` Duncan [this message]
2015-12-23 23:17 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$a07c5$8ea63042$e035dc2a$bbe2f2c1@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.