On Tue, Aug 9, 2016 at 1:47 AM, Hannes Reinecke <hare@xxxxxxx> wrote: > On 08/05/2016 10:35 PM, Shaun Tancheff wrote: >> On Tue, Aug 2, 2016 at 8:29 PM, Damien Le Moal <Damien.LeMoal@xxxxxxxx> wrote: >>>> On Aug 2, 2016, at 23:35, Hannes Reinecke <hare@xxxxxxx> wrote: >>>> On 08/01/2016 07:07 PM, Shaun Tancheff wrote: >>>>> On Mon, Aug 1, 2016 at 4:41 AM, Christoph Hellwig <hch@xxxxxx> wrote: [trim] >> Also the zone report is 'slow' in that there is an overhead for the >> report itself but >> the number of zones per query can be quite large so 4 or 5 I/Os that >> run into the >> hundreds if milliseconds to cache the entire drive isn't really unworkable for >> something that is used infrequently. >> > No, surely not. > But one of the _big_ advantages for the RB tree is blkdev_discard(). > Without the RB tree any mkfs program will issue a 'discard' for every > sector. We will be able to coalesce those into one discard per zone, but > we still need to issue one for _every_ zone. > Which is (as indicated) really slow, and easily takes several minutes. > With the RB tree we can short-circuit discards to empty zones, and speed > up processing time dramatically. > Sure we could be moving the logic into mkfs and friends, but that would > require us to change the programs and agree on a library (libzbc?) which > should be handling that. Adding an additional library dependency seems overkill for a program that is already doing ioctls and raw block I/O ... but I would leave that up to each file system. As it sits issuing the ioctl and walking the array of data returned [see blkreport.c] is already quite trivial. I believe the goal here is for F2FS, and perhaps NILFS? to "just work" with the DISCARD to Reset WP and zone cache in place. Still quite skeptical about other common file systems "just working" without their respective mkfs et. al. being zone aware and handling the topology of the media at mkfs time. Perhaps there is something I am unaware of? [trim] >> I can add finish zone ... but I really can't think of a use for it, myself. >> > Which is not the point. The standard defines this, so clearly someone > found it a reasonable addendum. So let's add this for completeness. Agreed and queued for the next version. Regards, Shaun -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
