Am Donnerstag, 26. Januar 2012 schrieb Duncan:
> I'm currently researching an upgrade to (raid1-ed) btrfs from mostly
> reiserfs (which I've found quite reliable (even thru a period of bad
> ram and resulting system crashes) since data=ordered went in with
> 2.6.16 or whatever it was. (Thanks, Chris! =:^)) on multiple
> md/raid-1s. I have some questions that don't appear to be addressed
> well on the wiki, yet, or where the wiki info might be dated.
>
> Device hardware is 4 now aging 300-gig disks with identical gpt-
> partitioning on all four disks, using multiple 4-way md/raid-1s for
> most of the system. I'm running gentoo/~amd64 with the linus mainline
> kernel from git, kernel generally updated 1-2X/wk except during the
> merge window, so I stay reasonably current. I have btrfs-progs-9999,
> aka the live-git build, kernel.org mason tree, installed.
>
> The current layout has a total of 16 physical disk partitions on each
> of the four drives, mostly of which are 4-disk md/raid1, but with a
> couple md/raid1s for local cache of redownloadables, etc, thrown in.
> Some of the mds are further partitioned (mdp), some not. A couple are
> only 2- disk md/raid1 instead of the usual 4-disk. Most mds have a
> working and backup copy of exactly the same partitioned size, thus
> explaining the multitude of partitions, since most of them come in
> pairs. No lvm as I'm not running an initrd which meant it couldn't
> handle root, and I wasn't confident in my ability to recover the
> system in an emergency with lvm either, so I was best off without it.
Sounds like a quite complex setup.
> Three questions:
>
> 1) My /boot partition and its backup (which I do want to keep separate
> from root) are only 128 MB each. The wiki recommends 1 gig sizes
> minimum, but there's some indication that's dated info due to mixed
> data/ metadata mode in recent kernels.
>
> Is a 128 MB btrfs reasonable? What's the mixed-mode minumum
> recommended and what is overhead going to look like?
I don´t know.
You could try with a loop device. Just create one and mkfs.btrfs on it,
mount it and copy your stuff from /boot over to see whether that works and
how much space is left.
On BTRFS I recommend using btrfs filesystem df for more exact figures of
space utilization that df would return.
Likewise for RAID 1, just create 2 or 4 BTRFS image files.
You may try with:
-M, --mixed
Mix data and metadata chunks together for more
efficient space utilization. This feature incurs
a performance penalty in larger filesystems. It
is recommended for use with filesystems of 1 GiB
or smaller.
for smaller partitions (see manpage of mkfs.btrfs).
> 2) The wiki indicates that btrfs-raid1 and raid-10 only mirror data 2-
> way, regardless of the number of devices. On my now aging disks, I
> really do NOT like the idea of only 2-copy redundancy. I'm far happier
> with the 4-way redundancy, twice for the important stuff since it's in
> both working and backup mds altho they're on the same 4-disk set (tho I
> do have an external drive backup as well, but it's not kept as
> current).
>
> If true that's a real disappointment, as I was looking forward to
> btrfs- raid1 with checksummed integrity management.
I didn´t see anything like this.
Would be nice to be able to adapt the redundancy degree where possible.
An idea might be splitting into a delayed synchronisation mirror:
Have two BTRFS RAID-1 - original and backup - and have a cronjob with
rsync mirroring files every hour or so. Later this might be replaced by
btrfs send/receive - or by RAID-1 with higher redundancy.
> 3) How does btrfs space overhead (and ENOSPC issues) compare to
> reiserfs with its (default) journal and tail-packing? My existing
> filesystems are 128 MB and 4 GB at the low end, and 90 GB and 16 GB at
> the high end. At the same size, can I expect to fit more or less data
> on them? Do the compression options change that by much "IRL"? Given
> that I'm using same- sized partitions for my raid-1s, I guess at least
> /that/ angle of it's covered.
The efficiency of the compression options depend highly of the kind of data
you want to store.
I tried lzo on a external disk with movies, music files, images and
software archives. The effect has been minimal, about 3% or so. But for
unpacked source trees, lots of clear text files, likely also virtual
machine image files or other nicely compressible data the effect should be
better.
Although BTRFS received a lot of fixes for ENOSPC issues I would be a bit
reluctant with very small filesystems. But that is just a gut feeling. So I
do not know whether the option -M from above is tested widely. I doubt it.
Maybe someone with more in-depth knowledge can shed some light on this.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
