From: "Stefan G. Weichinger" <lists@xunil.at>
To: linux-btrfs@vger.kernel.org
Subject: Re: general thoughts and questions + general and RAID5/6 stability?
Date: Thu, 25 Sep 2014 09:15:13 +0200 [thread overview]
Message-ID: <5423C101.8000201@xunil.at> (raw)
In-Reply-To: <542177BF.2000808@gmail.com>
Am 23.09.2014 um 15:38 schrieb Austin S Hemmelgarn:
>> What features for example?
> Well, running 'mkfs.btrfs -O list-all' with 3.16 btrfs-progs gives the
> following list of features:
> mixed-bg - mixed data and metadata block groups
> extref - increased hard-link limit per file to 65536
> raid56 - raid56 extended format
> skinny-metadata - reduced size metadata extent refs
> no-holes - no explicit hole extents for files
>
> mixed-bg is something that you generally wouldn't want to change after
> mkfs.
> extref can be enabled online, and the filesystem metadata gets updated
> as-needed, and dosen't provide any real performance improvement (but is
> needed for some mail servers that have HUGE mail-queues)
> I don't know anything about the raid56 option, but there isn't any way
> to change it after mkfs.
> skinyy-metadata can be changed online, and the format gets updated on
> rewrite of each metadata block. This one does provide a performance
> improvement (stat() in particular runs noticeably faster). You should
> probably enable this if it isn't already enabled, even if you don't
> recreate your filesystem.
> no-holes cannot currently be changed online, and is a very recent
> addition (post v3.14 btrfs-progs I believe) that provides improved
> performance for sparse files (which is particularly useful if you are
> doing things with fixed size virtual machine disk images).
Recreating or at least "btrfstune -rx" for my rootfs would mean that I
have to boot from a live medium bringing recent btrfs-progs, right?
sysresccd brings btrfs-progs-3.14.2 ... that should be enough, ok?
aside from that, the rootfs on my thinkpad shows these features:
# ls /sys/fs/btrfs/bec7dff9-8749-4db4-9a1b-fa844cfcc36a/features/
big_metadata compress_lzo extended_iref mixed_backref
So I only miss the skinny extents ... and "no-holes".
Stefan
next prev parent reply other threads:[~2014-09-25 7:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-19 20:50 general thoughts and questions + general and RAID5/6 stability? William Hanson
2014-09-20 9:32 ` Duncan
2014-09-22 20:51 ` Stefan G. Weichinger
2014-09-23 12:08 ` Austin S Hemmelgarn
2014-09-23 13:06 ` Stefan G. Weichinger
2014-09-23 13:38 ` Austin S Hemmelgarn
2014-09-23 13:51 ` Stefan G. Weichinger
2014-09-23 14:24 ` Tobias Holst
2014-09-24 1:08 ` Qu Wenruo
[not found] ` <CAGwxe4i2gQXSPiBGXbUKWid3o1tmD_+YtbOj=GQ11vzGx8CuTw@mail.gmail.com>
2014-09-23 14:47 ` Austin S Hemmelgarn
2014-09-23 15:25 ` Kyle Gates
2014-09-25 7:15 ` Stefan G. Weichinger [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-08-31 4:02 Christoph Anton Mitterer
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=5423C101.8000201@xunil.at \
--to=lists@xunil.at \
--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).