linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: shally verma <shallyvermacavium@gmail.com>
To: Timofey Titovets <nefelim4ag@gmail.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>,
	"Verma, Shally" <shally.verma@cavium.com>
Subject: Re: using fio to test btrfs compression
Date: Wed, 20 Sep 2017 15:43:25 +0530	[thread overview]
Message-ID: <CAP9W88hrM+9vPTL=RFXC9+VdWSLMvM1UAtR+XX89FcvorYLqvQ@mail.gmail.com> (raw)
In-Reply-To: <CAGqmi75wKaxpJNO6HfjUJZU4tESQA-r_4rTfe7MY9KW5C67JaQ@mail.gmail.com>

On Wed, Sep 20, 2017 at 3:06 PM, Timofey Titovets <nefelim4ag@gmail.com> wrote:
> 2017-09-20 11:59 GMT+03:00 shally verma <shallyvermacavium@gmail.com>:
>> On Wed, Sep 20, 2017 at 2:25 PM, Timofey Titovets <nefelim4ag@gmail.com> wrote:
>>> 2017-09-20 11:44 GMT+03:00 shally verma <shallyvermacavium@gmail.com>:
>>>> One more catch... I am initiating fio from non-btrfs filesystem i.e.
>>>> pwd is ext4 based fs where as mount point is btrfs.
>>>> Could that make difference?
>>>>
>>>>> Thanks
>>>>> Shally
>>>
>>> Only matter are where you store test file =)
>>> If you store test file on btrfs, pwd does nothing.
>>>
>>
>> Then steps listed in previous mail should work right?  Am listing them
>> again here:
>>
>> " ----
>>>
>>> 1. mount -t btrfs -o compress-force=zlib /dev/sdb1 mnt
>>>
>>> 2. fio --directory=mnt/ --numjobs=1 --direct=0 --buffered=1 --bs=64k
>>> --rw=write --iodepth=128 --name=test --size=1G
>>> --buffer_compress_percentage=100 --buffer_pattern=0xFF --refill_buffer
>>> --ioengine=libaio
>>>
>>> 1GN file written uncompressed. Here no compression invoked (though
>>> compress-force=zlib)
>>>
>>> 3. cp mnt/test ./ --> copy back fio generated test file from btrfs
>>> mount point to local drive
>>>
>>> 4. hex dump test file (all FFs) -- confirmed that data is compressible
>>> no random data.
>>>
>>> 5. cp test mnt/  --> now, copy same test again back to mount point
>>> (reverse of step 3) . Now, here I see during copying compression is
>>> invoked.
>>>
>>> I am using kernel 4.9 and compress-foce is said to be working for
>>> kernel > 2.13 from wiki ... so I wonder what's so special with cp
>>> command which is not happening during fio writes???
>>
>> "-----
>>
>> Thanks
>> Shally
>>
>>
>>> --
>>> Have a nice day,
>>> Timofey.
>
> I did try reproduce your problem on 4.14, i'm hard to explain that
> happens and why file created by FIO will not use compression.
>
> Suggest workaround:
> rm -v /mnt/test.0.0
> dd if=/dev/zero of=/mnt/test.0.0 bs=1M count=1024

You mean "compression" using "dd" write.

> fio --directory=$HOME/test/ --numjobs=1 --direct=1 --buffered=0
> --bs=64k --rw=write --iodepth=128 --name=test --size=1G
> --buffer_compress_percentage=100 --buffer_pattern=0xFF --refill_buffer
> --ioengine=libaio

You mean "no compression" during fio writes and you see similar behavior as I?
BTW here --direct=0 and --buffered = 1.

>
> You can check if data compressed by filefrag -v /mnt/test.0.0 (you
> will see encoded extents)
>
if I do filefrag on mnt/test.0.0, then it shows up like this:
ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       1:    1329922..   1329923:      2:
   1:        2..       3:    1329923..   1329924:      2:    1329924:
   2:        4..       5:    1329924..   1329925:      2:    1329925:

An new to this, how does it says extents are encoded here?

Thanks
Shally

> --
> Have a nice day,
> Timofey.

  reply	other threads:[~2017-09-20 10:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-18  7:36 using fio to test btrfs compression shally verma
2017-09-18  8:26 ` Timofey Titovets
2017-09-18 13:28   ` shally verma
2017-09-18 13:41     ` Timofey Titovets
2017-09-20  8:36       ` shally verma
2017-09-20  8:44         ` shally verma
2017-09-20  8:55           ` Timofey Titovets
2017-09-20  8:59             ` shally verma
2017-09-20  9:36               ` Timofey Titovets
2017-09-20 10:13                 ` shally verma [this message]
2017-09-20 10:30                   ` Timofey Titovets
2017-09-20 11:10                     ` shally verma
2017-09-21 11:42                       ` Duncan
     [not found]                       ` <CAGqmi74eviuSf=LL7sGEJnH1YYqu_pHdaGDvq4Qdr4aSpvqxkQ@mail.gmail.com>
2017-09-22  5:33                         ` shally verma
2017-09-22 17:05                           ` Timofey Titovets
2017-09-21 15:26 ` Liu Bo

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='CAP9W88hrM+9vPTL=RFXC9+VdWSLMvM1UAtR+XX89FcvorYLqvQ@mail.gmail.com' \
    --to=shallyvermacavium@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nefelim4ag@gmail.com \
    --cc=shally.verma@cavium.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;
as well as URLs for NNTP newsgroup(s).