On 10/7/20 3:20 AM, Johannes Thumshirn wrote: > Martin rightfully noted that for normal filesystem IO we have soft limits > in place, to prevent them from getting too big and not lead to > unpredictable latencies. For zone append we only have the hardware limit > in place. > > Cap the max sectors we submit via zone-append to the maximal number of > sectors if the second limit is lower. > > Link: https://lore.kernel.org/linux-btrfs/yq1k0w8g3rw.fsf@xxxxxxxxxxxxxxxxxxxx > Reported-by: Martin K. Petersen <martin.petersen@xxxxxxxxxx> > Signed-off-by: Johannes Thumshirn <johannes.thumshirn@xxxxxxx> > --- > include/linux/blkdev.h | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h > index cf80e61b4c5e..967cd76f16d4 100644 > --- a/include/linux/blkdev.h > +++ b/include/linux/blkdev.h > @@ -1406,7 +1406,10 @@ static inline unsigned int queue_max_segment_size(const struct request_queue *q) > > static inline unsigned int queue_max_zone_append_sectors(const struct request_queue *q) > { > - return q->limits.max_zone_append_sectors; > + > + struct queue_limits *l = q->limits; > + > + return min(l->max_zone_append_sectors, l->max_sectors); As the test robot points out, this won't even compile... How much testing did you do with this? -- Jens Axboe
