Hey Igor, I'm running it now. Should have results for you in a few hours.

On Thu, Mar 22, 2018 at 9:46 AM, Igor Kozhukhov <[email protected]> wrote:

> Paul,
>
> could you please try to do your tests with recordsize=1m ?
>
> Best regards,
> -Igor
>
>
> On Mar 22, 2018, at 7:43 PM, Paul Dagnelie <[email protected]>
> wrote:
>
> Sorry for the delay in getting back to this. I created a pool on 4 1TB
> HDDs, and then created a filesystem with compression off (since i'm using
> random data, it wouldn't help) and a edon-r for the checksum. I then create
> a number of files of a given size using dd, creating 10 at a time in
> parallel. Once the files are created, I export and import the pool to clear
> the cache, and read in all the files, writing them to /dev/null. I ran that
> part 15 times, timing it each time to get a decent performance measurement.
> Then I destroy the filesystem, and go back to the fs creation step with new
> parameters.
>
> I ran a decent spectrum of tests, so hopefully some of this data will help
> reassure you. The numbers across the top rows are the size of the files
> created, and the numbers across the left are the number of files being
> read. The times are the average of the 15 runs, in seconds.
>
> For recordsize=512:
> Before128k1m8m64mAfter128k1m8m64m
> *10* 0.09 0.36 2.88 21.70 *10* 0.07 0.33 2.89 20.21
> *40* 0.29 1.55 11.93 86.50 *40* 0.24 1.46 10.94 83.53
> *160* 1.14 6.08 50.10 361.76 *160* 0.93 6.23 44.20 342.40
>
> For recordsize=8k:
> Before128k1m8m64mAfter128k1m8m64m
> *10* 0.05 0.16 0.64 3.89 *10* 0.07 0.16 0.72 3.61
> *40* 0.25 0.59 3.02 17.72 *40* 0.20 0.68 3.46 15.96
> *160* 0.69 2.79 12.43 68.86 *160* 0.76 2.59 14.47 59.43
>
> For recordsize=128k:
> Before128k1m8m64mAfter128k1m8m64m
> *10* 0.04 0.10 0.53 3.58 *10* 0.05 0.11 0.64 4.32
> *40* 0.14 0.37 2.31 17.94 *40* 0.14 0.45 2.62 16.95
> *160* 0.59 1.67 9.81 60.39 *160* 0.56 1.77 10.42 61.90
>
> It looks like performance is usually similar with the new bits, some
> slightly better and some slightly worse. Those results may be within the
> margin of error of each other, or there may be some pattern that explains
> why some runs are slightly faster and some are slightly slower; I'm not
> sure.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/openzfs/openzfs/pull/548#issuecomment-375374996>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AOi0K619PuG-3HScm7LAhGe50gtPRRmQks5tg9TEgaJpZM4SGMaf>
> .
>
>
> *openzfs <https://openzfs.topicbox.com/latest>* / openzfs-developer
> <https://openzfs.topicbox.com/groups/developer/members> / Permalink
> <https://openzfs.topicbox.com/groups/developer/discussions/T987f71bf0a7c33f4-M9e030568d2f37c30c92ed08b>
>  Delivery
> options <https://openzfs.topicbox.com/groups>
>



-- 
Paul Dagnelie

------------------------------------------
openzfs: openzfs-developer
Permalink: 
https://openzfs.topicbox.com/groups/developer/discussions/T987f71bf0a7c33f4-M0c3cc37d719862cce7cdd734
Delivery options: https://openzfs.topicbox.com/groups

Reply via email to