CERN Accelerating science

Fuse client writes forever on a full filesystem


It has been observed that when a client writes a file that doesn’t fit the target FS, it tries to write forever without failing, causing a very large number of errors on the FST and the fuse client (100Hz). Maybe a i/o error sent back to the client would be a wiser behaviour ?

FST error :

180807 16:57:50 time=1533653870.737201 func=write                    level=ERROR logid==754e4570-9a2a-11e8-82e6-6c0b84b7fa3a tid=00007fae420ca700 source=XrdFstOfsFile:2174             tident=AAAAABMo.1890:183@s-jrciprjeop202p sec=      uid=35441 gid=40507 name=nobody geo="" block-write error=2 offset=849057677312 len=262144 file=/data19/00009e9f/1834250e error="&mgm.access=update&mgm.ruid=35441&mgm.rgid=40507&mgm.uid=35441&mgm.gid=99&mgm.path=/eos/jeodpp/home/users/tognova/tmp/Bonnie.21241&|tognova||||||fuse&mgm.lid=1048850&mgm.bookingsize=0&mgm.fsid=308&mgm.url0=root://"

Fuse error :

n=fxid:18342500&fst.valid=1533636837&xrd.k5ccname=/var/run/eosd/credentials/store/uid35441.krb5&xrd.wantprot=krb5,unix&xrdcl.secgid=40507&xrdcl.secuid=35441] Fatal file state error. Message kXR_write (handle: 0x00000000, offset: 745544089600, size: 262144) returned with [ERROR] Server responded with an error: [3011] Unable to write replica failed root://<...>&cap.sym=<...>&,unix&mgm.path=/#curl#/eos/jeodpp/home/users/tognova/tmp/Bonnie.21235; no such file or directory => file has been removed because the target filesystem  was full