Bug 244089 - lsextattr on a specific UFS file locks system
Summary: lsextattr on a specific UFS file locks system
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.3-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-fs mailing list
Depends on:
Reported: 2020-02-13 08:22 UTC by ml
Modified: 2020-02-17 04:05 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description ml 2020-02-13 08:22:24 UTC
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.
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.