On Mon, 25 Apr 2011 05:28:10 +0000 (UTC), Ivan Telichko wrote:
> > If you are still keeping the partition, could you test if the
> > following patch makes a difference ?
>
> No observable difference, patched cleanerd still dies the same way.
>
> There are more messages in the log if I start nilfs_cleanerd by hand:
>
> Apr 26 02:54:21 nilfs_cleanerd[4734]: start
> Apr 26 02:54:21 nilfs_cleanerd[4734]: pause (clean check)
> Apr 26 02:54:21 nilfs_cleanerd[4734]: resume (clean check)
> Apr 26 02:54:21 nilfs_cleanerd[4734]: ncleansegs = 244
> Apr 26 02:54:21 nilfs_cleanerd[4734]: 4 segments selected to be cleaned
> Apr 26 02:54:21 nilfs_cleanerd[4734]: protected checkpoints = [69325,69425]
> (protection period >= 1303760661)
> Apr 26 02:54:22 kernel: nilfs_ioctl_move_inode_block: conflicting data buffer:
> ino=97606, cno=281, offset=14, blocknr=3526535, vblocknr=1555981
> Apr 26 02:54:22 kernel: NILFS: GC failed during preparation: cannot read
> source blocks: err=-17
> Apr 26 02:54:23 nilfs_cleanerd[4734]: cannot clean segments: File exists
> Apr 26 02:54:23 nilfs_cleanerd[4734]: shutdown
Thanks,
According to the log, the same data block (i.e. blocks having the same
inode number, the same block offset, and the same checkpoint number)
appeared twice in a segment, and this causes a conflict of buffer on
GC page cache.
Umm, we need more information to narrow down this.
Could you take summaries of the segment 1721 and its adjacent segments ?
Summaries of a segment can be obtained as follows:
# dumpseg /dev/sda6 1721
~~~~~~~~~
your block device
where the segment 1721 contains the block 3526535 (a segment consists
of 2048 blocks by default). It doesn't contain any user private data.
Regards,
Ryusuke Konishi
> ---
>
> Regards,
> Ivan Telichko
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
