[Ocfs2-devel] dentry locks

[Ocfs2-devel] dentry locks

[Sunil Mushran]

Any reason the dentry lock has parent# in string and block# in binary?

The reverse will make it easier to grep for dentry locks in tcpdumps.

Sunil

[Ocfs2-devel] dentry locks

[Mark Fasheh]

On Tue, Apr 15, 2008 at 06:54:27PM -0700, Sunil Mushran wrote:
> Any reason the dentry lock has parent# in string and block# in binary?

Afair, there were space constraints to printing them both in hex.
	--Mark

--
Mark Fasheh

[Ocfs2-devel] dentry locks

[Sunil Mushran]

Not both in hex. I meant block# in hex and parent in binary.
The only clash this way will be for hard links.

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.

Mark Fasheh wrote:
> On Tue, Apr 15, 2008 at 06:54:27PM -0700, Sunil Mushran wrote:
>   
>> Any reason the dentry lock has parent# in string and block# in binary?
>>     
>
> Afair, there were space constraints to printing them both in hex.
> 	--Mark
>
> --
> Mark Fasheh
>   

[Ocfs2-devel] dentry locks

[Mark Fasheh]

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] dentry locks

[Sunil Mushran]

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] dentry locks

[Mark Fasheh]

On Wed, Apr 16, 2008 at 12:10:03PM -0700, Sunil Mushran wrote:
> 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?

Yeah, it breaks the protocol  ;)

If you're just looking to make a change on your local nodes for debugging
purposes, I see no reason why switching the order should break anything.

What do the tcp dumps look like? Is it raw binary data, is the binary
converted into hex, etc?
	--Mark

--
Mark Fasheh

[Ocfs2-devel] dentry locks

[Sunil Mushran]

Mark Fasheh wrote:
> Yeah, it breaks the protocol  ;)

I meant, other than that. As in, we can always queue up this change
the next time we break the protocol for a better reason.


> What do the tcp dumps look like? Is it raw binary data, is the binary
> converted into hex, etc?

dentry lock from debugfs: N0000000000000005000d6a02
raw tcpdump: 4e303030303030303030303030303030350000000000000d6a02

N 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 00          0d6a02
4e303030303030303030303030303030350000000000000d6a02

As all other locknames are strings, if I need to wade thru tcpdumps,
I simply grep. If not for that, one can easily spend a day just searching
for the appropriate packets. So this is not a useless exercise.