linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ritesh Harjani <riteshh@linux.ibm.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>, jack@suse.cz
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	mbobrowski@mbobrowski.org
Subject: Re: [RFC 0/5] Ext4: Add support for blocksize < pagesize for dioread_nolock
Date: Tue, 29 Oct 2019 12:49:24 +0530	[thread overview]
Message-ID: <20191029071925.60AABA405B@b06wcsmtp001.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <20191023232614.GB1124@mit.edu>

Hello Ted,

I tried reproducing issue generic/273 & generic/476 on vanilla 5.4-rc4.
I could see that both of these could be very well reproduced with same
symptoms on vanilla 5.4-rc4 as well with 1K blocksize on x86
(i.e. without this patch series).

Although when I tried reproducing generic/273 & generic/476 on ppc64le
(64K pagesize & 4K blocksize) both with & without these patches,
I could not reproduce this issue on this platform.

As of now, I haven't gone deep into analyzing failure for generic/476,
but generic/273 seems to be failing with 1K blocksize because of
"No space left in device". This is happening, since the free inode count
is exhausted (mostly only with 1K blocksize).
I will have to look into this on whether it needs any xfstest fixing or 
if there is something else going on.


So it looks like these failed tests does not seem to be because of this
patch series. But these are broken in general for at least 1K blocksize.

Also as an FYI, it seems generic/388 is also broken for blocksize <
pagesize for both platforms. So I will be planning to look into these 
failures (generic/273 generic/388 generic/476) in parallel.


Do you think we can work on these failing tests separately, since it 
does not look to be failing because of these patches and go ahead in
reviewing this current patch series?


-ritesh


On 10/24/19 4:56 AM, Theodore Y. Ts'o wrote:
> Hi Ritesh,
> 
> I haven't had a chance to dig into the test failures yet, but FYI....
> when I ran the auto test group in xfstests, I saw failures for
> generic/219, generic 273, and generic/476 --- these errors did not
> show up when running using a standard 4k blocksize on x86, and they
> also did not show up when running dioread_nolock using a 4k blocksize.
> 
> So I tried running "generic/219 generic/273 generic/476" 30 time
> using in a Google Compute Engine VM, using gce-xfstests, and while I
> wasn't able to get generic/219 to fail when run in isolation,
> generic/273 seems to fail quite reliably, and generic/476 about a
> third of the time.
> 
> How much testing have you done with these patches?
> 
> Thanks,
> 
> 							- Ted
> 
> TESTRUNID: tytso-20191023144956
> KERNEL:    kernel 5.4.0-rc3-xfstests-00005-g39b811602906 #1244 SMP Wed Oct 23 11:30:25 EDT 2019 x86_64
> CMDLINE:   --update-files -C 30 -c dioread_nolock_1k generic/219 generic/273 generic/476
> CPUS:      2
> MEM:       7680
> 
> ext4/dioread_nolock_1k: 90 tests, 42 failures, 10434 seconds
>    Failures: generic/273 generic/273 generic/273 generic/273
>      generic/476 generic/273 generic/476 generic/273 generic/273
>      generic/273 generic/476 generic/273 generic/476 generic/273
>      generic/476 generic/273 generic/476 generic/273 generic/273
>      generic/273 generic/273 generic/273 generic/476 generic/273
>      generic/273 generic/273 generic/273 generic/476 generic/273
>      generic/476 generic/273 generic/476 generic/273 generic/273
>      generic/273 generic/273 generic/273 generic/273 generic/273
>      generic/476 generic/273 generic/476
> Totals: 90 tests, 0 skipped, 42 failures, 0 errors, 10434s
> 


  parent reply	other threads:[~2019-10-29  7:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16  7:37 [RFC 0/5] Ext4: Add support for blocksize < pagesize for dioread_nolock Ritesh Harjani
2019-10-16  7:37 ` [RFC 1/5] ext4: keep uniform naming convention for io & io_end variables Ritesh Harjani
2019-10-25 13:07   ` Jan Kara
2019-10-16  7:37 ` [RFC 2/5] ext4: Add API to bring in support for unwritten io_end_vec conversion Ritesh Harjani
2019-10-16  7:37 ` [RFC 3/5] ext4: Refactor mpage_map_and_submit_buffers function Ritesh Harjani
2019-10-16  7:37 ` [RFC 4/5] ext4: Add support for blocksize < pagesize in dioread_nolock Ritesh Harjani
2019-10-16  7:37 ` [RFC 5/5] ext4: Enable blocksize < pagesize for dioread_nolock Ritesh Harjani
2019-10-23 23:26 ` [RFC 0/5] Ext4: Add support for " Theodore Y. Ts'o
2019-10-24  1:12   ` Ritesh Harjani
2019-10-29  7:19   ` Ritesh Harjani [this message]
2019-11-03 19:16     ` Theodore Y. Ts'o
2019-11-04 10:16       ` Matthew Bobrowski
2019-11-04 10:37         ` Ritesh Harjani
2019-11-04 10:49           ` Matthew Bobrowski
2019-11-04 16:08             ` Theodore Y. Ts'o
2019-11-04 10:43       ` Ritesh Harjani
2019-11-04 11:59       ` Ritesh Harjani
2019-11-06 17:23 ` Jan Kara
2019-11-07 11:15   ` Ritesh Harjani

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=20191029071925.60AABA405B@b06wcsmtp001.portsmouth.uk.ibm.com \
    --to=riteshh@linux.ibm.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mbobrowski@mbobrowski.org \
    --cc=tytso@mit.edu \
    /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).