Date: Thu, 13 Feb 2020 08:22:24 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 244089] lsextattr on a specific UFS file locks system Message-ID: <bug-244089-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D244089 Bug ID: 244089 Summary: lsextattr on a specific UFS file locks system Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: ml@netfence.it I've got a 11.3p6/amd64 UFS-based system, where Samba 4.10 is running in a = jail as an AD member. Yesterday I tried enabling vfs_fruit and streams_xattr: apparently everythi= ng worked fine for a while and extended attributes were created on files/direc= tory a Mac client accessed. After a while the client lost connection to the server: I checked and saw a smbd process taking 100% CPU; such a process was unkillable to the point it even prevented rebooting. Reset button had to be pressed. I pinpointed this to reading the extended attributes that were attached to = some file in a particular directory. I.e. Something like: find {dir} -exec lsextattr user "{}" ";" produces a process: lsextattr user {file} taking 100% cpu and not willing to die in any way. Again, only the reset button could get me out of this situation. "fsck -y" found no sign of troubles on that filesystem. I was able to use rsync to make a copy of the whole share without extended attributes, so the server is working again. However, for now, I'm keeping the "bad" copy around for testing. System is 11.3p6/amd64 with custom kernel, i.e.: _ UFS_ACL, UFS_GJOURNAL, QUOTA, MD_ROOT, NFS*, COMPAT*, AUDIT, CAPABILIT*, = MAC, RACCT*, RCTL were removed, along with unused drivers; _ GEOM_MIRROR, aesni and NULLFS were added. # tunefs -p /dev/mirror/gm0f=20 tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 6408 tunefs: optimization preference: (-o) time Note soft update journaling is now temporarily disabled, but was enabled wh= en the problem first arose. One intersting thing would be to exfiltrate this "bad" directory and copy i= t to a test server, as I cannot perform many things on this remote production sy= stem (especially considering I cannot press reset remotely). However just reading the data hangs it, so I have no idea how to do this. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-244089-227>