Bug #11790
closed"cannot utime" errors in from tar in knfs workloads
0%
Description
http://pulpito.ceph.com/teuthology-2015-05-18_13:43:17-knfs-hammer-testing-basic-multi/897933/
http://pulpito.ceph.com/teuthology-2015-05-18_13:43:17-knfs-hammer-testing-basic-multi/897931/
http://pulpito.ceph.com/teuthology-2015-05-18_13:43:17-knfs-hammer-testing-basic-multi/897924/
http://pulpito.ceph.com/teuthology-2015-05-18_13:43:17-knfs-hammer-testing-basic-multi/897926/
These runs don't seem to have debug logs from MDS :-/
Updated by John Spray almost 9 years ago
- Project changed from Ceph to CephFS
- Category set to NFS (Linux Kernel)
Updated by Yuri Weinstein almost 9 years ago
- Severity changed from 3 - minor to 1 - critical
hammer v0.94.2 release
do you think is this a blocker?
Updated by Greg Farnum almost 9 years ago
2015-05-18T19:26:50.878 INFO:tasks.workunit.client.1.plana46.stderr:tar: blogbench-1.0/configure: Cannot utime 2015-05-18T19:26:50.878 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/configure.ac 2015-05-18T19:26:50.882 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/config.guess 2015-05-18T19:26:50.886 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/install-sh 2015-05-18T19:26:50.890 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/config.sub 2015-05-18T19:26:50.894 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/missing 2015-05-18T19:26:50.898 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/mkinstalldirs 2015-05-18T19:26:50.901 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/Makefile.am 2015-05-18T19:26:50.905 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/Makefile.in 2015-05-18T19:26:50.909 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/config.h.in 2015-05-18T19:26:50.913 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/AUTHORS 2015-05-18T19:26:50.916 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/INSTALL 2015-05-18T19:26:50.920 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/ChangeLog 2015-05-18T19:26:50.924 INFO:tasks.workunit.client.1.plana46.stdout:blogbench-1.0/COPYING 2015-05-18T19:26:50.928 INFO:tasks.workunit.client.1.plana46.stderr:tar: Exiting with failure status due to previous errors 2015-05-18T19:26:50.931 INFO:tasks.workunit:Stopping ['suites/blogbench.sh'] on client.1... 2015-05-18T19:26:50.931 INFO:teuthology.orchestra.run.plana46:Running: 'rm -rf -- /home/ubuntu/cephtest/workunits.list.client.1 /home/ubuntu/cephtest/workunit.client.1' 2015-05-18T19:26:50.956 ERROR:teuthology.parallel:Exception in parallel execution Traceback (most recent call last): File "/home/teuthworker/src/teuthology_master/teuthology/parallel.py", line 82, in __exit__ for result in self: File "/home/teuthworker/src/teuthology_master/teuthology/parallel.py", line 101, in next resurrect_traceback(result) File "/home/teuthworker/src/teuthology_master/teuthology/parallel.py", line 19, in capture_traceback return func(*args, **kwargs) File "/var/lib/teuthworker/src/ceph-qa-suite_hammer/tasks/workunit.py", line 361, in _run_tests label="workunit test {workunit}".format(workunit=workunit) File "/home/teuthworker/src/teuthology_master/teuthology/orchestra/remote.py", line 156, in run r = self._runner(client=self.ssh, name=self.shortname, **kwargs) File "/home/teuthworker/src/teuthology_master/teuthology/orchestra/run.py", line 378, in run r.wait() File "/home/teuthworker/src/teuthology_master/teuthology/orchestra/run.py", line 114, in wait label=self.label) CommandFailedError: Command failed (workunit test suites/blogbench.sh) on plana46 with status 2: 'mkdir -p -- /home/ubuntu/cephtest/mnt.1/client.1/tmp && cd -- /home/ubuntu/cephtest/mnt.1/client.1/tmp && CEPH_CLI_TEST_DUP_COMMAND=1 CEPH_REF=63832d4039889b6b704b88b86eaba4aadcfceb2e TESTDIR="/home/ubuntu/cephtest" CEPH_ID="1" PATH=$PATH:/usr/sbin adjust-ulimits ceph-coverage /home/ubuntu/cephtest/archive/coverage timeout 3h /home/ubuntu/cephtest/workunit.client.1/suites/blogbench.sh'
I've not the slightest idea what that "cannot utime" means coming out from configure...anybody else?
Updated by John Spray almost 9 years ago
It's the failure to set mtimes etc on an extracted file via utimensat.
I have a slightly fuzzy memory that we were talking about the case where rsync/tar would try to set timestamps in the future, and whether we wanted to accept that, but I can't see any changes we made around that
Updated by Zheng Yan almost 9 years ago
- Status changed from New to Resolved
it's nfs bug in 4.1-rc2 kernel. now the testing branch has been rebased to 4.1-rc5, this issue should disappear