All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: linux-btrfs@vger.kernel.org
Cc: Kai Krakow <hurikhan77+btrfs@gmail.com>
Subject: Re: btrfs mount flags
Date: Sat, 14 Apr 2012 00:05:08 +0200	[thread overview]
Message-ID: <201204140005.08619.Martin@lichtvoll.de> (raw)
In-Reply-To: <jjul59-m49.ln1@hurikhan.ath.cx>

Am Freitag, 13. April 2012 schrieb Kai Krakow:
> Hello!

Hi!

> Is there any documentation about btrfs mount flags wrt:
> 
> 1. which flags are one-time options and are permanent,
> 2. which flags are global per btrfs partition,
> 3. which flags are local per subvolume mount?
> 
> I'm asking because while googling I found very confusing info about
> autodefrag. Some say it is a global flag, others say to get autodefrag
> one has to supply it for each subvolume mount to have autodefrag for
> that subvolume.
> 
> Then there's space_cache which is a one-time option and does not need
> to be given on successive mounts. Otoh there's inode_cache which I
> would expect to be handled the same but it doesn't look like it's
> implemented that way.

I like the distinction in Ext3/Ext4. There are mount option and filesystem 
features that can be activated at mkfs time or (some) later with tune2fs.

Now I would expect a one time mount option to be a filesystem feature that 
I enabled with btrfstune or so. Cause I always understood mount options as 
temporary unless I write them into /etc/fstab. But then tune2fs / Ext also 
supports default mount options, so you could encode into the fs as well.

There even is a btrfstune command and it has a switch to enable something:

merkaba:~> btrfstune 
usage: btrfstune [options] device
        -S value        enable/disable seeding

but no manual page here. Seeding is mentioned at:

Seed Device support
It is now possible to create a filesystem to seed other Btrfs filesystems. 
The original filesystem and devices are included as a readonly starting 
point to the new FS. All modifications go onto different devices and the COW 
machinery makes sure the original is unchanged.

http://btrfs.ipv5.de/index.php?title=Changelog#Seed_Device_support


Anyway the documentation of mount options is on:

http://btrfs.ipv5.de/index.php?title=Mount_options

it seems.


There only for "space_cache" it is mentioned that it is permanent. Not for 
"inode_cache".

The mount manpage which usually has mount options of various filesystems 
does not mention BTRFS yet. I am not sure whether each filesystem should 
have an own manpage anyway.


Whatever is used, I would like to have a clear distinction between 
permanent and volatile settings. And I think a permanent option is 
something which should be set and queryable by a tuning command.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

      parent reply	other threads:[~2012-04-13 22:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-13 15:50 btrfs mount flags Kai Krakow
2012-04-13 17:42 ` Duncan
2012-04-14 15:17   ` Kai Krakow
2012-04-15  5:53     ` Duncan
2012-04-15 10:00       ` Martin Steigerwald
2012-04-16  3:20         ` Duncan
2012-04-13 22:05 ` Martin Steigerwald [this message]

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=201204140005.08619.Martin@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=hurikhan77+btrfs@gmail.com \
    --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.