Linux block layer
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Bart Van Assche <bvanassche@acm.org>
Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Christoph Hellwig <hch@lst.de>,
	Niklas Cassel <Niklas.Cassel@wdc.com>,
	Avri Altman <Avri.Altman@wdc.com>, Bean Huo <huobean@gmail.com>,
	Daejun Park <daejun7.park@samsung.com>
Subject: Re: [PATCH v3 00/14] Pass data temperature information to SCSI disk devices
Date: Wed, 18 Oct 2023 13:09:57 -0600	[thread overview]
Message-ID: <3f3c2289-3185-4895-92cb-0692e3ca9ebc@kernel.dk> (raw)
In-Reply-To: <20231017204739.3409052-1-bvanassche@acm.org>

On 10/17/23 2:47 PM, Bart Van Assche wrote:
> Hi Jens,
> 
> UFS vendors need the data lifetime information to achieve good performance.
> Without this information there is significantly higher write amplification due
> to garbage collection. Hence this patch series that add support in F2FS and
> also in the block layer for data lifetime information. The SCSI disk (sd)
> driver is modified such that it passes write hint information to SCSI devices
> via the GROUP NUMBER field.
> 
> Please consider this patch series for the next merge window.

My main hesitation with this is that there's a big gap between what
makes theoretical sense and practical sense. When we previously tried
this, turns out devices retained the data temperature on media, as
expected, but tossed it out when data was GC'ed. That made it more of a
benchmarking case than anything else. How do we know that things are
better now? In previous postings I've seen you point at some papers, but
I'm mostly concerned with practical use cases and devices. Are there any
results, at all, from that? Or is this a case of vendors asking for
something to check some marketing boxes or have value add?

I can take a closer look once this is fully understood. Not adding
something like this without proper justification.

I'm also really against growing struct bio just for this. Why is patch 2
not just using the ioprio field at least?

-- 
Jens Axboe


  parent reply	other threads:[~2023-10-18 19:10 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-17 20:47 [PATCH v3 00/14] Pass data temperature information to SCSI disk devices Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 01/14] fs: Move enum rw_hint into a new header file Bart Van Assche
2023-10-30 11:11   ` Kanchan Joshi
2023-10-30 16:10     ` Bart Van Assche
2023-11-01  6:39       ` Daejun Park
2023-11-01 16:45         ` (2) " Bart Van Assche
2023-11-02  7:31           ` Daejun Park
2023-10-17 20:47 ` [PATCH v3 02/14] block: Restore data lifetime support in struct bio and struct request Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 03/14] fs: Restore write hint support Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 04/14] fs/f2fs: Restore data lifetime support Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 05/14] scsi: core: Query the Block Limits Extension VPD page Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 06/14] scsi_proto: Add structures and constants related to I/O groups and streams Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 07/14] sd: Translate data lifetime information Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 08/14] scsi_debug: Reduce code duplication Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 09/14] scsi_debug: Support the block limits extension VPD page Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 10/14] scsi_debug: Rework page code error handling Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 11/14] scsi_debug: Rework subpage " Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 12/14] scsi_debug: Implement the IO Advice Hints Grouping mode page Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 13/14] scsi_debug: Implement GET STREAM STATUS Bart Van Assche
2023-10-17 20:47 ` [PATCH v3 14/14] scsi_debug: Maintain write statistics per group number Bart Van Assche
2023-10-18 19:09 ` Jens Axboe [this message]
2023-10-18 19:34   ` [PATCH v3 00/14] Pass data temperature information to SCSI disk devices Bart Van Assche
2023-10-19  0:33     ` Damien Le Moal
2023-10-19 16:48       ` Bart Van Assche
2023-10-19 22:40         ` Damien Le Moal
2023-10-19 23:00           ` Damien Le Moal
2023-10-20 20:45   ` Bart Van Assche

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=3f3c2289-3185-4895-92cb-0692e3ca9ebc@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=Avri.Altman@wdc.com \
    --cc=Niklas.Cassel@wdc.com \
    --cc=bvanassche@acm.org \
    --cc=daejun7.park@samsung.com \
    --cc=hch@lst.de \
    --cc=huobean@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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