Repack issues seen. Thoughts?

Troubleshooting
1

Summary

We started our first repack and noticed two issues.

  1. We are using an NFS file system for the repack area mounted on /data/repack. We are using the file:/ form for the repack directory. Permissions are 777. The VIDXXX directory is successfully made but with 600 permissions instead of 700. File writes into that directory failed with permission denied. Changing the permissions manually to 700 allowed writes to start. Thoughts?

  2. Our cta-admin does not have --isrepackvo option for the vo ch command. Our version is cta-cli-5.10.0. Is this expected? We were able to kick off the repack by updating the database column directly.

Thanks!

Eric

2

Hi Eric,

On your first issue, this is because the umask in the tapeserver is set to 0177. We use EOS for the repack files, and EOS has a non-POSIX behaviour, in that when a directory is created, the permissions are inherited from the parent directory rather than following the constraints in the umask. But when using NFS, the permissions follow the umask so you get 0600.

I will fix this in main by changing the umask to 0077. In the meantime you will have to work around it as you are doing, sorry!

On your second issue, note that releases with .0 at the end are catalogue update releases. That is, when you upgrade to that release, the CTA catalogue schema is upgraded but there are no code updates. You need to upgrade again to 5.10.1 or later in order to get the --isrepackvo option.

This two-step upgrade scheme is by design, to allow a smooth upgrade to a new catalogue schema across all tapeservers with no downtime.

Cheers,
Michael

3

Hello,

Has the umask issue been adressed?
At Fermiab we use 5.10.10.1-1.el9.el9 and still see this problem.

Cheers,
Dmitry

4

Hi Dmitry, the fix is in v5.10.11.0-1.

This version is available in the public test repo if you want to try it.

5

Fantastic, thank you, Michael.

1 Like