linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: George Mitchell <george@chinilu.com>
To: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org
Subject: Re: Virtual Device Support
Date: Mon, 20 May 2013 22:21:01 -0700	[thread overview]
Message-ID: <519B043D.20805@chinilu.com> (raw)
In-Reply-To: <pan$9855$81c2d2df$c9aa1ca3$2451cc46@cox.net>

On 05/20/2013 08:59 PM, Duncan wrote:
> Then I ran into hardware issues that turned out to be bad caps on my 
> 8- year-old mobo (tho it was dual-socket first-gen opteron, which I 
> had upgraded to top-of-its-line dual-core Opteron 290s, thus four 
> cores @ 2.8 GHz, with 8 gigs RAM, so it wasn't as performance-dated as 
> its age might otherwise imply). However, those issues first appeared 
> as storage errors, so knowing the drives were aging, I thought it was 
> them, and I replaced, upgrading for the first time to 2.5" from the 
> older 3.5" drives.
And that is actually an advantage of using btrfs.  Because ... btrfs, 
unlike conventional RAID is very compatible and simple to use with 
SMART.  That way, by watching your system logs or journal, you are 
immediately aware of any hard drive issues.
> But meanwhile, the hardware problems continued, and I found the old 
> reiserfs was MUCH more stable under those conditions than btrfs, which 
> would often be missing entire directory trees after a crash, where 
> reiserfs would be missing maybe the last copied file or two. (I was 
> still trying to copy from the old raid1 to the new single device hard 
> drive, so was copying entire trees over... all on severely unstable 
> motherboard hardware that was frequently timing out SATA commands... 
> sometimes to resume after a couple minutes, sometimes not. Of course 
> at the time I was still blaming it on the old drives since that was 
> what I was copying from. It only became apparent that they weren't the 
> issue once I had enough on the new drive to try running from it with 
> the others detached.)
What can I say?  Hans Reiser, aside from his horrendous character flaws, 
is a software genius.  After a terrifying experience of having a hard 
drive fail and no backups, Hans Reiser and his helpers came to my aid 
and in short order I had all my data back intact.  I found that pretty 
impressive.  After that for a number of years I continued to use 
Reiserfs in a software RAID 1 configuration.  I never ever had any 
complaints about Reiserfs.  I really liked it and still do.  I really 
wanted to see Reiser4 see the light of day, but after Mr Reiser's 
incarceration, that has become more and more unlikely.  So, in 2009 I 
switch to hardware RAID 1 on a pair of old 3ware cards.  But file system 
RAID as offered by btrfs and zfs have the distinct advantage of not 
having to face those terrifying syncs after loss of a drive.  So now, as 
of April 2013, I am 100% on btrfs (well, almost).  I use 5 500GB Seagate 
2½" drives with all but boot filesystem (boot filesystem is spread 
across two Seagate 2½" 80GB drives formatted btrfs)  spread across them 
in RAID1 configuration. Additionally 100% of the content of those drives 
get backed up to another 500GB Seagate drive (formatted JFS) via cron 
every 3hrs AND to a 4TB Seagate drive (formatted btrfs raw, sans 
partitioning) via anacron daily, weekly, monthly, etc.  I also have a 
stripped down maintenance OS running on ext4 that I use to backup the 
main OS itself daily as a manual operation.  I am running this on a 
SuperMicro board with a dual core Pentium processor.  Not a particularly 
muscular system, but a VERY stable one.  I also use a small UPS unit 
which I think is a very good idea if you are doing write caching with 
btrfs, or any other filesystem for that matter. I use a CyberPower unit 
and CyberPower has a very nifty UPS tool for Linux which does 
auto-shutdown on low battery without intervention.

All in all I am very happy with this arrangement so far.  It has worked 
flawlessly in most respects and I really, really like btrfs. The two 
bugs in the ointment for me right now are 1) the infamous boot bug on 
kernel 3.8 whereby one gets repeated boot failures do to "open_ctree 
failure" and can only boot the system successfully after multiple 
attempts.  And 2) the btrfs incompatibilities like the umount issue 
which I script my way around by doing `mount -l` which provides both the 
LABEL and the mount point on the same line then `grep` out the label, 
extract the mount point with a `cut` and feed the verified mount point 
to `umount`.  That all works very sweet even if it is a bit clutzy.  And 
I am well enough aware of the dark side of all of this to steer clear of 
fatal moves with partitioning tools etc that don't have a clue that a 
mounted btrfs partition is ... a mounted btrfs partition even if it is 
NOT the mount point.  My only real concern at this point is the boot 
issue.  Overall, I have a lot less problems now than I did with hardware 
RAID and have not the least desire to go back.  btrfs could be better, 
but its still head and shoulders over any other approach I have tried, 
but that does not include zfs, which I have also heard very good things 
about.


  reply	other threads:[~2013-05-21  5:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-10 14:03 Virtual Device Support George Mitchell
2013-05-19 11:04 ` Martin
2013-05-19 14:49   ` George Mitchell
2013-05-19 17:18     ` Martin
     [not found]     ` <CAHGunUke143r3pj0Piv3AtJrJO1x8Bm+qS5Z+sY1G1EobhMG_w@mail.gmail.com>
2013-05-21 14:26       ` George Mitchell
2013-05-19 11:15 ` Roman Mamedov
2013-05-19 18:18   ` Chris Murphy
2013-05-19 18:22     ` Chris Murphy
2013-05-21  1:08     ` Duncan
2013-05-21  2:17       ` George Mitchell
2013-05-21  3:59         ` Duncan
2013-05-21  5:21           ` George Mitchell [this message]
2013-05-21 12:19           ` Virtual Device Support ("N-way mirror code") Martin
2013-05-23 16:08             ` Martin Steigerwald
2013-05-24  1:41               ` George Mitchell
2013-05-25 11:53                 ` Martin Steigerwald
2013-05-24  6:13               ` Duncan
2013-05-25 11:56                 ` Martin Steigerwald
2013-05-21  3:37       ` Virtual Device Support Chris Murphy
2013-05-21 12:06         ` Martin
2013-05-22  2:23           ` Chris Murphy

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=519B043D.20805@chinilu.com \
    --to=george@chinilu.com \
    --cc=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).