All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	"Theodore Ts'o" <tytso@mit.edu>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Parisc List <linux-parisc@vger.kernel.org>
Subject: Re: Question about ext4 testing: need to produce a high depth extent tree to verify mapping code
Date: Fri, 5 Jul 2019 14:40:58 -0700	[thread overview]
Message-ID: <20190705214058.GD5161@magnolia> (raw)
In-Reply-To: <1562352542.2953.10.camel@HansenPartnership.com>

On Fri, Jul 05, 2019 at 11:49:02AM -0700, James Bottomley wrote:
> On Fri, 2019-07-05 at 10:39 -0700, Matthew Wilcox wrote:
> > On Fri, Jul 05, 2019 at 09:25:48AM -0700, James Bottomley wrote:
> > > Now the problem: I'd like to do some testing with high depth extent
> > > trees to make sure I got this right, but the files we load at boot
> > > are ~20MB in size and I'm having a hard time fragmenting the
> > > filesystem enough to produce a reasonable extent (I've basically
> > > only got to a two level tree with two entries at the top).  Is
> > > there an easy way of producing a high depth extent tree for a 20MB
> > > file?
> > 
> > Create a series of 4kB files numbered sequentially, each 4kB in size
> > until you fill the partition.  Delete the even numbered ones.  Create
> > a 20MB file.
> 
> Well, I know *how* to do it ... I was just hoping, in the interests of
> creative laziness, that someone else had produced a script for this
> before I had to ... particularly one which leaves more randomized gaps.

If you don't care about the contents of the file you could just build
src/punch-alternating.c from xfstests and use it to turn your 20M file
into holy cheese.

(Granted if you actually need 5,120 extents then you probably ought to
make it a 40M file and /then/ run it through the cheese grater....)

--D

> James
> 

  reply	other threads:[~2019-07-05 21:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-01 22:44 [BUG] mke2fs produces corrupt filesystem if badblock list contains a block under 251 James Bottomley
2019-07-02  0:23 ` Theodore Ts'o
2019-07-02  0:53   ` James Bottomley
2019-07-02 17:33     ` Theodore Ts'o
2019-07-02 19:31       ` James Bottomley
2019-07-02 20:39         ` Theodore Ts'o
2019-07-03  0:37           ` James Bottomley
2019-07-05 16:25           ` Question about ext4 testing: need to produce a high depth extent tree to verify mapping code James Bottomley
2019-07-05 17:39             ` Matthew Wilcox
2019-07-05 18:49               ` James Bottomley
2019-07-05 21:40                 ` Darrick J. Wong [this message]
2019-07-06  4:02                 ` Theodore Ts'o

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=20190705214058.GD5161@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.org \
    /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.