All of lore.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 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.