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.
