пн, 25 февр. 2019 г. в 10:52, Steve French <smfrench@xxxxxxxxx>: > > On Mon, Feb 25, 2019 at 12:44 PM Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > > > > вс, 24 февр. 2019 г. в 23:11, Steve French <smfrench@xxxxxxxxx>: > > > > > > May be helpful to get timing info for large reads/writes/query_dirs or > > > to better find hangs or operations that trigger reconnects. Sample > > > output from various readdirs with the new tracepoints > > > > > > # trace-cmd show > > > # tracer: nop > > > # > > > # _-----=> irqs-off > > > # / _----=> need-resched > > > # | / _---=> hardirq/softirq > > > # || / _--=> preempt-depth > > > # ||| / delay > > > # TASK-PID CPU# |||| TIMESTAMP FUNCTION > > > # | | | |||| | | > > > ls-30820 [004] .... 77492.662476: smb3_query_dir_enter: > > > xid=8 sid=0x2fa2c9ab tid=0x1377432b fid=0xfc37e912 offset=0x0 > > > len=0x4000 > > > ls-30820 [004] .... 77492.663906: smb3_query_dir_done: > > > xid=8 sid=0x2fa2c9ab tid=0x1377432b fid=0xfc37e912 offset=0x0 len=0x13 > > > ls-30820 [004] .... 77492.664107: smb3_query_dir_enter: > > > xid=9 sid=0x2fa2c9ab tid=0x1377432b fid=0xfc37e912 offset=0x0 > > > len=0x4000 > > > ls-30820 [004] .... 77492.664639: smb3_query_dir_err: > > > xid=9 sid=0x2fa2c9ab tid=0x1377432b fid=0xfc37e912 offset=0x0 len=0x0 > > > rc=0 > > > bash-27628 [000] .... 77502.150630: smb3_query_dir_enter: > > > xid=12 sid=0x2fa2c9ab tid=0x1377432b fid=0x26e379e1 offset=0x0 > > > len=0x4000 > > > bash-27628 [000] .... 77502.151783: smb3_query_dir_done: > > > xid=12 sid=0x2fa2c9ab tid=0x1377432b fid=0x26e379e1 offset=0x0 > > > len=0x13 > > > bash-27628 [000] .... 77502.151855: smb3_query_dir_enter: > > > xid=13 sid=0x2fa2c9ab tid=0x1377432b fid=0x26e379e1 offset=0x0 > > > len=0x4000 > > > bash-27628 [000] .... 77502.152378: smb3_query_dir_err: > > > xid=13 sid=0x2fa2c9ab tid=0x1377432b fid=0x26e379e1 offset=0x0 > > > len=0x0 rc=0 > > > > query_dir_ERR and rc=0 looks weird, should be query_dir_DONE. > > The reason I left it that way was it was slightly simpler (saved a few > lines of code) > but also allows us to distinguish the case of STATUS_NO_MORE_FILES > (which is mapped to rc = 0 so is logged as smb3_query_dir_err with > rc=0) ie the end of search example. > > Alternatively, I could move the smb2_query_done / smb2_query_err lines > up (immediately after the send_rcv) but it could miss errors caught in > "smb2_validate_iov" > I don't think we should hide STATUS_NO_MORE_FILES or any other status code in tracing (even if we mask it off later). Let's trace smb3_query_dir_err with the proper error code. Nobody except developers is expected to look at the traces, so, should be fine. -- Best regards, Pavel Shilovsky
