linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] SCSI postmerge updates for the 6.8+ merge window
Date: Fri, 22 Mar 2024 16:24:17 -0400	[thread overview]
Message-ID: <3b5f3404bc63d59f4093e02c2cbb426a88d0bc70.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAHk-=wg9pvT5YEo_kGo2QGjbC-eRaaQNOZuJYCsM1zaxj+rnug@mail.gmail.com>

On Fri, 2024-03-22 at 12:55 -0700, Linus Torvalds wrote:
> On Fri, 22 Mar 2024 at 12:12, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 
> > Eleven patches that are based on the rw_hint branch of the vfs tree
> > which contained the base block and fs changes needed to support
> > this. 8 patches are in the debug driver and 3 in the core.
> 
> Please people - the number of patches involved is entirely
> immaterial.
> 
> I want my merge messages to say what those patches *do*?
> 
> This whole "how many patches" thing is a disease. It's not even
> remotely interesting. I see the size of the patch in the diffstat,
> and that actually has some meaning in the sense of "how much does
> this pull actually change", whether it's in one patch or a hundred.
> 
> I have absolutely *zero* idea what the above pull request actually
> asks me to pull.
> 
> So I won't.

OK, try this (I've updated the scsi-misc tag with it as well)

The vfs has long had a write lifetime hint mechanism that gives the
expected longevity on storage of the data being written.  f2fs was the
original consumer of this and used the hint for flash data placement
(mostly to avoid write amplification by placing objects with similar
lifetimes in the same erase block).  More recently the SCSI based UFS
(Universal Flash Storage) drivers have wanted to take advantage of this
as well, for the same reasons as f2fs, necessitating plumbing the write
hints through the block layer and then adding it to the SCSI core.  The
vfs write_hints pull you've already taken plumbs this as far as block
and this pull request completes the SCSI core enabling based on a
recently agreed reuse of the old write command group number.  The
additions to the scsi_debug driver are for emulating this property so
we can run tests on it in the absence of an actual UFS device.

James


  reply	other threads:[~2024-03-22 20:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-22 19:12 [GIT PULL] SCSI postmerge updates for the 6.8+ merge window James Bottomley
2024-03-22 19:55 ` Linus Torvalds
2024-03-22 20:24   ` James Bottomley [this message]
2024-03-22 20:34     ` Linus Torvalds
2024-03-22 20:43 ` pr-tracker-bot

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=3b5f3404bc63d59f4093e02c2cbb426a88d0bc70.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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;
as well as URLs for NNTP newsgroup(s).