All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Dave Stevens <geek@uniserve.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: should I use btrfs on Centos 7 for a new production server?
Date: Wed, 31 Dec 2014 12:00:01 +0800	[thread overview]
Message-ID: <54A374C1.2030401@cn.fujitsu.com> (raw)
In-Reply-To: <20141230192910.50345rkrnf3a8akm@webmail.uniserve.com>

Hi Dave,

-------- Original Message --------
Subject: should I use btrfs on Centos 7 for a new production server?
From: Dave Stevens <geek@uniserve.com>
To: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Date: 2014年12月31日 11:29
> I have a well tested and working fine Centos5-Xen system. Accumulated 
> cruft from various development efforts make it desirable to redo the 
> install. Currently a RAID-10 ext4 filesystem with LVM and 750G of 
> storage. There's a hot spare 750 drive in the system.
>
> I'm thinking of migrating the web sites (almost the only use of the 
> server) to a spare then installing Centos-7 and btrfs, then migrating 
> the sites back.
>
> I see RH marks btrfs in C7 as a technology preview but don't 
> understand what that implies for future support and a suitably stable 
> basis for storage.
Technology preview means no full official Red Hat support, just preview 
for technology.
https://access.redhat.com/support/offerings/techpreview

It may comes to full support in later version if it matures.
>
> The demand on the system is low and not likely to change in the near 
> future, storage access speeds are not likely to be dealbreakers and it 
> would be nice to not need to use LVM, btrfs seems to have a better 
> feature set and more intuitive command set. But I'm uncertain about 
> stability. Anyone have an opinion?
If I am sysadmin, I will still prefer the mature linux soft raid/LVM.

Less bug, mature kernel/user-land tools and use case,and you don't need 
to always update kernel/btrfs-progs
to address known bugs or fix corrupted fs
(if stay away from 
scrub/replace/balance/almost-full-disk/sudden-power-failure, it will 
shouldn't happen though)

But, if you want to contribute to btrfs, such production environment may 
expose some problem we didn't find.
Although you may take a lot time compiling latest kernel/btrfs-progs and 
doing btrfs-image dump, not to mention
the offline time...

Thanks,
Qu
>
> Dave
>


  reply	other threads:[~2014-12-31  4:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-31  3:29 should I use btrfs on Centos 7 for a new production server? Dave Stevens
2014-12-31  4:00 ` Qu Wenruo [this message]
2014-12-31  4:03 ` Wang Shilong
2014-12-31  4:06   ` Wang Shilong
2014-12-31  6:04     ` Eric Sandeen
2014-12-31  6:16       ` Fajar A. Nugraha
2014-12-31 16:28         ` Duncan
2014-12-31 18:17           ` Roman Mamedov
2014-12-31  5:55   ` Eric Sandeen
2015-01-01  8:22 ` Zygo Blaxell

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=54A374C1.2030401@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=geek@uniserve.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.