public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] [RFC] zram01: Fix on ppc64le
Date: Wed, 1 Feb 2017 10:45:41 +0100	[thread overview]
Message-ID: <20170201094541.GA13898@rei.lan> (raw)
In-Reply-To: <845142934.836828.1485879246140.JavaMail.zimbra@redhat.com>

Hi!
> This is ~4 years old comment from Zach Brown, when I hit an issue on ppc,
> where I could alloc only 1/2 of the volume size:
> 
> "That small volume mkfs warning is issued for devices less than a gig.  It indicates that btrfs has gone in to a weird degenerate allocation scheme.  We'd only support volumes much larger than that, though I have no quick rule to say how large starts to be reasonable.  Multiple gig, certainly."
> 
> I'm running with 384M since then, so far successfully. If we don't allocate
> too much data on it, we might be OK, but still I'd go with minimum default of 256M.

What exactly do you have in mind? Using 256MB by default for any Btrfs
filesystem or fallback to 256MB if mkfs.btrfs output cannot be parsed?

I guess that for any other testcase it would be fine enough to bump the
minimal device size to 256MB unconditionally, but in this case we create
the data in RAM albeit compressed, and so I would like to keep it as
small as possible, since otherwise it may fail on embedded hardware.
Maybe we should just remove Btrfs from the zram01.sh test so that we
don't have to keep bumping the minimal size each time the minimal Btrfs
size calculation changes...

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2017-02-01  9:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-31 13:44 [LTP] [PATCH] [RFC] zram01: Fix on ppc64le Cyril Hrubis
2017-01-31 16:14 ` Jan Stancek
2017-02-01  9:45   ` Cyril Hrubis [this message]
2017-02-01 10:59     ` Jan Stancek
2017-02-02 15:22       ` Cyril Hrubis
2017-02-08 11:10         ` Cyril Hrubis
2017-02-09 12:02           ` Cyril Hrubis
2017-02-09 13:24             ` Jan Stancek
2017-02-09 14:00               ` Cyril Hrubis
2017-02-09 14:48                 ` Jan Stancek
2017-02-09 14:56                   ` Cyril Hrubis
2017-08-15  9:23 ` Cyril Hrubis
2017-08-15 11:44   ` Jan Stancek
2017-08-15 12:38     ` Cyril Hrubis
2017-08-15 12:48       ` Jan Stancek
2017-08-15 12:57         ` Cyril Hrubis

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=20170201094541.GA13898@rei.lan \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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