----- Original Message ----- | > + lh2->lh_jinode = cpu_to_be64(GFS2_I(sdp->sd_jdesc->jd_inode)->i_no_addr); | This is still writing the wrong inode number for recovery headers. | Please check that all the fields are correct in both the local and | remote journal cases. It would probably make more sense to pass the | relevant gfs2_jdesc to this function in order to avoid this kind of | mistake in the future, | | Steve.
Hi, Actually, I did this intentionally. I suppose it depends on the intent and whether we consider this debug info, recovery hints, or hints for fsck. Right now it's just debug info, and I thought it would be more useful to put the journal inode of the node performing the recovery. In other words, a bread crumb, a smoking gun, or "who dunnit." IOW, which node was responsible for writing the log header. But since GFS2 doesn't typically know its own node number in the cluster, but it does know which journal is assigned for its general use, and that's always written into the dmesg, syslog, etc., I thought it would be more useful for file system forensics. The patch already saves the absolute block address of the log header, from which we can deduce the journal's inode address based on the inode's mapping. But what was the original intent? I suppose we could keep both, since all nodes look up the inode of every journal. Thoughts? Bob Peterson
