search for: newfstatat

...ent from the ./source4 directory I limited server max protocol = SMB2 but that didn't do it. Long story: ----------- My samba server (4.2.14) hosts a couple of game install trees for a Windows 7 computer. Some of the games cause storms of stat(2) system calls, here is a partial strace: newfstatat(35, "i50145t.bmp", {st_mode=S_IFREG|0664, st_size=35344, ...}, 0) = 0 newfstatat(35, "i01014o.BMP", {st_mode=S_IFREG|0664, st_size=21536, ...}, 0) = 0 newfstatat(35, "i50027g.bmp", {st_mode=S_IFREG|0664, st_size=28416, ...}, 0) = 0 newfstatat(35, "i02017g.BMP&quot...

...without vfs_fruit. On my setup it's roughly 2.5 times slower. To me it looks like this is caused by the getxattr call which is only present with vfs_fruit activated and introduces an additional delay of ~ 0.00033 s per listed file. strace -T reveals the following with vfs_fruit activated: newfstatat(35, "03915", {st_mode=S_IFREG|0660, st_size=1265, ...}, AT_SYMLINK_NOFOLLOW) = 0 <0.000243> fcntl(20, F_SETLKW, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=8368, l_len=1}) = 0 <0.000010> fcntl(20, F_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=8368, l_len=1}) = 0 &lt...

Im having an issue with what I believe might be pinned down to a need for a proper samba configuration. The problem: sparse writes (not sure which, either write sparse files to a system that doesn't support them, or vice versa) The system: Zfs-on-linux, samba share Accessing system which is erroring: Win7x64_ult, freefilesync Error message NOTHING I have done to it is

....P4-8ubuntu1.10), multiarch-support:amd64 (2.23-0ubuntu9, 2.23-0ubuntu10), libisccc140:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.8, 1:9.10.3.dfsg.P4-8ubuntu1.10), libbind9-140:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.8, 1:9.10.3.dfsg.P4-8ubuntu1.10) End-Date: 2018-01-18? 04:34:32 strace rsync : 30743 23:34:47 newfstatat(3, "6737", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0 30743 23:34:47 newfstatat(3, "6741", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0 30743 23:34:47 getdents(3, /* 0 entries */, 131072) = 0 30743 23:34:47 munmap(0x7fa4feae7000,...

...ubuntu9, 2.23-0ubuntu10), > libisccc140:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.8, > 1:9.10.3.dfsg.P4-8ubuntu1.10), > libbind9-140:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.8, > 1:9.10.3.dfsg.P4-8ubuntu1.10) > End-Date: 2018-01-18 04:34:32 > > > > strace rsync : > > 30743 23:34:47 newfstatat(3, "6737", {st_mode=S_IFDIR|0755, st_size=4096, > ...}, AT_SYMLINK_NOFOLLOW) = 0 > 30743 23:34:47 newfstatat(3, "6741", {st_mode=S_IFDIR|0755, st_size=4096, > ...}, AT_SYMLINK_NOFOLLOW) = 0 > 30743 23:34:47 getdents(3, /* 0 entries */, 131072) = 0 > 30743 23:34:47...

...roughly 2.5 times slower. To me it looks > like this is > caused by the getxattr call which is only present with vfs_fruit > activated and introduces an additional delay of ~ 0.00033 s > per listed file. > > strace -T reveals the following with vfs_fruit activated: > > newfstatat(35, "03915", {st_mode=S_IFREG|0660, st_size=1265, ...}, > AT_SYMLINK_NOFOLLOW) = 0 <0.000243> > fcntl(20, F_SETLKW, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=8368, > l_len=1}) = 0 <0.000010> > fcntl(20, F_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=8368...

(resending, sorry for duplicates) On 01/24/2018 05:59 PM, Dietmar Putz wrote: > strace rsync : > > 30743 23:34:47 newfstatat(3, "6737", {st_mode=S_IFDIR|0755, > st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0 > 30743 23:34:47 newfstatat(3, "6741", {st_mode=S_IFDIR|0755, > st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0 > 30743 23:34:47 getdents(3, /* 0 entries */, 131072) = 0 > 30743 23:34:...

...t; libisccc140:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.8, > 1:9.10.3.dfsg.P4-8ubuntu1.10), > libbind9-140:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.8, > 1:9.10.3.dfsg.P4-8ubuntu1.10) > End-Date: 2018-01-18? 04:34:32 > > > > strace rsync : > > 30743 23:34:47 newfstatat(3, "6737", {st_mode=S_IFDIR|0755, > st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0 > 30743 23:34:47 newfstatat(3, "6741", {st_mode=S_IFDIR|0755, > st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0 > 30743 23:34:47 getdents(3, /* 0 entries */, 131072) = 0 &gt...

Fwiw, rsync error 3 is: "Errors selecting input/output files, dirs" On January 19, 2018 7:36:18 AM PST, Dietmar Putz <dietmar.putz at 3qsdn.com> wrote: >Dear All, > >we are running a dist. repl. volume on 4 nodes including >geo-replication >to another location. >the geo-replication was running fine for months. >since 18th jan. the geo-replication is faulty.

...P4-8ubuntu1.8, >> 1:9.10.3.dfsg.P4-8ubuntu1.10), >> libbind9-140:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.8, >> 1:9.10.3.dfsg.P4-8ubuntu1.10) >> End-Date: 2018-01-18? 04:34:32 >> >> >> >> strace rsync : >> >> 30743 23:34:47 newfstatat(3, "6737", {st_mode=S_IFDIR|0755, >> st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0 >> 30743 23:34:47 newfstatat(3, "6741", {st_mode=S_IFDIR|0755, >> st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0 >> 30743 23:34:47 getdents(3, /* 0 entries */,...

..., FD_CLOEXEC) ? ? ? ? ? = 0 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7efdccf7f000 getdents(3, /* 6 entries */, 131072) ? ?= 168 getdents(3, /* 0 entries */, 131072) ? ?= 0 lseek(3, 0, SEEK_SET) ? ? ? ? ? ? ? ? ? = 0 getdents(3, /* 6 entries */, 131072) ? ?= 168 newfstatat(3, "test", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0 newfstatat(3, ".trashcan", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0 getdents(3, /* 0 entries */, 131072) ? ?= 0 munmap(0x7efdccf7f000, 135168) ? ? ? ? ?= 0 close(3) ? ? ? ?...

Hi, As a quick workaround for geo-replication to work. Please configure the following option. gluster vol geo-replication <mastervol> <slavehost>::<slavevol> config access_mount true The above option will not do the lazy umount and as a result, all the master and slave volume mounts maintained by geo-replication can be accessed by others. It's also visible in df output.

...9129 open 1.71 0.141637 7 19139 close 1.61 0.133204 6 23576 fstat 1.34 0.111502 6 19307 getcwd 0.23 0.019376 61 317 pread 0.09 0.007880 7 1115 newfstatat 0.08 0.006739 15 438 pwrite 0.05 0.004449 8 567 read 0.05 0.003875 5 794 getgroups 0.04 0.003103 19 163 write 0.02 0.001770 5 326 alarm 0.02...

On 02/05/2018 01:33 PM, Florian Weimer wrote: > Do you have strace output going further back, at least to the proceeding > getcwd call?? It would be interesting to see which path the kernel > reports, and if it starts with "(unreachable)". I got the strace output now, but it very difficult to read (chdir in a multi-threaded process ?). My current inclination is to blame

...2982 readv 0.13 0.124557 10 13011 open 0.09 0.084440 7 12982 close 0.09 0.081359 5 17792 fstat 0.06 0.057796 4 13005 getcwd 0.04 0.038026 5 7708 newfstatat 0.02 0.021132 67 317 pread 0.01 0.008339 18 451 pwrite 0.01 0.007232 14 505 getdents 0.00 0.003154 18 178 brk 0.00 0.000389 97 4 fdatasync 0.00...

...5 close 0.00 0.000780 16 50 openat 0.00 0.000773 13 60 lstat 0.00 0.000637 12 55 mprotect 0.00 0.000598 11 55 mmap 0.00 0.000474 13 36 newfstatat 0.00 0.000453 21 22 getdents 0.00 0.000377 29 13 sendmsg 0.00 0.000270 14 20 socket 0.00 0.000270 11 24 getcwd 0.00 0.000246 12 20 10 connect 0.0...

Hi Jones, many thanks again four your help and your time. Thanks for the patch too - I'll check it up. On my Ubuntu, there is a Samba 4.1.6. I'll install the samba source package, and will try to apply the patch, then - I hope - the package will be compiled as well. I'll notify to you about the result. (First, I need to upgrade that server.) Thanks again, Ervin On Thu, Apr

Dear All, we are running a dist. repl. volume on 4 nodes including geo-replication to another location. the geo-replication was running fine for months. since 18th jan. the geo-replication is faulty. the geo-rep log on the master shows following error in a loop while the logs on the slave just show 'I'nformations... somehow suspicious are the frequent 'shutting down connection'

...ilter settings for syscalls denial * (if syscall doesn't exist openssh will not build) * open is not on aarch64, openat exists also on primary architectures * stat is never used, x86_64 is using fstat, ix86 and arm is using fstat64 and stat64 => whitelisting, aarch64 is using fstat and newfstatat * poll, select are not available on aarch64 * pselect6 is used instead of select (see attached patch) This patch was tested and is currently used in Fedora. We plan to add support for other architectures sooner or later. Further discussion welcome. I'm also appending table with syscall...

...adlinkat(int, const char *, char *, int); <!ppc64> int stat64,stat::stat(const char *, struct stat *); <!ppc64> int lstat64,lstat::lstat(const char *, struct stat *); @@ -141,14 +141,15 @@ int readlink(const char *, char *, size_t); /* XXX: Is this right?! */ <?> int fstatat64,newfstatat,fstatat::fstatat(int, const char *, struct stat *, int); int getdents64,getdents::getdents(unsigned int, struct dirent *, unsigned int); -int chown32,chown::chown(const char *, uid_t, gid_t); +<?> int chown32,chown::chown(const char *, uid_t, gid_t); int fchown32,fchown::fchown(int, uid_t,...