From: Dave Chinner <david@fromorbit.com>
To: stan hoeppner <stan@hardwarefreak.com>
Cc: xfs@oss.sgi.com
Subject: Re: storage, libaio, or XFS problem? 3.4.26
Date: Wed, 3 Sep 2014 08:19:15 +1000 [thread overview]
Message-ID: <20140902221915.GK20518@dastard> (raw)
In-Reply-To: <5405FB19.2020208@hardwarefreak.com>
On Tue, Sep 02, 2014 at 12:15:05PM -0500, stan hoeppner wrote:
> On 09/01/2014 06:45 PM, Dave Chinner wrote:
> > On Sun, Aug 31, 2014 at 10:36:25PM -0500, stan hoeppner wrote:
> >> On 08/31/2014 06:57 PM, Dave Chinner wrote:
> >>> On Fri, Aug 29, 2014 at 09:55:53PM -0500, Stan Hoeppner wrote:
> >>>> Have you played with bcache yet?
> >>>
> >>> Enough to scare me. So many ways for things to go wrong, no easy way
> >>> to recover when things go wrong. And that's before I even get to
> >>> performance warts, like having systems stall completely because
> >>> there's tens or hundreds of GB of 4k random writes that have to be
> >>> flushed to slow SATA RAID6 in the cache....
> >>
> >> Yikes. I hadn't yet heard such opinions expressed. By go wrong I
> >> assume you mean the btrees or cached sector data getting broken, corrupted?
> >
> > bcache is a complex filesystem hidden inside a block device. If
> > bcache goes AWOL, so does the all the data on your block device.
> > Need I say more?
>
> So it's no different in that regard than the black box implementations
> such as LSI's CacheCade and various SAN vendor SSD caching
> implementations. Or are you saying the bcache code complexity is so
> much greater that failure is more likely that the vendor implementations?
No, not the code complexity in particular. It's more that compared
to vendor SSD caching implementations there's an awful lot less
testing and validation, and people tend to use random, unreliable
hardware for cache devices. It's great when it works, but the
configuration and validation of correct behaviour in error
conditions falls to the user...
> > screen is your friend when it comes to keeping remote shells
> > active as the network comes and goes. VPN drops out, just bring it
> > back up when you need it and reconnect to the remote screen instance
> > and it's like you never left....
>
> Thanks for this tip. I'd heard of screen before but never used it. I
> will say the man page is a bit intimidating for such an apparently
> simple tool...
Yeah, I use about 0.0001% of what screen can do. It could lose most
of it's functionality and I wouldn't notice or care. tmux is another
option for this functionality, but I've never used it because I
found out about screen first...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-09-02 22:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 6:18 storage, libaio, or XFS problem? 3.4.26 Stan Hoeppner
2014-08-26 6:25 ` Stan Hoeppner
2014-08-26 7:53 ` Dave Chinner
2014-08-26 17:19 ` Stan Hoeppner
2014-08-28 0:32 ` Dave Chinner
2014-08-28 22:31 ` Stan Hoeppner
2014-08-28 23:08 ` Dave Chinner
2014-08-29 16:38 ` Stan Hoeppner
2014-08-29 23:55 ` Dave Chinner
2014-08-30 2:55 ` Stan Hoeppner
2014-08-31 23:57 ` Dave Chinner
2014-09-01 3:36 ` stan hoeppner
2014-09-01 23:45 ` Dave Chinner
2014-09-02 17:15 ` stan hoeppner
2014-09-02 22:19 ` Dave Chinner [this message]
2014-09-07 5:23 ` stan hoeppner
2014-09-07 23:39 ` Dave Chinner
2014-09-08 15:13 ` stan hoeppner
2014-09-20 19:47 ` stan hoeppner
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=20140902221915.GK20518@dastard \
--to=david@fromorbit.com \
--cc=stan@hardwarefreak.com \
--cc=xfs@oss.sgi.com \
/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