linux-nilfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
To: "konishi.ryusuke@gmail.com" <konishi.ryusuke@gmail.com>
Cc: "linux-nilfs@vger.kernel.org" <linux-nilfs@vger.kernel.org>,
	"slava@dubeyko.com" <slava@dubeyko.com>
Subject: RE: Status of running xfstests for NILFS2
Date: Tue, 18 Nov 2025 23:23:25 +0000	[thread overview]
Message-ID: <66926bf9a9cb9488dd5f8fe9493d366fb3fd7e66.camel@ibm.com> (raw)
In-Reply-To: <CAKFNMok6sj9EPgCBSn=3Uc1ze51jbPH69xEXQtFTej3B1JcTLQ@mail.gmail.com>

Hi Ryusuke,

On Sun, 2025-11-16 at 00:44 +0900, Ryusuke Konishi wrote:
> Hi Viacheslav,
> 
> On Fri, Nov 14, 2025 at 9:19 AM Viacheslav Dubeyko wrote:
> > 
> > Hi Ryusuke,
> > 
> > I did run the xfstests suite for NILFS2. As far as I can see, there are 156
> > failed tests and I needed to exclude 2 tests from running.
> > 
> > sudo ./check -g auto -E ./my_exclude.txt
> > FSTYP         -- nilfs2
> > PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc3+ #93 SMP
> > PREEMPT_DYNAMIC Wed Nov 12 14:37:49 PST 2025
> > MKFS_OPTIONS  -- /dev/loop51
> > MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
> > 
> > <skipped>
> > 
> > Failures: generic/003 generic/040 generic/041 generic/068 generic/074
> > generic/075 generic/078 generic/080 generic/086 generic/092 generic/097
> > generic/099 generic/100 generic/103 generic/105 generic/109 generic/112
> > generic/117 generic/121 generic/122 generic/124 generic/127 generic/129
> > generic/131 generic/136 generic/177 generic/182 generic/192 generic/215
> > generic/221 generic/237 generic/241 generic/245 generic/246 generic/247
> > generic/248 generic/249 generic/251 generic/255 generic/257 generic/258
> > generic/260 generic/285 generic/286 generic/307 generic/309 generic/310
> > generic/313 generic/316 generic/318 generic/319 generic/322 generic/337
> > generic/348 generic/360 generic/363 generic/365 generic/375 generic/376
> > generic/377 generic/394 generic/403 generic/404 generic/408 generic/409
> > generic/410 generic/411 generic/420 generic/425 generic/428 generic/430
> > generic/431 generic/432 generic/433 generic/436 generic/437 generic/438
> > generic/439 generic/443 generic/444 generic/445 generic/448 generic/469
> > generic/471 generic/478 generic/483 generic/484 generic/485 generic/486
> > generic/489 generic/490 generic/503 generic/504 generic/510 generic/512
> > generic/516 generic/519 generic/523 generic/529 generic/533 generic/535
> > generic/537 generic/539 generic/547 generic/553 generic/555 generic/563
> > generic/565 generic/567 generic/568 generic/571 generic/585 generic/589
> > generic/590 generic/607 generic/610 generic/611 generic/614 generic/616
> > generic/618 generic/629 generic/631 generic/632 generic/634 generic/637
> > generic/638 generic/639 generic/640 generic/650 generic/676 generic/690
> > generic/695 generic/697 generic/704 generic/706 generic/712 generic/713
> > generic/715 generic/718 generic/719 generic/723 generic/724 generic/725
> > generic/728 generic/732 generic/736 generic/738 generic/741 generic/742
> > generic/749 generic/754 generic/758 generic/759 generic/763 generic/764
> > generic/771
> > Failed 156 of 767 tests
> > 
> > I needed to exclude generic/740 and generic/753. I am not completely sure what
> > is wrong with generic/740 (it could be glitch on my side). But generic/753 fills
> > the system log with bunch of errors:
> > 
> > 2025-11-12T18:36:24.171533-08:00 hfsplus-testing-0001 root: run xfstest
> > generic/753
> > 2025-11-12T18:36:24.175432-08:00 hfsplus-testing-0001 kernel: run fstests
> > generic/753 at 2025-11-12 18:36:24
> > 2025-11-12T18:36:24.243745-08:00 hfsplus-testing-0001 systemd[1]: Started
> > fstests-generic-753.scope - /usr/bin/bash -c "test -w
> >  /proc/self/oom_score_adj && echo 250 > /proc/self/oom_score_adj; exec
> > ./tests/generic/753".
> > 2025-11-12T18:36:26.068288-08:00 hfsplus-testing-0001 kernel: NILFS (dm-0):
> > segctord starting. Construction interval = 5 second
> > s, CP frequency < 30 seconds
> > 2025-11-12T18:36:26.082067-08:00 hfsplus-testing-0001 nilfs_cleanerd[763354]:
> > start
> > 2025-11-12T18:36:26.082949-08:00 hfsplus-testing-0001 nilfs_cleanerd[763354]:
> > pause (clean check)
> > 2025-11-12T18:36:28.111323-08:00 hfsplus-testing-0001 kernel: Buffer I/O error
> > on dev dm-0, logical block 2621424, async page r
> > ead
> ...
> > 2025-11-12T18:36:28.398430-08:00 hfsplus-testing-0001 kernel: NILFS (dm-0): I/O
> > error writing log (start-blocknr=49152, block-c
> > ount=418) in segment 24
> > 
> > I need to double check but likewise error happens not only for generic/753 test-
> > case. As far as I can see, other test-cases also triggered such issue. But
> > namely generic/753 hangs infinitely with such error messages.
> 
> Okay, I'll take a look at xfstests/753 and related tests.
> To be honest, I've been busy lately and haven't had much time, but I
> hope to have some time after Tuesday.
> 

It's OK. We are not in a hurry. And it's a lot of tests are failing right now.

> > I believe it makes sense to account all of these issues in some tracking system
> > before starting to fix it. Are you using any tracking system for NILFS2 issues?
> > Frankly speaking, I am using github's tracking system for HFS/HFS+ issues [1].
> > It's simple enough but I don't need in more complex system for this right now.
> > So, what do you think about some bug tracking system for NILFS2?
> 
> We don't have a central BTS that we operate. We did have one during
> development, but it wasn't open and is no longer usable.
> So we either use a mailing list or syzbot, and although I don't
> particularly want or use it, nilfs-utils' github plays a role in that
> regard.
> 
> As for managing issues raised by xfstests, as you say, I agree that a
> proper BTS is needed.
> However, something that is heavily web-dependent like github doesn't
> work well with mailing lists, so I'm honestly not sure if it's a good
> solution for this project, apart from github-based development
> projects.
> 
> In this regard, I think syzbot is good, because email exchanges
> naturally become a response history and are easily shared with the
> mailing list.
> Unfortunately, it doesn't cover the entire issue tracking.
> 
> If you're going to use github for issue tracking, it would be better
> if it could be set up to be highly compatible with mailing lists.
> What do you think?
> 

I like your suggestion. But what particular BTS candidate do you have in mind?

> Personally, I'd like to see a better issue tracking system that can
> bridge with email-driven workflows, flexibly connect with AI, and
> support OSS activity, but I don't know of anything other than GitHub
> that I think would be suitable.
> 

So, this is my worry that we could not find good and free BTS. And, finally, we
will need to use anything not very good but accessible right now. :)

> > As far as I can see, syzbot still reports about 5 issues for NILFS2 [2]. So, it
> > makes sense to account these issues too.
> 
> I think it's fine to use it solely for issue management purposes, as
> long as it doesn't result in double management.
> Therefore, I think we should make sure to always jump to syzbot from
> GitHub, etc., as an index, and make good use of syzbot's workflow as
> is.
> 

I am simply thinking to have some tracking system that can account all NILFS2
issues. The syzbot has its own tracking system. But, from my point of view, it
makes sense to account syzbot issues like sub-class of issues.

> > I am working on Kunit-based unit-tests for CephFS, HFS/HFS+, SSDFS. So, I
> > believe that NILFS2 could benefit also from having likewise unit-tests. How do
> > you feel about it?
> 
> As for using Kunit, I'm not sure how to effectively extract unit tests
> while avoiding I/O and page caching.
> Rather, what parts of HFS/HFS+ do you extract and write tests for?
> 

Usually, unit-tests check correctness of functions' logic in isolated
environment. So, unit-test logic can create local fake object(s) that will not
involve complex logic of the rest kernel functionality. Most frequently, file
system can implement multiple internal primitives (like bitmap, b-tree, etc).
And unit-tests check this internal functionality likewise it can be called by
other file system's part or by VFS. I've found that unit-testing is very useful
frequently. It cannot detect all bugs but it can find simple but not always
trivial issues in file system's code.

> > 
> > I am going to attend LPC 2025 in Tokyo (December 11 - 13, 2025). And I am
> > planning to have 2 free days before conference start. Are you planning to attend
> > LPC 2025?
> 
> I'm not participating. But welcome to Japan ;)
> 

Thanks. :) I hope I will not be lost there. :)

> It might have been a good opportunity to meet you. However, since I'm
> not a native speaker, I honestly find email communication more
> efficient than face-to-face communication.
> Also, while it's not a health issue, personal circumstances have been
> making it difficult for me to move around freely recently.
> 
> Well, it's not like I can't come at all, so if you still want to have
> a face-to-face discussion for the future, please let me know via
> private message.
> 

OK. I see. No problem. :)

Thanks,
Slava.

      reply	other threads:[~2025-11-18 23:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-14  0:19 Status of running xfstests for NILFS2 Viacheslav Dubeyko
2025-11-15 15:44 ` Ryusuke Konishi
2025-11-18 23:23   ` Viacheslav Dubeyko [this message]

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=66926bf9a9cb9488dd5f8fe9493d366fb3fd7e66.camel@ibm.com \
    --to=slava.dubeyko@ibm.com \
    --cc=konishi.ryusuke@gmail.com \
    --cc=linux-nilfs@vger.kernel.org \
    --cc=slava@dubeyko.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).