Re: [Gluster-devel] Upcall details for NLINK

2016-09-19 Thread Soumya Koduri



On 09/19/2016 10:08 AM, Niels de Vos wrote:

Duh, and now with the attachment. I'm going to get some coffee now.


On Mon, Sep 19, 2016 at 06:22:58AM +0200, Niels de Vos wrote:

Hey Soumya,

do we have a description of the different actions that we expect/advise
users of upcall to take? I'm looking at the flags that are listed in
libglusterfs/src/upcall-utils.h and api/src/glfs-handles.h and passed in
the glfs_callback_inode_arg structure from api/src/glfs-handles.h.


Not very detailed. But a minimal description of each of these flags is 
provided in the definitions of these flags (now moved to the 
file:upcall-utils.h).




We have a NLINK flag, but that does not seem to carry the stat/iatt
attributes for the changed inode. It seems we send an upcall on file
removal that incudes NLINK, and just after that we send an other one
with FORGET.


From the code, I see that it does seem to be sending stat of the inode 
being (un)linked. May be if it is the last link to be removed, stat 
structure could have been NULL. Could you please check with files with 
link count >1?


FORGET was not exactly related to removal/unlink of the file. It is to 
be sent whenever (protocol/)server does inode_forget which could be for 
various other reasons. But yeah, as you have said, when the last link is 
removed, since a FORGET gets definitely sent which invalidates the inode 
cache entry, there is no point sending NLINK flag just before that. We 
could have a check to avoid NLINK upcall if it is the last link of the 
file being removed.



Thanks,
Soumya



This attachment in Bugzilla shows the behaviour:
  https://bugzilla.redhat.com/attachment.cgi?id=1202190

You'll need https://code.wireshark.org/review/17776 to decode the flags,
so I'll attach the tshark output to this email for your convenience.
  $ tshark -r /tmp/upcall_xid.1474190284.pcap.gz -V 'glusterfs.cbk'

Question: For the NLINK flag, should we not include the stat/iatt of the
modified inode? And only if the iatt->nlink is 0, a FORGET should get
sent? NLINK would then only happen when a (not the last) hardlink is
removed.

Thanks,
Niels





___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel



___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


Re: [Gluster-devel] Upcall details for NLINK

2016-09-18 Thread Niels de Vos
Duh, and now with the attachment. I'm going to get some coffee now.


On Mon, Sep 19, 2016 at 06:22:58AM +0200, Niels de Vos wrote:
> Hey Soumya,
> 
> do we have a description of the different actions that we expect/advise
> users of upcall to take? I'm looking at the flags that are listed in
> libglusterfs/src/upcall-utils.h and api/src/glfs-handles.h and passed in
> the glfs_callback_inode_arg structure from api/src/glfs-handles.h.
> 
> We have a NLINK flag, but that does not seem to carry the stat/iatt
> attributes for the changed inode. It seems we send an upcall on file
> removal that incudes NLINK, and just after that we send an other one
> with FORGET.
> 
> This attachment in Bugzilla shows the behaviour:
>   https://bugzilla.redhat.com/attachment.cgi?id=1202190
> 
> You'll need https://code.wireshark.org/review/17776 to decode the flags,
> so I'll attach the tshark output to this email for your convenience.
>   $ tshark -r /tmp/upcall_xid.1474190284.pcap.gz -V 'glusterfs.cbk'
> 
> Question: For the NLINK flag, should we not include the stat/iatt of the
> modified inode? And only if the iatt->nlink is 0, a FORGET should get
> sent? NLINK would then only happen when a (not the last) hardlink is
> removed.
> 
> Thanks,
> Niels



> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel

Frame 37: 468 bytes on wire (3744 bits), 468 bytes captured (3744 bits)
Encapsulation type: Linux cooked-mode capture (25)
Arrival Time: Sep 18, 2016 11:18:16.284213000 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1474190296.284213000 seconds
[Time delta from previous captured frame: 0.000289000 seconds]
[Time delta from previous displayed frame: 0.0 seconds]
[Time since reference or first frame: 9.241353000 seconds]
Frame Number: 37
Frame Length: 468 bytes (3744 bits)
Capture Length: 468 bytes (3744 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: sll:ethertype:ip:tcp:rpc:glusterfs.cbk]
Linux cooked capture
Packet type: Unicast to us (0)
Link-layer address type: 772
Link-layer address length: 6
Source: 00:00:00_00:00:00 (00:00:00:00:00:00)
Protocol: IPv4 (0x0800)
Internet Protocol Version 4, Src: 172.31.122.140, Dst: 172.31.122.140
0100  = Version: 4
 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
 00.. = Differentiated Services Codepoint: Default (0)
 ..00 = Explicit Congestion Notification: Not ECN-Capable Transport 
(0)
Total Length: 452
Identification: 0xf440 (62528)
Flags: 0x02 (Don't Fragment)
0...  = Reserved bit: Not set
.1..  = Don't fragment: Set
..0.  = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (6)
Header checksum: 0xf79b [validation disabled]
[Good: False]
[Bad: False]
Source: 172.31.122.140
Destination: 172.31.122.140
Transmission Control Protocol, Src Port: 49152, Dst Port: 49150, Seq: 1, Ack: 
1, Len: 400
Source Port: 49152
Destination Port: 49150
[Stream index: 4]
[TCP Segment Len: 400]
Sequence number: 1(relative sequence number)
[Next sequence number: 401(relative sequence number)]
Acknowledgment number: 1(relative ack number)
Header Length: 32 bytes
Flags: 0x018 (PSH, ACK)
000.   = Reserved: Not set
...0   = Nonce: Not set
 0...  = Congestion Window Reduced (CWR): Not set
 .0..  = ECN-Echo: Not set
 ..0.  = Urgent: Not set
 ...1  = Acknowledgment: Set
  1... = Push: Set
  .0.. = Reset: Not set
  ..0. = Syn: Not set
  ...0 = Fin: Not set
[TCP Flags: ···AP···]
Window size value: 475
[Calculated window size: 475]
[Window size scaling factor: -1 (unknown)]
Checksum: 0x4f0e [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Urgent pointer: 0
Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
No-Operation (NOP)
Type: 1
0...  = Copy on fragmentation: No
.00.  = Class: Control (0)
...0 0001 = Number: No-Operation (NOP) (1)
No-Operation (NOP)
Type: 1
0...  = Copy on fragmentation: No
.00.  = Class: Control (0)
...0 0001 = Number: No-Operation (NOP) (1)
Timestamps: TSval 1196377, TSecr 1180839
Kind: Time Stamp Option (8)
Length: 10
Timestamp value: 1196377
Timestamp echo reply: 1180839
[SEQ/ACK analysis]
[Bytes in flight: 400]
[Bytes sent since last 

[Gluster-devel] Upcall details for NLINK

2016-09-18 Thread Niels de Vos
Hey Soumya,

do we have a description of the different actions that we expect/advise
users of upcall to take? I'm looking at the flags that are listed in
libglusterfs/src/upcall-utils.h and api/src/glfs-handles.h and passed in
the glfs_callback_inode_arg structure from api/src/glfs-handles.h.

We have a NLINK flag, but that does not seem to carry the stat/iatt
attributes for the changed inode. It seems we send an upcall on file
removal that incudes NLINK, and just after that we send an other one
with FORGET.

This attachment in Bugzilla shows the behaviour:
  https://bugzilla.redhat.com/attachment.cgi?id=1202190

You'll need https://code.wireshark.org/review/17776 to decode the flags,
so I'll attach the tshark output to this email for your convenience.
  $ tshark -r /tmp/upcall_xid.1474190284.pcap.gz -V 'glusterfs.cbk'

Question: For the NLINK flag, should we not include the stat/iatt of the
modified inode? And only if the iatt->nlink is 0, a FORGET should get
sent? NLINK would then only happen when a (not the last) hardlink is
removed.

Thanks,
Niels


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel