From: Joseph Benjamin Evans <beevans@whamcloud.com>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] Error checking for llapi_hsm_action_progress().
Date: Mon, 31 Aug 2020 15:36:41 +0000 [thread overview]
Message-ID: <DA0C2761-A024-4D7D-8E78-37649812D037@ddn.com> (raw)
In-Reply-To: <87pn77qx60.fsf@notabene.neil.brown.name>
I don't think anything is actually monitoring or using the results of those extents, specifically. "bytes copied" would be equally useful to the end user, I'd think. Others may have better data on real-world usage, though. So this might be a "code deleted is code debugged" situation.
-Ben
?On 8/31/20, 12:03 AM, "lustre-devel on behalf of NeilBrown" <lustre-devel-bounces at lists.lustre.org on behalf of neilb@suse.de> wrote:
I have a question about llapi_hsm_action_progress(). The documentation
says that every interval sent "must" be unique, and must not overlap
(which not exactly the same as 'unique'). The code (on server side)
only partially enforces this. It causes any request for an empty
interval (start>end) to fail, but otherwise accepts any interval. If it
gets two identical intervals (not just overlapping, but identical), it
ignores the second. This seems weird.
It would make some sense to just accept any interval - all it does is
sum the lengths, and use this to report status, so no corruption would
result. It would also make sense to return an error if an interval
overlaps any previous interval, as this violates the spec. It might
make sense to accept any interval, but only count the overlapped length
once. But the current behaviour of only ignoring exact duplicates is
weird. I tried removing that check, but there is a test (hsm_test 108)
which checks for repeating identical intervals.
I want to clean up this code as I'm converting all users of the lustre
interval-tree to use the upstream-linux interval tree code. What should
I do?
Should I remove test 108 because it is only testing one particular
corner case, or should I improve the code to handle all overlaps
consistently? Would it be OK to fail an overlap (I'd need to change
test 108), it must they be quietly accepted?
Thanks,
NeilBrown
next prev parent reply other threads:[~2020-08-31 15:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-31 4:03 [lustre-devel] Error checking for llapi_hsm_action_progress() NeilBrown
2020-08-31 12:53 ` quentin.bouget at cea.fr
2020-09-01 0:58 ` NeilBrown
2020-09-01 9:33 ` quentin.bouget at cea.fr
2020-09-01 12:07 ` Degremont, Aurelien
2020-09-02 0:36 ` NeilBrown
2020-08-31 15:36 ` Joseph Benjamin Evans [this message]
2020-09-01 1:27 ` NeilBrown
2020-09-01 7:41 ` Degremont, Aurelien
2020-09-01 13:10 ` Joseph Benjamin Evans
2020-09-18 17:33 Nathan Rutman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DA0C2761-A024-4D7D-8E78-37649812D037@ddn.com \
--to=beevans@whamcloud.com \
--cc=lustre-devel@lists.lustre.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).