All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kirk Wolff <kirk@wolffelectronicdesign.com>
To: linux-btrfs@vger.kernel.org
Subject: Suggestion for sticky-compression mount setting (default mount options)
Date: Fri, 04 Feb 2011 20:44:03 -0600	[thread overview]
Message-ID: <1296873843.7800.36.camel@KWOLFF03> (raw)

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

As I've been using btrfs with an external USB drive, I wonder how to
handle efficiently the compression setting.  When I plug a drive in to
ubuntu, it is automatically mounted.  Its mounted without the
compression option as its not in fstab.  I don't see it as desirable to
install each usb drive in fstab on each computer that it may be used
just so that compression is automatically enabled.  In discussion with
cjb on irc, I came to realize that the compression setting shouldn't be
filesystem-wide therefore it doesn't make sense to have default mount
options for an entire btrfs filesystem as you may want compression on
one subvolume and not on another.  Therefore, it seems to me that
default mount options should be able to be configured for each
subvolume.  If you follow this idea through, this means that you would
need to be able to both override each of the default mount options from
the mount command (or fstab).  For example, if a subvolume has its
default mount option set to compress, you should be able to disable
compression if you manually mount it with "-o nocompress".  If mount
default mount options were able to be configured through btrfs for each
subvolume, then for the case when you have a simple USB drive that
you're using for backups, the default subvolume could have compress
automatically set when its plugged into a PC.  Then you can use
snapshots alongside the default subvolume to perform a type of
differential backups (similar to rsnapshot, but using COW instead of
hard links).  I can guess there are people out there that may want other
mount options to be carried around with the subvolume such as disabling
COW or whatever.  What are your thoughts on the above?  Please advise.

- Kirk

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

             reply	other threads:[~2011-02-05  2:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-05  2:44 Kirk Wolff [this message]
2011-02-05 12:18 ` Suggestion for sticky-compression mount setting (default mount options) Felix Blanke
2011-02-05 15:31   ` cwillu
2011-02-05 13:19 ` Olaf van der Spek

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=1296873843.7800.36.camel@KWOLFF03 \
    --to=kirk@wolffelectronicdesign.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.