From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: mount options ignored / unclear
Date: Sat, 12 Apr 2014 04:42:29 +0000 (UTC) [thread overview]
Message-ID: <pan$726e3$4cc96c8$4136f98$23771afe@cox.net> (raw)
In-Reply-To: 1988570.7Waz7R0erI@zafu
Swâmi Petaramesh posted on Fri, 11 Apr 2014 11:21:55 +0200 as excerpted:
> It is extremely unclear which BTRFS mount options are "filesystem wide"
> and will apply to each and every mountpoint in the BTRFS filesystem, and
> which options can be set per subvolume or per mountpoint.
>
> As far as I can tell, there is no reliable documentation about this, is
> there any ?
In general, btrfs doesn't _yet_ have the runtime infrastructure to handle
per-subvolume mount options. The on-device format and general approach
in the kernel was designed to allow it, and it's on the roadmap, it just
hasn't been done... yet.
So at this time, assume all options apply to the entire filesystem
including all subvolumes unless you know and can demonstrate otherwise.
If you will take a look back at my posts related to nocow files, while I
suggested a separate subvolume for those files in ordered to prevent
snapshotting them with the rest of the filesystem, I specifically did
*NOT* suggest using the nodatacow mount-option on that subvolume even tho
I knew about it, instead suggesting either still using the nocow file
attribute, or putting those file on an entirely separate partition, which
could then be other than btrfs if desired, precisely because AFAIK the
nodatacow option cannot apply to a single subvolume yet, and for the most
part, if one's going to use it on the entire filesystem, one might as
well use some other filesystem instead of btrfs, since without cow and
checksumming and snapshotting, there's little left to recommend btrfs
above a more stable filesystem such as ext3/4 or xfs. Once the per-
subvolume mount-options work as is planned, simply mounting that
dedicated subvolume nodatacow will be what I'll recommend, while keeping
standard cow for the main filesystem, but AFAIK that doesn't work yet, so
I can't recommend it yet.
--
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:[~2014-04-12 4:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-11 9:21 mount options ignored / unclear Swâmi Petaramesh
2014-04-12 4:42 ` Duncan [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-04-12 20:05 Chris Murphy
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$726e3$4cc96c8$4136f98$23771afe@cox.net' \
--to=1i5t5.duncan@cox.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).