public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: Zirong Lang <zlang@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Dave Chinner <david@fromorbit.com>, Eryu Guan <eguan@redhat.com>,
	fstests@vger.kernel.org, sandeen@redhat.com, cem@redhat.com
Subject: Re: [PATCH v4 2/2] xfs/006: new case to test xfs fail_at_unmount error handling
Date: Tue, 21 Jun 2016 23:17:20 -0400 (EDT)	[thread overview]
Message-ID: <1177627164.497649.1466565440350.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <696ce99d-dfa9-70a0-29c2-e605a3d71285@sandeen.net>



----- 原始邮件 -----
> 发件人: "Eric Sandeen" <sandeen@sandeen.net>
> 收件人: "Zirong Lang" <zlang@redhat.com>, "Dave Chinner" <david@fromorbit.com>
> 抄送: "Eryu Guan" <eguan@redhat.com>, fstests@vger.kernel.org, sandeen@redhat.com, cem@redhat.com
> 发送时间: 星期三, 2016年 6 月 22日 上午 11:04:55
> 主题: Re: [PATCH v4 2/2] xfs/006: new case to test xfs fail_at_unmount error handling
> 
> On 6/21/16 8:42 PM, Zirong Lang wrote:
> > Hi Dave
> > 
> > ----- 原始邮件 -----
> >> 发件人: "Dave Chinner" <david@fromorbit.com>
> >> 收件人: "Eryu Guan" <eguan@redhat.com>
> >> 抄送: "Zorro Lang" <zlang@redhat.com>, fstests@vger.kernel.org,
> >> sandeen@redhat.com, cem@redhat.com
> >> 发送时间: 星期三, 2016年 6 月 22日 上午 8:00:40
> >> 主题: Re: [PATCH v4 2/2] xfs/006: new case to test xfs fail_at_unmount error
> >> handling
> >>
> >> On Tue, Jun 21, 2016 at 03:08:18PM +0800, Eryu Guan wrote:
> >>> On Mon, Jun 20, 2016 at 09:24:33PM +0800, Zorro Lang wrote:
> >>>> +# real QA test starts here
> >>>> +_supported_fs xfs
> >>>> +_supported_os Linux
> >>>> +_require_dm_target error
> >>>> +_require_scratch
> >>>> +
> >>>> +_scratch_mkfs > $seqres.full 2>&1
> >>>> +_require_fs_sysfs $SCRATCH_DEV error/fail_at_unmount
> >>>
> >>> Usually we call _require_xxx before mkfs and do the real test, a comment
> >>> to explain why we need to mkfs first would be good.
> >>
> >> Ok, so why do we need to test the scratch device for this
> >> sysfs file check? We've already got the test device mounted, and
> >> filesystems tend to present identical sysfs control files for all
> >> mounted filesystems.
> >>
> >> i.e. this _require_fs_sysfs() function could just drop the device
> >> and check the test device for whether the sysfs entry exists. If it
> >> doesn't, then the scratch device isn't going to have it, either.
> > 
> > Hmm... at first I thought about if I should use TEST_DEV to do
> > _require_fs_sysfs
> > checking. But I'm not sure if different devices maybe bring different sysfs
> > attributes in, if someone make a special device in one case? So I give one
> > more
> > argument about device name.
> 
> Sorry, I was kind of thinking this as well on my first review, but I let it
> pass.
> 
> I would say that for now, let's just use TEST_DEV.  There is no reason to
> code
> around "what-if" scenarios.  If a filesystem ends up needing a special mkfs
> or mount option to expose a sysfs tunable in the future, we can add a device
> name
> at that point. Until then, I don't think there is any reason, and the "mkfs
> first,
> then require" is definitely a little bit out of the ordinary.

Sorry, I should follow your first review suggestion. I will change to use TEST_DEV:)

Thanks,
 -Zorro

> 
> -Eric
> 

  reply	other threads:[~2016-06-22  3:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-20 13:24 [PATCH v4 1/2] common/rc: add functions to check or write objects under /sys/fs/$FSTYP Zorro Lang
2016-06-20 13:24 ` [PATCH v4 2/2] xfs/006: new case to test xfs fail_at_unmount error handling Zorro Lang
2016-06-21  7:08   ` Eryu Guan
2016-06-22  0:00     ` Dave Chinner
2016-06-22  1:42       ` Zirong Lang
2016-06-22  3:04         ` Dave Chinner
2016-06-22  3:15           ` Zirong Lang
2016-06-22  3:04         ` Eric Sandeen
2016-06-22  3:17           ` Zirong Lang [this message]
2016-06-21  6:54 ` [PATCH v4 1/2] common/rc: add functions to check or write objects under /sys/fs/$FSTYP Eryu Guan

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=1177627164.497649.1466565440350.JavaMail.zimbra@redhat.com \
    --to=zlang@redhat.com \
    --cc=cem@redhat.com \
    --cc=david@fromorbit.com \
    --cc=eguan@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=sandeen@sandeen.net \
    /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