[PATCH 06/13] xfs: xfs_sync_data is redundant.

[Mark Tinguely]

On 10/01/12 15:14, Brian Foster wrote:
<deletes by mt>
> Heads up... I was doing some testing against my eofblocks set rebased
> against this patchset and I'm reproducing a new 273 failure. The failure
> bisects down to this patch.
>
> With the bisection, I'm running xfs top of tree plus the following patch:
>
> xfs: only update the last_sync_lsn when a transaction completes
>
> ... and patches 1-6 of this set on top of that. i.e.:
>
> xfs: xfs_sync_data is redundant.
> xfs: Bring some sanity to log unmounting
> xfs: sync work is now only periodic log work
> xfs: don't run the sync work if the filesystem is read-only
> xfs: rationalise xfs_mount_wq users
> xfs: xfs_syncd_stop must die
> xfs: only update the last_sync_lsn when a transaction completes
> xfs: Make inode32 a remountable option
>
> This is on a 16p (according to /proc/cpuinfo) x86-64 system with 32GB
> RAM. The test and scratch volumes are both 500GB lvm volumes on top of a
> hardware raid. I haven't looked into this at all yet but I wanted to
> drop it on the list for now. The 273 output is attached.
>
> Brian

  <deletes by mt>
>
>
> 273.out.bad
>
>
> QA output created by 273
> ------------------------------
> start the workload
> ------------------------------
> _porter 31 not complete
> _porter 79 not complete
> _porter 149 not complete_porter 74 not complete
> _porter 161 not complete
> _porter 54 not complete
> _porter 98 not complete
> _porter 99 not complete
> _porter 167 not complete
> _porter 76 not complete
> _porter 45 not complete
> _porter 152 not complete
> _porter 173 not complete_porter 24 not complete

  <deletes by mt>

I see it too on a single machine. It looks like an interaction between 
patch 06 and the "...update the last_sync_lsn...".

I like the "...update the last_sync_lsn ..." patch because it fixes the 
"xlog_verify_tail_lsn: tail wrapped" and "xlog_verify_tail_lsn: ran out 
of log space" messages that I am getting on that machine.

--Mark.