From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH RFC] xfstests: speculative preallocaction trimming test
Date: Fri, 09 Nov 2012 09:18:58 -0500 [thread overview]
Message-ID: <509D10D2.1050508@redhat.com> (raw)
In-Reply-To: <20121108222949.GT6434@dastard>
On 11/08/2012 05:29 PM, Dave Chinner wrote:
> On Thu, Nov 08, 2012 at 03:18:09PM -0500, Brian Foster wrote:
>> The speculative preallocation trimming test verifies that files
>> with post-EOF blocks are trimmed when the scan is invoked.
>> Background scans and the various scan filters are tested as well.
>>
>> Signed-off-by: Brian Foster <bfoster@redhat.com>
>> ---
>>
>> Hi all,
>>
...
>
> I'll have to get a basic version of the spacemen patchset I have
> sent out again so that we can get this into xfsprogs ASAP. I think
> we might be waiting until after the release is done before that
> happens, though....
>
No problem. Keep me posted on any significant changes and I'll keep this
up to date.
>>
>> 290 | 176 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 290.out | 55 ++++++++++++++++++
>> common.config | 1 +
>> common.rc | 10 +++
>> group | 1 +
>> 5 files changed, 243 insertions(+), 0 deletions(-)
>> create mode 100755 290
>> create mode 100644 290.out
>>
>> diff --git a/290 b/290
>> new file mode 100755
>> index 0000000..12ce9c2
>> --- /dev/null
>> +++ b/290
>> @@ -0,0 +1,176 @@
>> +#! /bin/bash
>> +# FS QA Test No. 290
>> +#
...
>> +
>> +_scratch_mkfs_xfs -d size=200m >> $seq.full 2>&1 || _fail "mkfs failed"
>
> _scratch_mkfs_sized 200m >> $seq.full 2>&1
>
> And once again, there's generally no need to check for mkfs failure.
>
Ok, thanks for the general tips on the filters and error checking.
>> +_scratch_mount
>> +
>> +echo "==================="
>> +echo -e "speculative preallocation trim"
>> +
>> +_create_files
>> +echo -e "\nfiles"
>
> I can't say I like the extra line output here. "pretty" .out
> contents isn't really necessary, especially when it makes the test
> code harder to read...
>
>> +_stat_files
>> +# trim all files
>> +_trim_prealloc $SCRATCH_MNT "-s"
>> +echo -e "\nno filter"
>> +_stat_files
>
> If you are going to put progress output in the $seq.out file (which
> I still think is unnecessary), then put it in the function doing
> that work.
>
I'll remove the newlines and things that uglify the code. I'd like to
keep the text headers such that the output is somewhat readable in the
event that the test fails, particularly since the output is repetitive.
>> +echo -e "\nuid/gid filter"
>> +_stat_files
>> +
>> +echo -e "\n==================="
>> +echo -e "background speculative preallocation trim"
>> +
>> +# Clean up (unmount), set the lifetime to 5s and remount to ensure that the new
>> +# lifetime kicks in immediately.
>> +
>> +_cleanup
>> +_set_speculative_prealloc_lifetime 5
>
> old_lifetime=`cat ....`
> echo 5 > ....
>
Ok.
>> +
>> +_scratch_mount
>
> Did I miss an unmount somewhere?
>
_cleanup is called immediately prior to the
_set_speculative_prealloc_lifetime call. There's a comment there too. ;)
>> +_create_files
>> +
>> +# flush and wait a few scan intervals
>> +sync
>> +sleep 15
>> +echo -e "\nbackground scan"
>> +_stat_files
>> +
>> +_set_speculative_prealloc_lifetime 300
>
> echo $old_lifetime > ....
>
>> diff --git a/group b/group
>> index a846b60..675d5b5 100644
>> --- a/group
>> +++ b/group
>> @@ -408,3 +408,4 @@ deprecated
>> 287 auto dump quota quick
>> 288 auto quick ioctl trim
>> 289 auto quick
>> +290 auto quick
>
> I'd suggest that the rw and ioctl groups are appropriate here as
> well.
>
Ok. Thanks!
Brian
> Cheers,
>
> Dave.
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2012-11-09 14:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-08 20:18 [PATCH RFC] xfstests: speculative preallocaction trimming test Brian Foster
2012-11-08 22:29 ` Dave Chinner
2012-11-09 14:18 ` Brian Foster [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=509D10D2.1050508@redhat.com \
--to=bfoster@redhat.com \
--cc=david@fromorbit.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox