Re: pmfsrr mode
Absolutely On Sat, Apr 4, 2015 at 1:30 AM, sf...@users.sourceforge.net [1]sf...@users.sourceforge.net wrote: Jean-Ray Arseneau: Apologies, I sent the wrong log file. Here is the correct one, I am quite sure the patch is installed, as I see = lines like this one: Ok thanx, confirmed the patch was applied. The strange thing is that aufs considers there are only 6 writable branches, while you specified 8 writable branches. The missing two are - br2, WD-WCC4E5AFUJZK - br7, WD-WMAZA4509546 and br7 is what you expect as the target. If I write more patch to investigate this point, would you test again? J. R. Okajima References 1. mailto:sf...@users.sourceforge.net -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
Re: Permissions for root user
sf...@users.sourceforge.net: Your case looks different a little bit from Christoph Pleger's, but it must be same essentially. I've found linux NFS client always sets MS_POSIXACL (which is a flag in VFS layer) even if it was mounted with 'noacl.' I don't think it illegal or violation something, but it surely makes aufs (and me) confused. I may need some dirty workaround, but I'll consider more and more. When I found a solution, I'll send you a patch and ask a test. Here is my current solution, a dirty work-around. When you have time, pleast test. J. R. Okajima a.patch.bz2 Description: BZip2 compressed data -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
Re: pmfsrr mode
Jean-Ray Arseneau: Absolutely Here is an additional debug patch. J. R. Okajima b.patch.bz2 Description: BZip2 compressed data -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
Re: pmfsrr mode
Hereâs the updated log after applying the latest debug b.patch: https://dl.dropboxusercontent.com/u/26943/syslog-20150404.zip Jean On Sat, Apr 4, 2015 at 11:53 AM, sf...@users.sourceforge.net [1]sf...@users.sourceforge.net wrote: Jean-Ray Arseneau: Absolutely Here is an additional debug patch. J. R. Okajima b.patch.bz2 b.patch.bz2 References 1. mailto:sf...@users.sourceforge.net -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
open(..., O_CREAT|O_EXCL, 0400) on aufs over nfs4
I'm running into a problem using tar(1) to create a read-only file on an
aufs file system with two nfs4 branches.
test@sivtar-8e3b7f91b4ed:~/test$ ls
test@sivtar-8e3b7f91b4ed:~/test$ echo test x
test@sivtar-8e3b7f91b4ed:~/test$ chmod 0400 x
test@sivtar-8e3b7f91b4ed:~/test$ tar cvf x.tar x
x
test@sivtar-8e3b7f91b4ed:~/test$ rm x
rm: remove write-protected regular file ?x?? y
test@sivtar-8e3b7f91b4ed:~/test$ tar xvf x.tar
x
tar: x: Cannot open: Permission denied
tar: Exiting with failure status due to previous errors
test@sivtar-8e3b7f91b4ed:~/test$ ls -l
total 12
-r 1 test test    0 Apr 5 04:03 x
-rw-r--r-- 1 test test 10240 Apr 5 04:03 x.tar
test@sivtar-8e3b7f91b4ed:~/test$
I've narrowed it down to this test case:
#include sys/types.h
#include sys/stat.h
#include fcntl.h
int main(void)
{
 int fd = open(x, O_WRONLY|O_CREAT, 0400);
 if (fd 0)
   return 1;
 write(fd, test\n, 5);
 return 0;
}
which wrongly fails on aufs with nfs4 branches. The correct behavior is for
the open() call to succeed and for the resulting file descriptor to be
writable; instead, the file is created but -EACCES is returned by open().
The open(2) man page documents this behavior, and tar(1) relies on it.
The relevant strace when running on aufs:
open(x, O_WRONLY|O_CREAT, 0400)Â Â Â Â Â Â = -1 EACCES (Permission
denied)
The strace when running directly on nfs4:
open(x, O_WRONLY|O_CREAT, 0400)Â Â Â Â Â Â = 3
write(3, test\n, 5)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â = 5
This error seems to affect multiple or all versions of aufs, but the
specific data for the version that produced the above traces is:
aufs version: [Â Â Â 1.060148] aufs 3.x-rcN-20150330
I'm using kernel 4.0.0-rc6 in qemu.
I've attached a shell log that I believe contains all the information you
request for bug reports; please do let me know if I've missed something.
I've had a look at the relevant code in fs/namei.c, and it appears to me the
problem is that lookup_open(), in the absence of an -atomic_open method,
falls back to creating a file with vfs_create, then opening it with
vfs_open, which fails in this case. It's not clear to me what a good fix
would be, though implementing -atomic_open should work.
As an experiment, I've disabled nfs4's -atomic_open method, and the result
was that with the modified kernel, my test program fails even directly on
the nfs file system. It still succeeds both directly on a ramfs and on an
aufs using said ramfs, but that appears to be because ramfs has no -open at
all
aufs-data
Description: Binary data
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
Re: pmfsrr mode
Jean-Ray Arseneau: Here=E2=80=99s the updated log after applying the latest debug b.patch: Thank you very much. I think I could see the scenario. As you might know, the mfs policy caches the free-space value per branch, and pmfsrr policy internally runs the mfs rourtine twice. The first one is considering the parent dir, and the other is without considering the parent. In this second call, the mfs routine doesn't work expectedly since the result is cached and the routine dicide the target bracnh based upon the last result. Obviously it is an aufs bug. I will adress it in next week. If you can't wait, try 'pmfdrr:low:0' which will force the mfs routine not to use the cached value. J. R. Okajima -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
