On Thu, Dec 11, 2014 at 03:13:23PM +1100, Dave Chinner wrote:
> On Wed, Dec 10, 2014 at 09:25:18PM -0500, Theodore Ts'o wrote:
> > It's possible based on a race conditions (and possibly the version of
> > coreutils which supplies /usr/bin/yes) that commands of the form:
> >
> > yes | $MKFS_PROG ...
> >
> > will end up causing the following failure:
>
> What race conditions?
It looks like under some circumstances, mkfs reads from stdin and then
exits quickly; in the mean time, since the pipe has read from, yes
then tries to send more "y\n" to stdout, and then it gets an EPIPE
error and complains.
> But thats indicative that something failed and you need to analyse
> the reason, yes? So AFAICT this is deisred behaviour, and hiding the
> error will actually hide other failures, right?
No, I don't think anything fails; it's perfectly OK that mkfs can read
from stdin and then exit very quickly. It seems to happen primarily
when we're running a test where mkfs can exit quickly enough to hit
this race.
> I'd highly recommend you add ext4 specific mkfs branches so you can
> use the non-interactive/force mkfs flags so that "yes |" is not
> necessary for your (and everyone elses ext4) test environments.
Sure, I'd be happy to add a ext2/3/4 specific mkfs branch. Does any
other file system's mkfs try to do interactive I/O? If so, then they
could hit this too, so I think the "yes 2> /dev/null | ..."
formulation is still a good thing to do. If not, maybe we should be
removing the "yes | ..." construct entirely, since it's pretty ugly
IMHO.
Cheers,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
