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/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244089 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 everything worked fine for a while and extended attributes were created on files/directory 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 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 when the problem first arose. One intersting thing would be to exfiltrate this "bad" directory and copy it to a test server, as I cannot perform many things on this remote production system (especially considering I cannot press reset remotely). However just reading the data hangs it, so I have no idea how to do this. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-244089-227>