On 5/11/11 2:10 AM, Surbhi Palande wrote: > While the fsstress background writes are busy dirtying the page cache, if a > fsfreeze happens then the background writes should stall. A sync should then > not have any data to sync to the FS. If it does have any data to sync then > sync will cause a deadlock by holding the s_umount write semaphore and waiting > in the wait queue for the FS to thaw, whereas the F.S can never thaw without > getting the s_umount write semaphore. > > Signed-off-by: Surbhi Palande <surbhi.palande@xxxxxxxxxxxxx> Seems ok to me. In the future, when sending xfstests patches, if you can add "xfstests" to the subject, and cc: the xfs list, it'd be great. I presume that this test does fail for you without your fixes? I'll see if anyone on the xfs list has comments and if not, I can check this in. Thanks, -Eric > --- > 068 | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/068 b/068 > index 82c1a4e..b9ac58d 100755 > --- a/068 > +++ b/068 > @@ -101,6 +101,11 @@ do > tee -a $seq.full > sleep 2 > > + # there should be nothing to sync at this point. This may hang in case > + # of fsstress background writes dirtying the page cache while the F.S is frozen > + sync & > + sleep 2 > + > echo "*** thawing \$SCRATCH_MNT" | tee -a $seq.full > xfs_freeze -u "$SCRATCH_MNT" | tee -a $seq.full > [ $? != 0 ] && echo xfs_freeze -u "$SCRATCH_MNT" failed | \ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
