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.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc
The short changelog is:
Bart Van Assche (11):
scsi: scsi_debug: Maintain write statistics per group number
scsi: scsi_debug: Implement GET STREAM STATUS
scsi: scsi_debug: Implement the IO Advice Hints Grouping mode page
scsi: scsi_debug: Allocate the MODE SENSE response from the heap
scsi: scsi_debug: Rework subpage code error handling
scsi: scsi_debug: Rework page code error handling
scsi: scsi_debug: Support the block limits extension VPD page
scsi: scsi_debug: Reduce code duplication
scsi: sd: Translate data lifetime information
scsi: scsi_proto: Add structures and constants related to I/O groups and streams
scsi: core: Query the Block Limits Extension VPD page
And the diffstat:
drivers/scsi/Kconfig | 5 +
drivers/scsi/Makefile | 2 +
drivers/scsi/scsi.c | 2 +
drivers/scsi/scsi_debug.c | 293 +++++++++++++++++++++++++++++++----------
drivers/scsi/scsi_proto_test.c | 56 ++++++++
drivers/scsi/scsi_sysfs.c | 10 ++
drivers/scsi/sd.c | 111 +++++++++++++++-
drivers/scsi/sd.h | 3 +
include/scsi/scsi_device.h | 1 +
include/scsi/scsi_proto.h | 78 +++++++++++
10 files changed, 490 insertions(+), 71 deletions(-)
create mode 100644 drivers/scsi/scsi_proto_test.c
James
On Fri, 22 Mar 2024 at 12:12, James Bottomley
<[email protected]> 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.
Linus
On Fri, 2024-03-22 at 12:55 -0700, Linus Torvalds wrote:
> On Fri, 22 Mar 2024 at 12:12, James Bottomley
> <[email protected]> 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
On Fri, 22 Mar 2024 at 13:24, James Bottomley
<[email protected]> wrote:
>
> OK, try this (I've updated the scsi-misc tag with it as well)
Well there we go. I really had no idea what the pull was supposed to do.
And while I end up looking at individual commits for random smaller
subsystems when it's unclear (sometimes just for language barrier
issues), for long-time maintainers of bigger stuff I kind of expect
better.
Linus
The pull request you sent on Fri, 22 Mar 2024 15:12:27 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bfa8f18691ed2e978e4dd51190569c434f93e268
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html