[Gluster-users] "mismatching layouts" errors after expanding volume

[Jeff Darcy]

Following up on the previous reply...

On 02/22/2012 02:52 AM, Dan Bretherton wrote:
> [2012-02-16 22:59:42.504907] I
> [dht-layout.c:682:dht_layout_dir_mismatch] 0-atmos-dht: subvol:
> atmos-replicate-0; inode layout - 0 - 0; disk layout - 9203501
> 34 - 1227133511
> [2012-02-16 22:59:42.534399] I [dht-common.c:524:dht_revalidate_cbk]
> 0-atmos-dht: mismatching layouts for /users/rle/TRACKTEMP/TRACKS

On 02/22/2012 09:19 AM, Jeff Darcy wrote:
> OTOH, the log entries below do seem to indicate that there's something going on
> that I don't understand.  I'll dig a bit, and let you know if I find anything
> to change my mind wrt the safety of restoring write access.

The two messages above are paired, in the sense that the second is inevitable
after the first. The "disk layout" range shown in the first is exactly what I
would expect for subvolume 3 out of 0-13. That means the trusted.glusterfs.dht
value on disk seems reasonable. The corresponding in-memory "inode layout"
entry has the less reasonable value of all zero. That probably means we failed
to fetch the xattr at some point in the past. There might be something earlier
in your logs - perhaps a message about "holes" and/or one specifically
mentioning that subvolume - to explain why.

The good news is that this should be self-repairing. Once we get these
messages, we try to re-fetch the layout information from all subvolumes. If
*that* failed, we'd see more messages than those above. Since the on-disk
values seem OK and revalidation seems to be succeeding, I would say these
messages probably represent successful attempts to recover from a transient
brick failure, and that does *not* change what I said previously.