linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Setting options permanently?
Date: Sat, 28 Jan 2012 10:55:21 +0000 (UTC)	[thread overview]
Message-ID: <pan.2012.01.28.10.55.21@cox.net> (raw)
In-Reply-To: 20120128142344.6f18c989@natsu

Roman Mamedov posted on Sat, 28 Jan 2012 14:23:44 +0600 as excerpted:

> On Sat, 28 Jan 2012 17:05:41 +1100 Ben Klein <shacklein@gmail.com>
> wrote:
> 
>> If the compression routine changes in a later kernel/filesystem
>> revision,
> 
> There are already two different algorithms, zlib and lzo, and a third
> one - snappy - planned for inclusion.
> 
>> then you could end up with some files using one routine and others
>> using another.
> 
> Which is absolutely not a problem even right now.

Reading them isn't a problem, sure, but the thread indicates a desire to 
set the write-compression characteristics.

But that's why I specifically mentioned more than just a compression 
flag.  Presumably it'd be several bits (four bits, 16 values, would leave 
enough room for additional compression types in the future, tho three or 
even two would do it with the current three choices plus uncompressed), 
with one value indicating a no-compression default, and the others 
various choices as the default.  The mount option could then be used to 
override the default, just as it is now, altho the only choice for 
default currently is no compression.

Actually, given that btrfs is in line to be the successor to the ext* 
series, I'd say it should be close to a given that many mount options 
will have settable defaults recorded in the superblocks at mkfs time, and 
updatable using some btrfs parallel to tune2fs (tunebtrfs? tunebfs?).  
However, as I said earlier, committing to specifics with incremental on-
disk including superblock format changes doesn't really cut it.  If a big 
format change is needed due to continuing development, so it can be 
tested and gotchas worked out, yeah, do it now, and hopefully there's 
some space in the superblock(s) reserved for more trivial stuff like 
mount-option defaults already, but especially for mount options since 
they can be tested without committing to the superblock spec changes 
necessary to nail it down there, just testing them using the mount 
options is fine at this point, and the actual recording of the default 
choices can be nailed down all at once in one final change, just before 
the "be prepared for on-disk-format-changes" label comes off.

-- 
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


  parent reply	other threads:[~2012-01-28 10:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-27 15:03 Setting options permanently? Hadmut Danisch
2012-01-27 23:20 ` Chester
2012-01-28  0:49   ` Hadmut Danisch
2012-01-28  3:32     ` Duncan
2012-01-28  6:05       ` Ben Klein
2012-01-28  8:23         ` Roman Mamedov
2012-01-28  9:24           ` Ben Klein
2012-01-28 10:55           ` Duncan [this message]
2012-01-30  5:57       ` Li Zefan
2012-01-28 12:07     ` Fajar A. Nugraha
2012-01-30  7:18     ` Sander
2012-01-30  7:49 ` Li Zefan

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.2012.01.28.10.55.21@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).