All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: WuBo <wu.bo@cn.fujitsu.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfstests: several 274 fixups
Date: Wed, 1 Feb 2012 15:07:07 +1100	[thread overview]
Message-ID: <20120201040707.GT9090@dastard> (raw)
In-Reply-To: <4F28A32C.9030706@sandeen.net>

On Tue, Jan 31, 2012 at 08:27:56PM -0600, Eric Sandeen wrote:
> On 1/31/12 4:41 PM, Dave Chinner wrote:
> > On Mon, Jan 30, 2012 at 04:27:51PM -0600, Eric Sandeen wrote:
> >> -dd if=/dev/zero of=tmp1 bs=1M >/dev/null 2>&1
> >> -dd if=/dev/zero of=tmp2 bs=4K >/dev/null 2>&1
> >> +# Fill the rest of the fs completely
> >> +dd if=/dev/zero of=$SCRATCH_MNT/tmp1 bs=1M >>$seq.full 2>&1
> >> +dd if=/dev/zero of=$SCRATCH_MNT/tmp2 bs=4K >>$seq.full 2>&1
> >>  sync
> >> +# Last effort, use O_SYNC
> >> +dd if=/dev/zero of=$SCRATCH_MNT/tmp3 bs=4K oflag=sync >>$seq.full 2>&1
> >> +# Save space usage info
> >> +echo "Post-fill space:" >> $seq.full
> >> +df $SCRATCH_MNT >>$seq.full 2>&1
> >>  
> >> -dd if=/dev/zero of=test seek=1 bs=4K count=2 conv=notrunc >/dev/null 2>&1
> >> +# Now attempt a write into all of the preallocated space 
> >> +dd if=/dev/zero of=$SCRATCH_MNT/test seek=1 bs=4K count=1024 conv=notrunc >>$seq.full 2>&1
> >>  if [ $? -ne 0 ]
> >>  then
> >> -	echo "fill prealloc range err"
> >> +	echo "fill prealloc range error"
> >>  	status=1
> >>  	exit
> >>  fi
> > 
> > I'd still like to see this write attempt to trigger nasty behaviours
> > like needing to allocate a metadata block for the extent list. I
> > suggested randholes, but perhaps this would be easier:
> > 
> > for i in `seq 1 2 1023`; do
> > 	dd if=/dev/zero of=$SCRATCH_MNT/test seek=$i bs=4K count=1 conv=notrunc \
> > 		>>$seq.full 2>&1 || _fail "failed to write test file"
> > done
> > 
> > which will write every second block and so only convert every second
> > block from unwritten to written and hence blow out the size of the
> > extent list and require extent map block allocation and potentially
> > trigger ENOSPC that way....
> 
> but will also only write half the actual preallocated space.  I guess it
> depends on what we are trying to test - reservations for metadata or proper
> accounting of prealloc'd space itself...?

So then go back and fill in the unwritten blocks. i.e:

for i in `seq 1 2 1023`; do
	dd if=/dev/zero of=$SCRATCH_MNT/test seek=$i bs=4K count=1 conv=notrunc \
		>>$seq.full 2>&1 || _fail "failed to write test file"
done
sync
for i in `seq 2 2 1023`; do
	dd if=/dev/zero of=$SCRATCH_MNT/test seek=$i bs=4K count=1 conv=notrunc \
		>>$seq.full 2>&1 || _fail "failed to fill test file"
done
sync

> (and really, what is the proper amount of preallocated metadata space; if
> I subbed 2G for 4M, would anything survive the test above?)

Given that the test is only using a 1GB filesystem.... ;)

But even if it was 2GB, then I'm pretty sure that XFS would handle
it fine. Take a long to run, though, with all those individual 4k
IOs. My point was simply to determine if the filesystem will be able
to hold up the guarantees posix_fallocate() tries to give
applications, and so enough extents simple to force a single
metadata block allocation is all that is required. Having a 1000
extent state changes shoul dbe sufficient to cause that....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2012-02-01  4:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30 22:27 [PATCH] xfstests: several 274 fixups Eric Sandeen
2012-01-31 22:41 ` Dave Chinner
2012-02-01  2:27   ` Eric Sandeen
2012-02-01  4:07     ` Dave Chinner [this message]
2012-03-08 21:55   ` Eric Sandeen
2012-03-08 23:34     ` Dave Chinner
2012-03-08 22:23 ` [PATCH V2] " Eric Sandeen
2012-03-08 22:23   ` Eric Sandeen
2012-04-06 16:12   ` Mark Tinguely
2012-03-31 16:00 ` [PATCH] " Christoph Hellwig

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=20120201040707.GT9090@dastard \
    --to=david@fromorbit.com \
    --cc=sandeen@sandeen.net \
    --cc=wu.bo@cn.fujitsu.com \
    --cc=xfs@oss.sgi.com \
    /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.