I understand that. I am looking to switch the order in the name. As in, N<block# in hex>NULL<parent# in bin>. Maybe change N to T to prevent confusion.
Any harm in the above? The issue is not with debugfs but to help cull the number of tcpdumps to wade thru. Mark Fasheh wrote: > On Wed, Apr 16, 2008 at 11:29:22AM -0700, Sunil Mushran wrote: > >> Not both in hex. I meant block# in hex and parent in binary. >> The only clash this way will be for hard links. >> > > Right, what I meant is that we can't print both in hex due to size > constraints. So, one was kept in hex and the other in binary. In theory, > they could have both been binary but I figured that we might as well have > *something* to printf: > > /* > * Unfortunately, the standard lock naming scheme won't work > * here because we have two 16 byte values to use. Instead, > * we'll stuff the inode number as a binary value. We still > * want error prints to show something without garbling the > * display, so drop a null byte in there before the inode > * number. A future version of OCFS2 will likely use all > * binary lock names. The stringified names have been a > * tremendous aid in debugging, but now that the debugfs > * interface exists, we can mangle things there if need be. > * > * NOTE: We also drop the standard "pad" value (the total lock > * name size stays the same though - the last part is all > * zeros due to the memset in ocfs2_lock_res_init_once() > */ > > > >> I ran into this while debugging the extra downconvert on dentry locks. >> Even if I teach the ocfs2 dissector to handle the dentry lock, I won't >> be able to trim down enough the number of tcpdumps to wade thru (using >> grep, that is). Block# in hex will help. >> > > Well, there's not really much we can do for what's on the wire. The debugfs > interface at least seems to print it in hex for you. > --Mark > > -- > Mark Fasheh > _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com http://oss.oracle.com/mailman/listinfo/ocfs2-devel
