 |
 |
Hello, Wei Yang.Thank you for your kind explanation.I've only seen using the -f option in strace, but I've never thought about putting on a gdb.I'll try again when a similar problem occurs.It doesn't happen as often as I think if it does't have a lot of user activity.And when we checked with xrdfs' own debug option, we got the following results.When we look at the two cases below, we have the following hypotheses.When communication between the xrdfs client and the XRootD redirector server or communication between the XRootD redirector and the XRootD servers fails, the waiting seems to go infinitely. (For example, opcode:READDIR did not receive "NODEID, unique, success code, or outsize" from remote on Case 1.)Because there are no returning packets, FUTEX seems to be waiting indefinitely.Is there a timeout setting related to it? I think it'll work out if I set it up.Regards,##Case 1) unique: 3679, opcode: LOOKUP (1), nodeid: 2402, insize: 48LOOKUP /store/data/Run2016C/SingleMuon/MINIAODgetattr /store/data/Run2016C/SingleMuon/MINIAOD NODEID: 2403 unique: 3679, success, outsize: 144unique: 3680, opcode: OPENDIR (27), nodeid: 2403, insize: 48 unique: 3680, success, outsize: 32unique: 3681, opcode: READDIR (28), nodeid: 2403, insize: 80readdir[0] from 0unique: 3682, opcode: STATFS (17), nodeid: 1, insize: 40statfs / unique: 3682, success, outsize: 96unique: 3683, opcode: STATFS (17), nodeid: 1, insize: 40statfs /Case2)unique: 550908, opcode: LOOKUP (1), nodeid: 507164, insize: 59LOOKUP /store/group/CAT/V9_2/SingleMuon/V9_2_Run2017F-31Mar2018-v1/180601_025537/0001/catTuple_1969.root getattr /store/group/CAT/V9_2/SingleMuon/V9_2_Run2017F-31Mar2018-v1/180601_025537/0001/catTuple_1969.root NODEID: 508134 unique: 550908, success, outsize: 144unique: 550909, opcode: LOOKUP (1), nodeid: 507164, insize: 59LOOKUP /store/group/CAT/V9_2/SingleMuon/V9_2_Run2017F-31Mar2018-v1/180601_025537/0001/catTuple_1970.root getattr /store/group/CAT/V9_2/SingleMuon/V9_2_Run2017F-31Mar2018-v1/180601_025537/0001/catTuple_1970.root <- Hold here -----------------------원본 메세지-----------------------보낸사람: "Yang, Wei "<[log in to unmask]>받는사람: "Geonmo Ryu" <[log in to unmask]>,xrootd-l <[log in to unmask]>보낸시간: 2020-12-12 15:48:41 GMT +0900 (ROK)제목: Re: Infinite standby state of xrootdfsHi Geonmo, I have an almost identical setup except that my storages are local disks, not NFS disk. I can’t repeat the hanging you described in xrootdfs. So far my ‘du’ has run for 24+ hours and is still running. To debug, I suggest that you use the following command line: xrootdfs -f -o rdr=root://your/storage /mount_point the -f puts xrootdfs in a foreground mode which helps you to debug. You can then attach gdb to check what is xrootdfs’ called stacks when du (or find) command starts to show problem. Keep in mind that xrootdfs is a fuse application – there is a linux kernel between xrootdfs and du/find. regards, -- Wei Yang | [log in to unmask] | 650-926-3338(O) https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1