Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp6622717ybf; Fri, 6 Mar 2020 01:12:27 -0800 (PST) X-Google-Smtp-Source: ADFU+vuo8D5FAa9TtqAu24f4HefJnKF3gvwR7wzZAoSHR3vIRZ/bb296y/Tn8UIYYBiBt9brTItJ X-Received: by 2002:aca:c0c5:: with SMTP id q188mr1785072oif.169.1583485947111; Fri, 06 Mar 2020 01:12:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583485947; cv=none; d=google.com; s=arc-20160816; b=zYRYkHRyLEtonzUCbWBzTQj9pOW1muHJ2CMcTmAAo7fkp7arVS8HuHf7y00zClKYVU z/Bfj10trZAN48tCcmKSaTrO/jXJwwdy+s7GNvcvcXn9DGafX/nmWQmOFZJoGOE/0Fxn DAxYNBeWKaVcJHI3hyRQ2qcOcydE4ygXNEFMcRA/TPctKYwUbZ5hUY173aqlZispm3Av Hu0lEu/0lS4Pj3if9wFIewvCfyA9WGIUJFhhPZz51q7fpQjYQVxytE/TENpAvZ/Am6Lu BoxfOnG7jPSwu+kVCLtBl3SIxXr3m9H+1U135KwKai+Zq1GSWLQe/y9UunA+wDOBbuGl ZkZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject; bh=+m3u6b2SecrvrI7n3udJZjyKonlxEIMnnwWxLBPJFxw=; b=a3PeSf4ksO6yxEMOO9O1ikf8SzTUrknzIuU5PMJpBcy1o0ek4ssdcIbL2AKyL2s9DU rYojHjoDqsOym0+qizXoNI7O46WxMxkvcts+aSXrHR4gx174jKvbmhVUak+/fVxSdA4L OA5d557Oku6d3CIk65l9EdfoV+kJviNUaORHWKGN6Zd3EL5RwajWMS/gLijZgWE88nBZ 2AeezCSd2oaCepkqPtBxubkzJ9heoQyPW93t8NCVFzrqIImawI38UVXLlAQE+pFqo0+s 6BKIuby7nCyl/Mln0rTtp0j7TEcUWaxaRonSrS6eFULpWCZrUAzqtSU/S5UNGNAAUC/i OwLw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e26si1008800otk.251.2020.03.06.01.12.14; Fri, 06 Mar 2020 01:12:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726047AbgCFJLu (ORCPT + 99 others); Fri, 6 Mar 2020 04:11:50 -0500 Received: from relay.sw.ru ([185.231.240.75]:56530 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725927AbgCFJLu (ORCPT ); Fri, 6 Mar 2020 04:11:50 -0500 Received: from dhcp-172-16-24-104.sw.ru ([172.16.24.104]) by relay.sw.ru with esmtp (Exim 4.92.3) (envelope-from ) id 1jA90m-0002l2-Cd; Fri, 06 Mar 2020 12:11:16 +0300 Subject: Re: [PATCH v7 0/6] block: Introduce REQ_ALLOCATE flag for REQ_OP_WRITE_ZEROES From: Kirill Tkhai To: axboe@kernel.dk Cc: martin.petersen@oracle.com, bob.liu@oracle.com, darrick.wong@oracle.com, agk@redhat.com, snitzer@redhat.com, dm-devel@redhat.com, song@kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, Chaitanya.Kulkarni@wdc.com, ming.lei@redhat.com, osandov@fb.com, jthumshirn@suse.de, minwoo.im.dev@gmail.com, damien.lemoal@wdc.com, andrea.parri@amarulasolutions.com, hare@suse.com, tj@kernel.org, ajay.joshi@wdc.com, sagi@grimberg.me, dsterba@suse.com, bvanassche@acm.org, dhowells@redhat.com, asml.silence@gmail.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org References: <158157930219.111879.12072477040351921368.stgit@localhost.localdomain> Message-ID: <69c0b8a4-656f-98c4-eb55-2fd1184f5fc9@virtuozzo.com> Date: Fri, 6 Mar 2020 12:11:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ping On 13.02.2020 10:55, Kirill Tkhai wrote: > Hi, Jens, > > could you please provide some comments on this? I sent v1 two months ago, > and it would be great to know your vision of the functionality and > the approach and whether it is going to go to block tree. > > Thanks, > Kirill > > On 13.02.2020 10:39, Kirill Tkhai wrote: >> (was "[PATCH block v2 0/3] block: Introduce REQ_NOZERO flag >> for REQ_OP_WRITE_ZEROES operation"; >> was "[PATCH RFC 0/3] block,ext4: Introduce REQ_OP_ASSIGN_RANGE >> to reflect extents allocation in block device internals") >> >> v7: Two comments changed. >> >> v6: req_op() cosmetic change. >> >> v5: Kill dm|md patch, which disables REQ_ALLOCATE for these devices. >> Disable REQ_ALLOCATE for all stacking devices instead of this. >> >> v4: Correct argument for mddev_check_write_zeroes(). >> >> v3: Rename REQ_NOZERO to REQ_ALLOCATE. >> Split helpers to separate patches. >> Add a patch, disabling max_allocate_sectors inheritance for dm. >> >> v2: Introduce new flag for REQ_OP_WRITE_ZEROES instead of >> introduction a new operation as suggested by Martin K. Petersen. >> Removed ext4-related patch to focus on block changes >> for now. >> >> Information about continuous extent placement may be useful >> for some block devices. Say, distributed network filesystems, >> which provide block device interface, may use this information >> for better blocks placement over the nodes in their cluster, >> and for better performance. Block devices, which map a file >> on another filesystem (loop), may request the same length extent >> on underlining filesystem for less fragmentation and for batching >> allocation requests. Also, hypervisors like QEMU may use this >> information for optimization of cluster allocations. >> >> This patchset introduces REQ_ALLOCATE flag for REQ_OP_WRITE_ZEROES, >> which makes a block device to allocate blocks instead of actual >> blocks zeroing. This may be used for forwarding user's fallocate(0) >> requests into block device internals. E.g., in loop driver this >> will result in allocation extents in backing-file, so subsequent >> write won't fail by the reason of no available space. Distributed >> network filesystems will be able to assign specific servers for >> specific extents, so subsequent write will be more efficient. >> >> Patches [1-3/6] are preparation on helper functions, patch [4/6] >> introduces REQ_ALLOCATE flag and implements all the logic, >> patch [5/6] adds one more helper, patch [6/6] adds loop >> as the first user of the flag. >> >> Note, that here is only block-related patches, example of usage >> for ext4 with a performance numbers may be seen in [1]. >> >> [1] https://lore.kernel.org/linux-ext4/157599697369.12112.10138136904533871162.stgit@localhost.localdomain/T/#me5bdd5cc313e14de615d81bea214f355ae975db0 >> --- >> >> Kirill Tkhai (6): >> block: Add @flags argument to bdev_write_zeroes_sectors() >> block: Pass op_flags into blk_queue_get_max_sectors() >> block: Introduce blk_queue_get_max_write_zeroes_sectors() >> block: Add support for REQ_ALLOCATE flag >> block: Add blk_queue_max_allocate_sectors() >> loop: Add support for REQ_ALLOCATE >> >> >> block/blk-core.c | 6 +++--- >> block/blk-lib.c | 17 ++++++++++------- >> block/blk-merge.c | 9 ++++++--- >> block/blk-settings.c | 17 +++++++++++++++++ >> drivers/block/loop.c | 20 +++++++++++++------- >> drivers/md/dm-kcopyd.c | 2 +- >> drivers/target/target_core_iblock.c | 4 ++-- >> fs/block_dev.c | 4 ++++ >> include/linux/blk_types.h | 6 ++++++ >> include/linux/blkdev.h | 34 ++++++++++++++++++++++++++-------- >> 10 files changed, 88 insertions(+), 31 deletions(-) >> >> -- >> Signed-off-by: Kirill Tkhai >> Reviewed-by: Bob Liu >> >