[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240214122719.184946-1-nilay@linux.ibm.com>
Date: Wed, 14 Feb 2024 17:57:19 +0530
From: Nilay Shroff <nilay@...ux.ibm.com>
To: john.g.garry@...cle.com
Cc: alan.adamson@...cle.com, axboe@...nel.dk, brauner@...nel.org,
bvanassche@....org, dchinner@...hat.com, djwong@...nel.org, hch@....de,
jack@...e.cz, jbongio@...gle.com, jejb@...ux.ibm.com,
kbusch@...nel.org, linux-block@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-nvme@...ts.infradead.org, linux-scsi@...r.kernel.org,
linux-xfs@...r.kernel.org, martin.petersen@...cle.com,
ming.lei@...hat.com, ojaswin@...ux.ibm.com, sagi@...mberg.me,
tytso@....edu, viro@...iv.linux.org.uk
Subject: Re: [PATCH v3 14/15] nvme: Support atomic writes
>Support reading atomic write registers to fill in request_queue
>properties.
>Use following method to calculate limits:
>atomic_write_max_bytes = flp2(NAWUPF ?: AWUPF)
>atomic_write_unit_min = logical_block_size
>atomic_write_unit_max = flp2(NAWUPF ?: AWUPF)
>atomic_write_boundary = NABSPF
In case the device doesn't support namespace atomic boundary size (i.e. NABSPF
is zero) then while merging atomic block-IO we should allow merge.
For example, while front/back merging the atomic block IO, we check whether
boundary is defined or not. In case if boundary is not-defined (i.e. it's zero)
then we simply reject merging ateempt (as implemented in
rq_straddles_atomic_write_boundary()).
I am quoting this from NVMe spec (Command Set Specification, revision 1.0a,
Section 2.1.4.3) : "To ensure backwards compatibility, the values reported for
AWUN, AWUPF, and ACWU shall be set such that they are supported even if a
write crosses an atomic boundary. If a controller does not guarantee
atomicity across atomic boundaries, the controller shall set AWUN, AWUPF, and
ACWU to 0h (1 LBA)."
Thanks,
--Nilay
Powered by blists - more mailing lists