From: Eric Sandeen <sandeen@redhat.com>
To: Zeev Tarantov <zeev.tarantov@gmail.com>
Cc: Andreas Dilger <adilger@dilger.ca>,
ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] e2fsprogs: don't set stripe/stride to 1 block in mkfs
Date: Wed, 06 Apr 2011 10:00:40 -0700 [thread overview]
Message-ID: <4D9C9C38.2070008@redhat.com> (raw)
In-Reply-To: <BANLkTi=wnyvf2T5KDo5NQkjLw4aTHPUz9w@mail.gmail.com>
On 4/5/11 11:51 PM, Zeev Tarantov wrote:
> On Wed, Apr 6, 2011 at 01:21, Eric Sandeen <sandeen@redhat.com> wrote:
>> Zeev, if you'd like to test that patch above with your profiling, that'd be awesome.
>
> My wall-clock timings are strange and I disregard them.
> On a desktop with X turned off and perf recording system-wide, I trust
> the profile to show everything.
Agreed, the wallclock time was just a very coarse sanity check while off at a conference :)
> In the no-stride case, I don't think you've made it any worse.
it shouldn't even go down this path so I hope not ;)
> In the stripe=stride=1, it went from:
>
> [ perf record: Woken up 13 times to write data ]
> [ perf record: Captured and wrote 3.163 MB perf.data (~138211 samples) ]
> # Events: 14K cycles
> #
> # Overhead Command Shared Object
> Symbol
> # ........ .............. .....................
> .......................................
> #
> 13.08% gzip gzip [.] zip
> 12.65% flush-253:0 [kernel.kallsyms] [k] ext4_mb_scan_aligned
...
> to:
>
> [ perf record: Woken up 12 times to write data ]
> [ perf record: Captured and wrote 3.091 MB perf.data (~135042 samples) ]
> # Events: 13K cycles
> #
> # Overhead Command Shared Object
> Symbol
> # ........ ........... .....................
> .....................................
> #
> 15.10% gzip gzip [.] zip
> 14.70% gzip gzip [.] treat_file.part.4.2264
> 11.10% flush-253:0 [csnappy_compress] [k] snappy_compress_fragment
> 6.12% md5sum md5sum [.] digest_file.isra.2.2089
...
> 0.23% tar [kernel.kallsyms] [k] ext4_mb_scan_aligned
...
> So that's great, but I still don't want mke2fs to set a stripe and
> stride of 1, because that's silly - no code improvement in the
> allocator is ever going to be able to use that information.
I totally agree, and I'm sure the mkfs patch will go in as well.
Thanks for the verification of the kernel patch, too.
It should help a bit for sane stripe-sizes, too, with less impact as the stripe size gets bigger.
Thanks,
-Eric
>> Thanks,
>> -Eric
>
> Thank you!
> -Z.T.
next prev parent reply other threads:[~2011-04-06 17:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-04 19:11 [PATCH] e2fsprogs: don't set stripe/stride to 1 block in mkfs Eric Sandeen
2011-04-05 8:10 ` Andreas Dilger
2011-04-05 8:43 ` Zeev Tarantov
2011-04-05 16:39 ` Eric Sandeen
2011-04-05 16:56 ` Eric Sandeen
2011-04-05 22:21 ` Eric Sandeen
2011-04-06 6:51 ` Zeev Tarantov
2011-04-06 17:00 ` Eric Sandeen [this message]
2011-04-08 0:13 ` Andreas Dilger
2011-04-08 0:24 ` Eric Sandeen
2011-05-18 17:20 ` Ted 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=4D9C9C38.2070008@redhat.com \
--to=sandeen@redhat.com \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=zeev.tarantov@gmail.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.