Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1453363

Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands

From Shaun Tancheff <shaun.tancheff@seagate.com>
Newsgroups linux.kernel
Subject Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands
Date 2016-08-01 19:40 +0200
Message-ID <s1pm2-Vl-15@gated-at.bofh.it> (permalink)
References <s0lkt-nb-3@gated-at.bofh.it> <s1i1c-4yM-21@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, Aug 1, 2016 at 4:41 AM, Christoph Hellwig <hch@lst.de> wrote:
>
> Can you please integrate this with Hannes series so that it uses
> his cache of the zone information?

Adding Hannes and Damien to Cc.

Christoph,

I can make a patch the marshal Hannes' RB-Tree into to a block report, that is
quite simple. I can even have the open/close/reset zone commands update the
RB-Tree .. the non-private parts anyway. I would prefer to do this around the
CONFIG_SD_ZBC support, offering the existing type of patch for setups that do
not need the RB-Tree to function with zoned media.

I do still have concerns with the approach which I have shared in smaller
forums but perhaps I have to bring them to this group.

First is the memory consumption. This isn't really much of a concern for large
servers with few drives but I think the embedded NAS market will grumble as
well as the large data pods trying to stuff 300+ drives in a chassis.

As of now the RB-Tree needs to hold ~30000 zones.
sizeof() reports struct blk_zone to use 120 bytes on x86_64. This yields
around 3.5 MB per zoned drive attached.
Which is fine if it is really needed, but most of it is fixed information
and it can be significantly condensed (I have proposed 8 bytes per zone held
in an array as more than adequate). Worse is that the crucial piece of
information, the current wp needed for scheduling the next write, is mostly
out of date because it is updated only after the write completes and zones
being actively written to must work off of the last location / size that was
submitted, not completed. The work around is for that tracking to be handled
in the private_data member. I am not saying that updating the wp on
completing a write isn’t important, I am saying that the bi_end_io hook is
the existing hook that works just fine.

This all tails into domain responsability. With the RB-Tree doing half of the
work and the ‘responsible’ domain handling the active path via private_data
why have the split at all? It seems to be a double work to have second object
tracking the first so that I/O scheduling can function.

Finally is the error handling path when the RB-Tree encounters and error it
attempts to requery the drive topology virtually guaranteeing that the
private_data is now out-of-sync with the RB-Tree. Again this is something
that can be better encapsulated in the bi_end_io to be informed of the
failed I/O and schedule the appropriate recovery (including re-querying the
zone information of the affected zone(s)).

Anyway those are my concerns and why I am still reluctant to drop this line of
support. I have incorporated Hannes changes at various points. Hence the
SCT Write Same to attempt to work around some of the flaws in mapping
discard to reset write pointer.

Thanks and Regards,
Shaun

> --
> To unsubscribe from this list: send the line "unsubscribe linux-block" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_majordomo-2Dinfo.html&d=CwIBAg&c=IGDlg0lD0b-nebmJJ0Kp8A&r=Wg5NqlNlVTT7Ugl8V50qIHLe856QW0qfG3WVYGOrWzA&m=0ZPyN4vfYZXSmuCmIm3wpExF1K28PYO9KmgcqDsfQBg&s=aiguzw5_op7woZCZ5Qi7c36b16SxiWTJXshN0dG3Xyo&e=



-- 
Shaun Tancheff

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v6 0/2] Block layer support ZAC/ZBC commands Shaun Tancheff <shaun@tancheff.com> - 2016-07-29 21:10 +0200
  Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands Christoph Hellwig <hch@lst.de> - 2016-08-01 11:50 +0200
    Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands Shaun Tancheff <shaun.tancheff@seagate.com> - 2016-08-01 19:40 +0200
      Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands Hannes Reinecke <hare@suse.de> - 2016-08-02 17:30 +0200
        Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands Damien Le Moal <Damien.LeMoal@hgst.com> - 2016-08-03 03:40 +0200
          Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands Shaun Tancheff <shaun.tancheff@seagate.com> - 2016-08-05 22:40 +0200
            Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands Hannes Reinecke <hare@suse.de> - 2016-08-09 08:50 +0200
              Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands Damien Le Moal <Damien.LeMoal@hgst.com> - 2016-08-09 10:20 +0200
                Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands Shaun Tancheff <shaun.tancheff@seagate.com> - 2016-08-10 06:00 +0200
              Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands Shaun Tancheff <shaun.tancheff@seagate.com> - 2016-08-10 05:30 +0200

csiph-web