From: Tarun Sahu <tsahu@linux.ibm.com>
To: "Verma, Vishal L" <vishal.l.verma@intel.com>,
"nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>
Cc: "Williams, Dan J" <dan.j.williams@intel.com>,
"aneesh.kumar@linux.ibm.com" <aneesh.kumar@linux.ibm.com>,
"sbhat@linux.ibm.com" <sbhat@linux.ibm.com>,
"vaibhav@linux.ibm.com" <vaibhav@linux.ibm.com>
Subject: Re: [PATCH v4 0/2]ndctl/namespace: Fix and improve write-infoblock
Date: Tue, 13 Sep 2022 15:56:05 +0530 [thread overview]
Message-ID: <e9bb18bae97df6cb574070533198adfb4553c44b.camel@linux.ibm.com> (raw)
In-Reply-To: <0ac88f93980f0da33939178abb16aab0a9d907cc.camel@intel.com>
Hi,
> Hi Tarun,
>
> Sorry for the delay in reviewing these. From a quick look, it looks
> like you're adding read-modify-write functionality to the write-
> infoblock command - is that correct?
>
> I think the original intent of these commands was, purely as a
> debug/test aid, that the user would be responsible for reading the
> namespace if needed, and using that as a basis for writing the
> infoblockl if an RMW operation is desired. However for the most part,
> write-infoblock just creates infoblocks out of thin air, and
> optionally
> writes it to a namepspace. I'm not sure adding a read-modify-write
> here
> is really that useful, unless you have a specific use case for this
> sort of thing?
From the man page, it is not clear that, non-provided args values will
get updated without user concern, and It comes as surprise to user as
user didnt intend to change that. For Example, If user only want to
change the value of uuid of a namespace infoblock, So They perform
write-infoblock with particular uuid but didnt pass align value which
they intended not to change but write-infoblock changes it to default
value.
This patch, read-modify-write takes care of other arguments which are
not passed for the concerned namespace as part of write-infoblock by
retaining the values of them.
Other patch of this series, takes
advantage of the above read-modify-write functionality and implement
write-infoblock for sector/BTT namespaces. Which currently allows only
uuid and parent_uuid updates.
prev parent reply other threads:[~2022-09-13 10:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-27 10:30 [PATCH v4 0/2]ndctl/namespace: Fix and improve write-infoblock Tarun Sahu
2022-05-27 10:30 ` [PATCH v4 1/2] ndctl/namespace: Fix multiple issues with write-infoblock Tarun Sahu
2022-05-27 10:30 ` [PATCH v4 2/2] ndctl/namespace: Implement write-infoblock for sector mode namespaces Tarun Sahu
2022-06-20 9:27 ` [PATCH v4 0/2]ndctl/namespace: Fix and improve write-infoblock Tarun Sahu
2022-08-01 7:50 ` Tarun Sahu
2022-09-13 3:18 ` Verma, Vishal L
2022-09-13 10:26 ` Tarun Sahu [this message]
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=e9bb18bae97df6cb574070533198adfb4553c44b.camel@linux.ibm.com \
--to=tsahu@linux.ibm.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=dan.j.williams@intel.com \
--cc=nvdimm@lists.linux.dev \
--cc=sbhat@linux.ibm.com \
--cc=vaibhav@linux.ibm.com \
--cc=vishal.l.verma@intel.com \
/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