Discourse - DeviceMapper causing corruption?

[Philip Rhoades]

People,


> Date: Mon, 21 Mar 2016 15:02:02 -0600
> From: Chris Murphy <lists at colorremedies.com>
> To: phil at pricom.com.au, 	Community support for Fedora users
> 	<users at lists.fedoraproject.org>
> Subject: Re: Discourse - DeviceMapper causing corruption?
> Message-ID:
> 	<CAJCQCtSCPQRQsecq0+dzEKdNjEDfBzaDavOOV_e_ARL6LjgkDg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> On Mon, Mar 21, 2016 at 1:03 PM, Philip Rhoades <phil at pricom.com.au> 
> wrote:
>> People,
>> 
>> I had a couple of issues to sort out with installing the Docker 
>> Discourse
>> app and while that was being done people made these comments:
>> 
>> "Devicemapper is non starter, fails spectacularly under load and 
>> causes
>> corruption. We block setup if we detect devicemapper. You need aufs or
>> another better supported docker filesystem."
>> 
>> - which was not true - it did install without resorting to aufs.
>> 
>> also:
>> 
>> "Redhat team get very upset when we mention that it just does not work 
>> for
>> us, but release after release they say there are no bugs left, and 
>> each time
>> we keep seeing Discourse users complain about corruption due to device
>> mapper."
>> 
>> Any comments?
> 
> On the one hand, I'd say, talk is cheap, show me the bug.
> 
> On the other hand, having blown up thinly provisioned pools quite a
> few times early on, I basically couldn't handle how non-deterministic
> the blow ups were, and how difficult the LVM and devicemapper tools
> are to understand the state of the pool, and fix it. So I gave up and
> went down the Btrfs path just because I understand it better, and
> there are only so many rabbit holes one has time and interest to go
> down.
> 
> For a good bug report you either need a way to debug it, i.e. you need
> familiarity with that thing you are debugging. Or you need a concise
> set of reproduce steps (and a list of versions) so someone else, like
> a dev or more experienced user, can reproduce that environment and
> steps and debug it. Without one of those two things at least, I think
> it's unreasonable to say "hi this is busted" and then just walk away.
> 
> aufs is just not workable in my opinion because it's not in the
> mainline kernel. So any sense of portability can't be that important
> if you're going to depend on aufs. There are plenty of bugs to go
> around at this point, between overlay(fs), btrfs, and devicemapper
> although I think by now most of the devicemapper stuff is probably the
> more stable of the three (?) just a guess really. I had 500+ container
> states as Btrfs subvolumes and never ran into a Btrfs related problem
> though. What are the CoreOS folks using? Overlay or dm?


I had another response on the Discourse forum:

"It's probably this bug, devicemapper seems to be unable to free deleted 
files until you delete the container:

   https://github.com/docker/docker/issues/188672

Which is catastrophic for any long-lived server that uses temporary 
files in any capacity at all."

Does that also make sense to more clued-up tech people than me?

Regards,

Phil.
-- 
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  phil at pricom.com.au