linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Cc: fstests@vger.kernel.org, linux-mtd@lists.infradead.org, richard@nod.at
Subject: Re: Add UBIFS support to xfstests
Date: Wed, 17 May 2017 12:05:54 -0700	[thread overview]
Message-ID: <20170517190554.GC91213@gmail.com> (raw)
In-Reply-To: <20170517095531.11818-1-david.oberhollenzer@sigma-star.at>

Hi David,

On Wed, May 17, 2017 at 11:55:28AM +0200, David Oberhollenzer wrote:
> 
> Modifying the xfstests-bld patch to use nandsim (which simulates a NAND
> flash MTD device) instead of block2mtd has been considered, however the
> default size of 128MiB is slightly too small for generic/129.
> 
> Nandsim does not have an option to directly specify the size of the
> backing buffer but instead requires a set of NAND ID bytes that imply
> (among other things) the size of the chip (example, see 1). The ID bytes
> would have to be added to the kernel arguments for the UBIFS case. It
> might be desirable to document this somehow, for the next person who
> has to adjust the size, once a new test exhausts it. Also, it would be
> ultimately limted by available RAM and what can be encoded using the
> NAND ID bytes.
> 
> So right now, it looks like block2mtd is the simplest option for getting
> xfstests-bld to work with UBIFS.
>

It probably would be a good idea to document this decision somewhere more
permanent, maybe in a comment in
kvm-xfstests/test-appliance/files/root/fs/ubifs/config, which is where the
block2mtd devices get set up.

Or, it could be useful to add a documentation file for UBIFS in the xfstests-bld
documentation directory, which would also document any "gotchas" specific to how
UBIFS support is implemented in the test appliances, e.g the two issues I listed
in my patch description.  Also the fact that you need to configure your kernel
with UBIFS and block2mtd support.  Ideally we'd just fix these issues, though,
so there would be nothing special to document.  (We could at least solve the
kernel configuration issue by renaming the example configs in the
kernel-configs/ directory from "ext4-" to "xfstests-", then enabling support for
ubifs, f2fs, btrfs, etc.  in them.)

Eric

      parent reply	other threads:[~2017-05-17 19:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-17  9:55 Add UBIFS support to xfstests David Oberhollenzer
2017-05-17  9:55 ` [PATCH 1/2] Add support for UBIFS David Oberhollenzer
2017-05-17 11:53   ` Eryu Guan
2017-05-17 18:45     ` Eric Biggers
2017-05-18  8:41       ` David Oberhollenzer
2017-05-18 11:35         ` Eryu Guan
2017-05-17  9:55 ` [PATCH 2/2] Accept failing with EPERM in addition to ENOKEY for rename without key David Oberhollenzer
2017-05-17 19:21   ` Eric Biggers
2017-05-17  9:55 ` [PATCH] xfstests-bld: add experimental support for ubifs David Oberhollenzer
2017-05-17 19:05 ` Eric Biggers [this message]

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=20170517190554.GC91213@gmail.com \
    --to=ebiggers3@gmail.com \
    --cc=david.oberhollenzer@sigma-star.at \
    --cc=fstests@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    /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).