On Wed, Dec 19, 2018 at 11:23 PM Xiaoli Feng <xifeng@xxxxxxxxxx> wrote: > > Hello, > > ----- Original Message ----- > > From: "Steve French" <smfrench@xxxxxxxxx> > > To: "Xiaoli Feng" <xifeng@xxxxxxxxxx> > > Cc: "Christoph Hellwig" <hch@xxxxxxxxxxxxx>, fstests@xxxxxxxxxxxxxxx, "Ronnie Sahlberg" <lsahlber@xxxxxxxxxx>, "CIFS" > > <linux-cifs@xxxxxxxxxxxxxxx> > > Sent: Thursday, December 20, 2018 11:53:09 AM > > Subject: Re: [PATCH v1] xfstests: filter the default EA > > > > What server type (presumably Samba if mounting to localhost)? What > > Yes, it's Samba. <snip> > The dialect is smb3.02. Since cifs.ko does not know about or special case this attribute, the next step is to figure out who is returning this attribute - Samba server or something above the client. Typically I approach this by doing a quick wireshark trace (or follow the process described at https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Wire_Captures), that will very quickly allow you to determine if it even came from the server. If it came from the server, follow the normal process for enabling Samba logging (setting log level in smb.conf and looking at why the xattr is being returned by examining the corresponding log file in /var/log/samba/). If you don't see it coming from the server, then enabling the usual dynamic trace (trace-cmd) of the syscall may be helpful. Note that there are a fairly large number of xattr related trace points (see /sys/kernel/tracing/events/syscalls). Looking at this does remind me that I should add dynamic trace points to cifs.ko for smb3_get/set xattrs (for the error and success cases) although it probably wouldn't be needed in this case - it would have allowed us to more quickly rule out Samba returning this. > > What does the getfattr on the local path show as the attributes? > > It shows nothing for local path on xfs filesystem. > > # touch /file > # getfattr /file > #
