Thank you for your fast response.
Timothy Shimmin <tes@xxxxxxxxxxxxxxxxxxxxxxx> wrote,
> Do you have top of tree cmds and kernel ?
In this morning, I could not do a CVSup too as someone reported,
so, I tried QA suite 022 three times using the CVS kernel and
cmds which were updated on last friday. Then, all of them have
been passed :-) I'll try more tonight.
> cmd/xfstests/022 has failed reliably for us in recent times,
> but over the last few days (Nathan looks after our QA he'll
> know exactly when), it has been passing reliably.
> I have been meaning to look into 022 and 024 but only
> looked at 024 recently.
> I do not know exactly what has changed to cause 022
> to pass now.
>
> xfsdump uses an xfs feature called bulkstat'ing to speed up
> the stat'ing of all the inodes of the file system.
> However, it apparently snapshots the info from the disk blocks
> instead of going through the in-core data structures.
> This means that if this data is not flushed to disk completely
> when xfsdump is running then it won't have the latest stat
> information.
Hmmm... I see.
> So for the QA testing, after populating an FS I would call
> _stable_fs to do sync and sleep. However, I didn't do this
> in every case such as the case where I append to files to
> test out incremental dumps in 024.
> So I added the call to _stable_fs in common.dump for this.
> I also changed from sync/sleep to umount/mount to be sure
> that the changes are flushed to disk before proceeding.
> So this may have also affected 022.
> However, by putting back the old behaviour I was still unable
> to get 022 to fail.
I would like to know that whether it is correct way or
workaround to dump the XFS file system which requires preceding
unmount and mount, not only for QA suite but also on a
production environment.
Could you explain me about this?
Best Regards,
Takayuki
|