Hi,
I encountered a strange bug when running 4.1-rc3 kernel (head commit 110bc76729d448fdbcb5cdb63b83d9fd65ce5e26). Tar reports that it can not utime when unpack the archive.
[root@zhyan-kvm2 nfs]# tar -xjf ~/blogbench-1.0.tar.bz2
tar: blogbench-1.0/configure: Cannot utime
tar: Exiting with failure status due to previous errors
strace show that fstat reports a regular file as block device
openat(AT_FDCWD, "blogbench-1.0/configure", O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_CLOEXEC, 0700) = 4
…
fstat(4, {st_mode=S_IFBLK|020000740, st_rdev=makedev(4294937303, 3436209), ...}) = 74
I did bisect, found the first bad commit is
commit 5bb89b4702e22981445ae01af733a57d1cae2018
Author: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>
Date: Wed Mar 25 14:14:42 2015 -0400
NFSv4.1/pnfs: Separate out metadata and data consistency for pNFS
The LAYOUTCOMMIT operation means different things to different layout types.
For blocks and objects, it is both a data and metadata consistency operation.
For files and flexfiles, it is only a metadata consistency operation.
This patch separates out the 2 cases, allowing the files/flexfiles layout
drivers to optimise away the data consistency calls to layoutcommit.
Signed-off-by: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>
my nfsd and nfs configs are normal (fedora 20 default)
[root@zhyan-kvm1 ~]# cat /etc/exports
/mnt/local *(rw,no_root_squash,no_subtree_check)
[root@zhyan-kvm2 ~]# mount
192.168.122.157:/mnt/local on /mnt/nfs type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.158,local_lock=none,addr=192.168.122.157)
the attached file is tar archive to reproduce this issue, and strace of tar when this issue happens.
Attachment:
blogbench-1.0.tar.bz2
Description: BZip2 compressed data
Attachment:
strace
Description: Binary data
Regards Yan, Zheng
