[LU-6213] 'tar -c' returns status 1 if HSM released files were encountered

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.8.0
• Affects Version/s: Lustre 2.7.0
• Labels: hsm
• Severity: 3
• Assignee: John Hammond
• Reporter: John Hammond

Description

HSM restore causes some file attributes to change (blocks and maybe ctime). tar detects this and reports "tar: f0: file changed as we read it" and will continue archiving but return 1 on exit. So according to its exit status it has failed but the archive contents are correct.

# echo XXXXXXXXXXXXXXXXXXXXXXXX > f0
# echo ZZZZZZZZZZZZZZZZZZZ > f1
# lfs hsm_archive f0
# lfs hsm_state f0
f0: (0x00000009) exists archived, archive_id:1
# lfs hsm_release f0
# lfs hsm_state f0
f0: (0x0000000d) released exists archived, archive_id:1
# tar -cf /tmp/0.tar f0 f1
tar: f0: file changed as we read it
# tar -tvf /tmp/0.tar
-rw-r--r-- root/root        25 2015-02-05 10:31 f0
-rw-r--r-- root/root        20 2015-02-05 10:34 f1
# rm f0 f1
# tar -xf /tmp/0.tar
# ls -l
total 1
-rw-r--r-- 1 root root 25 Feb  5 10:31 f0
-rw-r--r-- 1 root root 20 Feb  5 10:34 f1
# cat f0
XXXXXXXXXXXXXXXXXXXXXXXX
# cat f1
ZZZZZZZZZZZZZZZZZZZ

Comments

[Joseph Gmitter (Inactive)]

Landed for 2.8.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/13665/
Subject: LU-6213 llite: add LL_IOC_FUTIMES_3
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 12e4004656f3019d0195d46de6df94af7452fdf8

[Gerrit Updater]

John L. Hammond ([e-mail]) uploaded a new patch: http://review.whamcloud.com/13665
Subject: LU-6213 llite: add LL_IOC_FUTIMES_3
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 3433f3e3da4963d5bbe3c5bf05748bc328bd9023

[John Hammond]

It's the ctime change that tar is reacting to.

                if (ok) {
			if ((timespec_cmp
                             (get_stat_ctime(&final_stat), original_ctime) != 0
                             /* Original ctime will change if the file is a directory and
                                --remove-files is given */
                             && !(remove_files_option && is_dir))
                            || original_size < final_stat.st_size) {
                                WARNOPT(WARN_FILE_CHANGED,
					(0, 0,
                                         _("%s: file changed as we read it"),
                                         quotearg_colon(p)));
                                set_exit_status(TAREXIT_DIFFERS);
                        } else if (atime_preserve_option ==
                                   replace_atime_preserve
                                   && set_file_atime(fd, p, restore_times) != 0)
				utime_error(p);
                }

By skewing clocks I can see that the ctime comes from the copytool node via the OST object from the volatile file. (This is a different file from above.)

t3:lustre# echo XXX > f0
t3:lustre# stat f0
  File: `f0'
  Size: 4         	Blocks: 1          IO Block: 4194304 regular file
Device: 2c54f966h/743766374d	Inode: 288230393331580931  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-02-05 15:38:58.000000000 -0600
Modify: 2015-02-05 15:38:58.000000000 -0600
Change: 2015-02-05 15:38:58.000000000 -0600
t3:lustre# lfs hsm_archive f0
t3:lustre# lfs hsm_release f0
t3:lustre# stat f0
  File: `f0'
  Size: 4         	Blocks: 1          IO Block: 4194304 regular file
Device: 2c54f966h/743766374d	Inode: 288230393331580931  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-02-05 15:38:58.000000000 -0600
Modify: 2015-02-05 15:38:58.000000000 -0600
Change: 2015-02-05 15:38:58.000000000 -0600
t3:lustre# lfs hsm_restore f0
t3:lustre# stat f0
  File: `f0'
  Size: 4         	Blocks: 8          IO Block: 4194304 regular file
Device: 2c54f966h/743766374d	Inode: 288230393331580931  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-02-05 15:38:58.000000000 -0600
Modify: 2015-02-05 15:38:58.000000000 -0600
Change: 2015-02-06 15:39:40.000000000 -0600
t3:lustre# lfs getstripe f0
f0
lmm_stripe_count:   1
lmm_stripe_size:    1048576
lmm_pattern:        1
lmm_layout_gen:     2
lmm_stripe_offset:  1
	obdidx		 objid		 objid		 group
	     1	             2	          0x2	             0

t0:~# stat /tmp/mnt/ROOT/f0
  File: `/tmp/mnt/ROOT/f0'
  Size: 4               Blocks: 0          IO Block: 4096   regular file
Device: 701h/1793d      Inode: 141         Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-02-05 15:38:58.000000000 -0600
Modify: 2015-02-05 15:38:58.000000000 -0600
Change: 2015-02-05 15:38:58.000000000 -0600

t2:~# stat /tmp/mnt/O/0/d2/2
  File: `/tmp/mnt/O/0/d2/2'
  Size: 4         	Blocks: 8          IO Block: 4096   regular file
Device: 707h/1799d	Inode: 222         Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-02-05 15:38:58.000000000 -0600
Modify: 2015-02-05 15:38:58.000000000 -0600
Change: 2015-02-06 15:39:40.000000000 -0600

[Robert Read]

AFAICT, restore is not changing the timestamps, just the blocks.

[Andreas Dilger]

It definitely makes sense to keep the previous timestamps when restoring a file. IMHO the userspace visible attributed of the file should stay constant regardless of whether the file is released or restored.

Is the timestamp change a side effect of the MDS clock leaking into file attributes, and will this be fixed by other patches in that area?