All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] [RFC] zram01: Fix on ppc64le
Date: Tue, 31 Jan 2017 11:14:06 -0500 (EST)	[thread overview]
Message-ID: <845142934.836828.1485879246140.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <1485870273-26990-1-git-send-email-chrubis@suse.cz>



----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: ltp@lists.linux.it
> Sent: Tuesday, 31 January, 2017 2:44:33 PM
> Subject: [LTP] [PATCH] [RFC] zram01: Fix on ppc64le
> 
> The minimal size for Btrfs filesystem on ppc64le is around 139MB, most
> likely because of larger page size, hence the test fails.
> 
> This commit adds tst_min_fs_size.sh library, that parses mkfs.btrfs
> output which includes minimal filesystem size in case of a failure.
> 
> The code also falls back to 150MB if the mkfs.btrfs output wasn't parsed
> correctly.
> 
> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> ---
>  testcases/kernel/device-drivers/zram/zram01.sh |  8 ++++--
>  testcases/lib/tst_min_fs_size.sh               | 35
>  ++++++++++++++++++++++++++
>  2 files changed, 41 insertions(+), 2 deletions(-)
>  create mode 100644 testcases/lib/tst_min_fs_size.sh

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.

Regards,
Jan

  reply	other threads:[~2017-01-31 16:14 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 [this message]
2017-02-01  9:45   ` Cyril Hrubis
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=845142934.836828.1485879246140.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --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 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.