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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
