From: Hao Wang <pkuwangh@gmail.com>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Christoph Hellwig <hch@infradead.org>, Linux-nvme@lists.infradead.org
Subject: Re: Data corruption when using multiple devices with NVMEoF TCP
Date: Wed, 23 Dec 2020 14:23:44 -0800 [thread overview]
Message-ID: <CAJS6EdjusB9DWtaj=FOW1AxJmb7jA1-C+8TqwWN-TBqMM-Awig@mail.gmail.com> (raw)
In-Reply-To: <ad826e9c-021b-7750-314a-f44ef58944f9@grimberg.me>
Sure. I will try to build a new kernel.
This is in an enterprise environment, so it's just really convenient
for me to run with v5.2 or v5.6. For newer kernel, I will have to
build myself. But I will give it a try.
Regarding max_sectors_kb, there seems something interesting:
So on the target side, I see:
# cat /sys/block/nvme1n1/queue/max_sectors_kb
256
#/sys/block/nvme2n1/queue/max_sectors_kb
256
On the initiator side,
* first, there is both /sys/block/nvme1c1n1 and /sys/block/nvme1n1
* and their max_sectors_kb is 1280.
Then when I create a raid-0 volume with mdadm,
# /sys/block/md5
128
I'm not an expert on storage, but do you see any potential problem here?
Hao
On Wed, Dec 23, 2020 at 1:23 PM Sagi Grimberg <sagi@grimberg.me> wrote:
>
>
> > Wouldn't testing with a not completely outdated kernel a better first
> > step?
>
> Right, didn't notice that. Hao, would it be possible to test this
> happens with the latest upstream kernel (or something close to that)?
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-12-23 22:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-22 18:09 Data corruption when using multiple devices with NVMEoF TCP Hao Wang
2020-12-22 19:29 ` Sagi Grimberg
2020-12-22 19:58 ` Hao Wang
2020-12-23 8:41 ` Sagi Grimberg
2020-12-23 8:43 ` Christoph Hellwig
2020-12-23 21:23 ` Sagi Grimberg
2020-12-23 22:23 ` Hao Wang [this message]
2020-12-24 1:51 ` Hao Wang
2020-12-24 2:57 ` Sagi Grimberg
2020-12-24 10:28 ` Hao Wang
2020-12-24 17:56 ` Sagi Grimberg
2020-12-25 7:49 ` Hao Wang
2020-12-25 9:05 ` Sagi Grimberg
[not found] ` <CAJS6Edgb+yCW5q5dA=MEkL0eYs4MXoopdiz72nhkxpkd5Fe_cA@mail.gmail.com>
2020-12-29 1:25 ` Sagi Grimberg
2021-01-06 1:53 ` Sagi Grimberg
2021-01-06 8:21 ` Hao Wang
2021-01-11 8:56 ` Hao Wang
2021-01-11 10:11 ` Sagi Grimberg
[not found] ` <CAJS6Edi9Es1zR9QC+=kwVjAFAGYrEru4vibW42ffyWoMDutFhQ@mail.gmail.com>
2021-01-12 0:36 ` Sagi Grimberg
2021-01-12 1:29 ` Sagi Grimberg
2021-01-12 2:22 ` Ming Lei
2021-01-12 6:49 ` Sagi Grimberg
2021-01-12 8:55 ` Hao Wang
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='CAJS6EdjusB9DWtaj=FOW1AxJmb7jA1-C+8TqwWN-TBqMM-Awig@mail.gmail.com' \
--to=pkuwangh@gmail.com \
--cc=Linux-nvme@lists.infradead.org \
--cc=hch@infradead.org \
--cc=sagi@grimberg.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.