Daniel Moore wrote:
> Russell Cattelan writes:
>
> => Yes I would guess so.
> => Setting the length to the count is not what you want to do.
> => The buffer_length must remain set to whatever size the page_buf was
> => set up with.
>
> I don't think I'm doing that.
#define XFS_BUF_SET_SIZE(bp, cnt) \
! ((bp)->pb_count_desired = (bp)->pb_buffer_length =
cnt)
> Currently pb_count_desired either doesn't
> get set (it's often zero)
> or it gets set to some masked version of
It isn't used for user data... for meta data it should set...
from pagebuf_get
/* For inodes without mapping functions we can always fill in
* the block number now.
*/
if (PB_BMAP_FUNC(pb) == NULL) {
/* Use identity mapping */
pb->pb_bn = pb->pb_file_offset >> PB_SECTOR_BITS(pb);
pb->pb_count_desired =
pb->pb_buffer_length & ~(PB_SECTOR_SIZE(pb) - 1);
}
If you put the printk in from pagebuf_segment_apply
you will see the count and lenght values during recovery.
> pb_buffer_length. The changes to xfs_buf.h make sure that
> pb_count_desired gets updated whenever pb_buffer_length does and some
> changes to page_buf.c stop it setting pb_count_desired to the masked value.
>
>
> => The count_desired is set at pagebuf_get time and will remain equal to
> => length as long as it isn't reset... as in the case of the log write
> => There is also a possibility that shrinking the length will cause
> => the page_buf to lose pages.... I'm not sure about I'll have to look.
>
> I saw some funny stuff when I tried your patch which (from memory)
> set kb->count to pb_count_desired... I suspect that causes loss...
Hmm shouldn't; the kb->count is only used for the io loop, the pages
are a array off the kiovec and should be free'ed all in one go.
Like I said I didn't have much time to test it, I may have missed something.
I look closer.
I think we need to keep the length and the count uniq... if we
can set them to one another then we can get rid of one?!
Tomorrow morning... I need some sleep.
>
>
> => I'll look at the non kiobuf case it shouldn't be to hard to fix.
>
> That'd be great. thanks...
>
> -----------------------------------------------------
> Daniel Moore dxm@xxxxxxx
> R&D Software Engineer Phone: +61-3-98348209
> SGI Performance Tools Group Fax: +61-3-98132378
> -----------------------------------------------------
--
Russell Cattelan
cattelan@xxxxxxxxxxx
|