All of lore.kernel.org
 help / color / mirror / Atom feed
From: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
To: fdmanana@gmail.com
Cc: fstests@vger.kernel.org,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Lukas Czerner <lczerner@redhat.com>
Subject: Re: [PATCH] generic/017: skip invalid block sizes for btrfs
Date: Mon, 23 Jun 2014 20:04:56 +0900	[thread overview]
Message-ID: <53A809D8.9010601@jp.fujitsu.com> (raw)
In-Reply-To: <CAL3q7H7PvNQi1W=gnbjSmJd-r3sR3FPs+qfdfCDH34R=eujHMw@mail.gmail.com>

Hi Filipe,

(2014/06/23 19:55), Filipe David Manana wrote:
> On Mon, Jun 23, 2014 at 11:48 AM, Satoru Takeuchi
> <takeuchi_satoru@jp.fujitsu.com> wrote:
>> Hi Filipe,
>>
>> (2014/06/23 19:28), Filipe David Borba Manana wrote:
>>> In btrfs the block size (called sector size in btrfs) can not be
>>> smaller then the page size. Therefore skip block sizes smaller
>>> then page size if the fs is btrfs, so that the test can succeed
>>> on btrfs (testing only with block sizes of 4kb on systems with a
>>> page size of 4Kb).
>>>
>>> Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
>>
>> I consider it doesn't work since this test is not for Btrfs.
>
> Did you try it out (together with the corresponding change for btrfs
> to support collapse range) or is just code analysis?

I commented it just by code analysis.

> For me it works.
>
>> Please see the following code.
>>
>> tests/generic/017:
>> ===
>> for (( BSIZE = 1024; BSIZE <= 4096; BSIZE *= 2 )); do
>>
>>          length=$(($BLOCKS * $BSIZE))
>>          case $FSTYP in
>>          xfs)
>>          _scratch_mkfs -b size=$BSIZE >> $seqres.full 2>&1
>>          ;;
>>          ext4)
>>          _scratch_mkfs -b $BSIZE >> $seqres.full 2>&1
>>          ;;
>>          esac
>>          _scratch_mount >> $seqres.full 2>&1
>> ===
>>
>> There is no btrfs here.
>
> Yes...
> That means it doesn't create a brand new fs and just uses the currently one.

Yes. I think so too.

Thanks,
Satoru

>
> Thanks.
>
>>
>> This test was moved to shared/005 to generic/017
>> at 21723cdbf303e031d6429f67fec9768750a5db7d.
>>
>> Original supported fs is here.
>> ===============================================================================
>> supported_fs xfs ext4
>> ===============================================================================
>>
>> I suspect that Lukas moved this test to generic/ by mistake or forgot to
>> add "$FSTYP == btrfs" case.
>>
>> Thanks,
>> Satoru
>>
>>> ---
>>>    tests/generic/017 | 8 ++++++++
>>>    1 file changed, 8 insertions(+)
>>>
>>> diff --git a/tests/generic/017 b/tests/generic/017
>>> index 13b7254..6495be5 100755
>>> --- a/tests/generic/017
>>> +++ b/tests/generic/017
>>> @@ -51,6 +51,14 @@ BLOCKS=10240
>>>
>>>    for (( BSIZE = 1024; BSIZE <= 4096; BSIZE *= 2 )); do
>>>
>>> +     # btrfs doesn't support block size smaller then page size
>>> +     if [ "$FSTYP" == "btrfs" ]; then
>>> +             if (( $BSIZE < `getconf PAGE_SIZE` )); then
>>> +                     echo "80"
>>> +                     continue
>>> +             fi
>>> +     fi
>>> +
>>>        length=$(($BLOCKS * $BSIZE))
>>>        case $FSTYP in
>>>        xfs)
>>>
>>
>
>
>


WARNING: multiple messages have this Message-ID (diff)
From: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
To: <fdmanana@gmail.com>
Cc: <fstests@vger.kernel.org>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Lukas Czerner <lczerner@redhat.com>
Subject: Re: [PATCH] generic/017: skip invalid block sizes for btrfs
Date: Mon, 23 Jun 2014 20:04:56 +0900	[thread overview]
Message-ID: <53A809D8.9010601@jp.fujitsu.com> (raw)
In-Reply-To: <CAL3q7H7PvNQi1W=gnbjSmJd-r3sR3FPs+qfdfCDH34R=eujHMw@mail.gmail.com>

Hi Filipe,

(2014/06/23 19:55), Filipe David Manana wrote:
> On Mon, Jun 23, 2014 at 11:48 AM, Satoru Takeuchi
> <takeuchi_satoru@jp.fujitsu.com> wrote:
>> Hi Filipe,
>>
>> (2014/06/23 19:28), Filipe David Borba Manana wrote:
>>> In btrfs the block size (called sector size in btrfs) can not be
>>> smaller then the page size. Therefore skip block sizes smaller
>>> then page size if the fs is btrfs, so that the test can succeed
>>> on btrfs (testing only with block sizes of 4kb on systems with a
>>> page size of 4Kb).
>>>
>>> Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
>>
>> I consider it doesn't work since this test is not for Btrfs.
>
> Did you try it out (together with the corresponding change for btrfs
> to support collapse range) or is just code analysis?

I commented it just by code analysis.

> For me it works.
>
>> Please see the following code.
>>
>> tests/generic/017:
>> ===
>> for (( BSIZE = 1024; BSIZE <= 4096; BSIZE *= 2 )); do
>>
>>          length=$(($BLOCKS * $BSIZE))
>>          case $FSTYP in
>>          xfs)
>>          _scratch_mkfs -b size=$BSIZE >> $seqres.full 2>&1
>>          ;;
>>          ext4)
>>          _scratch_mkfs -b $BSIZE >> $seqres.full 2>&1
>>          ;;
>>          esac
>>          _scratch_mount >> $seqres.full 2>&1
>> ===
>>
>> There is no btrfs here.
>
> Yes...
> That means it doesn't create a brand new fs and just uses the currently one.

Yes. I think so too.

Thanks,
Satoru

>
> Thanks.
>
>>
>> This test was moved to shared/005 to generic/017
>> at 21723cdbf303e031d6429f67fec9768750a5db7d.
>>
>> Original supported fs is here.
>> ===============================================================================
>> supported_fs xfs ext4
>> ===============================================================================
>>
>> I suspect that Lukas moved this test to generic/ by mistake or forgot to
>> add "$FSTYP == btrfs" case.
>>
>> Thanks,
>> Satoru
>>
>>> ---
>>>    tests/generic/017 | 8 ++++++++
>>>    1 file changed, 8 insertions(+)
>>>
>>> diff --git a/tests/generic/017 b/tests/generic/017
>>> index 13b7254..6495be5 100755
>>> --- a/tests/generic/017
>>> +++ b/tests/generic/017
>>> @@ -51,6 +51,14 @@ BLOCKS=10240
>>>
>>>    for (( BSIZE = 1024; BSIZE <= 4096; BSIZE *= 2 )); do
>>>
>>> +     # btrfs doesn't support block size smaller then page size
>>> +     if [ "$FSTYP" == "btrfs" ]; then
>>> +             if (( $BSIZE < `getconf PAGE_SIZE` )); then
>>> +                     echo "80"
>>> +                     continue
>>> +             fi
>>> +     fi
>>> +
>>>        length=$(($BLOCKS * $BSIZE))
>>>        case $FSTYP in
>>>        xfs)
>>>
>>
>
>
>


  reply	other threads:[~2014-06-23 11:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23 10:28 [PATCH] generic/017: skip invalid block sizes for btrfs Filipe David Borba Manana
2014-06-23 10:48 ` Satoru Takeuchi
2014-06-23 10:48   ` Satoru Takeuchi
2014-06-23 10:55   ` Filipe David Manana
2014-06-23 11:04     ` Satoru Takeuchi [this message]
2014-06-23 11:04       ` Satoru Takeuchi
2014-06-23 11:46   ` Brendan Hide
2014-06-23 12:35 ` Lukáš Czerner
2014-06-23 14:09   ` Lukáš Czerner
2014-06-23 17:39     ` Filipe David Manana
2014-06-24  4:26     ` Dave Chinner
2014-06-24  5:28       ` Lukáš Czerner
2014-06-23 22:23 ` Zach Brown
2014-06-24  4:58 ` Roman Mamedov

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=53A809D8.9010601@jp.fujitsu.com \
    --to=takeuchi_satoru@jp.fujitsu.com \
    --cc=fdmanana@gmail.com \
    --cc=fstests@vger.kernel.org \
    --cc=lczerner@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.