[LU-10260] ARCHIVE ID range

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.11.0
• Labels: HSM patch
• Severity: 3
• Project: HSM
• Assignee: Thomas Stibor
• Reporter: Tatsushi Takamura

Description

According to the lustre manual, ARCHIVE ID must be in the range of 1 to 32.
On the other hand, the code limits ARCHIVE ID to less than 32.

# lhsmtool_posix -A 32
1461110663.550681 lhsmtool_posix[5792]: archive number must be lessthan 32: Argument list too long (7)

Which is correct?

Comments

[Peter Jones]

Landed for 2.11

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/30171/
Subject: LU-10260 hsm: enable max archive_id posix copytool
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: c98a51f2cebd3417956f5823a0531311e2895028

[Gerrit Updater]

Thomas Stibor ([e-mail]) uploaded a new patch: https://review.whamcloud.com/30171
Subject: LU-10260 hsm: enable max archive_id posix copytool
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 24ddf1454ab01db540f96a4dc85fe95b57433a34

[Joseph Gmitter (Inactive)]

Thanks Thomas. Based on that, let's move this ticket over to the LU project instead of LUDOC, which is for the manual only.

[Thomas Stibor]

It looks like the problem is in the lhsmtool_posix. I think one can fix that as follows: 

diff --git a/lustre/utils/lhsmtool_posix.c b/lustre/utils/lhsmtool_posix.c
index 804dbe7..fc078d5 100644
--- a/lustre/utils/lhsmtool_posix.c
+++ b/lustre/utils/lhsmtool_posix.c
@@ -88,7 +88,7 @@ struct options {
        int                      o_verbose;
        int                      o_copy_xattrs;
        int                      o_archive_cnt;
-       int                      o_archive_id[LL_HSM_MAX_ARCHIVE];
+       int                      o_archive_id[LL_HSM_MAX_ARCHIVE + 1];
        int                      o_report_int;
        unsigned long long       o_bandwidth;
        size_t                   o_chunk_size;
@@ -259,8 +259,8 @@ static int ct_parseopts(int argc, char * const *argv)
                                long_opts, NULL)) != -1) {
                switch (c) {
                case 'A':
-                       if ((opt.o_archive_cnt >= LL_HSM_MAX_ARCHIVE) ||
-                           (atoi(optarg) >= LL_HSM_MAX_ARCHIVE)) {
+                       if ((opt.o_archive_cnt > LL_HSM_MAX_ARCHIVE) ||
+                           (atoi(optarg) > LL_HSM_MAX_ARCHIVE)) {
                                rc = -E2BIG;
                                CT_ERROR(rc, "archive number must be less"
                                         "than %zu", LL_HSM_MAX_ARCHIVE);

I will submit a patch and let's see what the others are thinking about it. Just did a quick check and archive_id=32 seems to work:

lrh=[type=10680000 len=136 idx=1/15] fid=[0x200000401:0x16:0x0] dfid=[0x200000401:0x16:0x0] compound/cookie=0x5a0ee
145/0x5a0ee13d action=ARCHIVE archive#=32 flags=0x0 extent=0x0-0xffffffffffffffff gid=0x0 datalen=0 status=SUCCEED
data=[]
3600
uuid=31732ace-8312-ea22-3423-9d06294ce647 archive_id=32 requests=[current:0 ok:2 errors:0]

Cheers
Thomas

[Joseph Gmitter (Inactive)]

So if I understand correctly, there is no manual bug correct?

[Thomas Stibor]

The maximum ARCHIVE ID is defined as

#define LL_HSM_MAX_ARCHIVE (sizeof(__u32) * 8) = 32

and checked for instance as follows

/* Detect out-of range archive id */
 if (hss->hss_archive_id > LL_HSM_MAX_ARCHIVE) {
     CDEBUG(D_HSM, "archive id %u exceeds maximum %zu.\n",
     hss->hss_archive_id, LL_HSM_MAX_ARCHIVE);
     GOTO(out_unlock, rc = -EINVAL);
 }

or

if (archive_count > LL_HSM_MAX_ARCHIVE) {
                llapi_err_noerrno(LLAPI_MSG_ERROR, "%d requested when maximum "
                                  "of %zu archives supported", archive_count,
                                  LL_HSM_MAX_ARCHIVE);
                return -EINVAL;
        }

so the range is from 1 to 32. The archive ID = 0 is reserved to specify in low level calls that no archive identifier change is done.