All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.