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.





Case 1) 

unique: 3679, opcode: LOOKUP (1), nodeid: 2402, insize: 48
LOOKUP /store/data/Run2016C/SingleMuon/MINIAOD
getattr /store/data/Run2016C/SingleMuon/MINIAOD
   NODEID: 2403
   unique: 3679, success, outsize: 144
unique: 3680, opcode: OPENDIR (27), nodeid: 2403, insize: 48
   unique: 3680, success, outsize: 32
unique: 3681, opcode: READDIR (28), nodeid: 2403, insize: 80
readdir[0] from 0
unique: 3682, opcode: STATFS (17), nodeid: 1, insize: 40
statfs /
   unique: 3682, success, outsize: 96
unique: 3683, opcode: STATFS (17), nodeid: 1, insize: 40
statfs /
unique: 550908, opcode: LOOKUP (1), nodeid: 507164, insize: 59
LOOKUP /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: 144
unique: 550909, opcode: LOOKUP (1), nodeid: 507164, insize: 59
LOOKUP /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


Geonmo Ryu / 류건모

Korea Institute of Science and Technology Information (KISTI)
Global Science experimental Data hub Center (GSDC)
245 Daehak-ro, Yuseong-gu, Daejeon, 305-806, Republic of Korea
Tel :  +82-42-869-1639
E-mail: (CMS Helpdesk) [log in to unmask] / (Contact) [log in to unmask]







-----------------------원본 메세지-----------------------
보낸사람: "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 xrootdfs



Hi 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.




Wei Yang  |  [log in to unmask]  |  650-926-3338(O)




Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-L list, click the following link: