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
next prev 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).