Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp151683imj; Thu, 14 Feb 2019 17:27:45 -0800 (PST) X-Google-Smtp-Source: AHgI3IYPzBGZG2Lo6FkeqtKy/znrQw1SapwE5DSKhpoV+mJ1Qp8E7q8N7uUY8BI9WnPtZwgKw6D5 X-Received: by 2002:a17:902:684:: with SMTP id 4mr7330426plh.3.1550194065065; Thu, 14 Feb 2019 17:27:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550194065; cv=none; d=google.com; s=arc-20160816; b=g4uocqoa/PbSpJ2hxKgnvwrgfH1QEpl5dQlP/0ys2hxNk4iCFJ3OH+KCye4M+Ln145 tBsYJbVg+RfinOTncKVysQR82rPRorjlB4+LV+WwKvrQCeseNOzctFVLkwPaKgi/6lw5 ZzlMXiCh5hTOXuX0ruU8oXepAGTVlvsoUZqaiLjHggmNgQpE/ceKRvTfyccwHomiVud4 lMTzcfiqlkiKmToABEXNLG0I8rLD/O1+3jzSH5GehkiLHWjw912b4eIW9sfRcPuVK80A 7IMmyFayGw8GmRpPm1bSK+MQqG298K3U60yCYDfYsAlIpEDpHbQSkjjmH0OlYw93ymcc NlQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=cNdmBhJV6l2CrpOn23AdUvuvbdoQzPMeGeladPJyn9A=; b=B6AYzluJWjqypjg+FiameKAGt7HyOC0uE+3YiUUiAVv3i9Mo1gSxIo0biS6acB6+wF BGmmp3s56raqJHnLeWbTz7ROYk5WyW6faXrFD8VH1HNj7z7ohVCX+B6I0RYDPe9D/ecN zZBoHVPLuXQOhdAynInBNaNWmEybmjBgNfklJFEUDjLqWIQjqM2fLQKVMRuo0xSx/3Ur KA6vr1mMJuD+eM2ohIMU+XurTsGJK7C32xetqTba+62T6uOH/DcKdJGdQF4qvD7sRmfc aM0PWzs0PGQP1e69ImeWOUIJUCiWRkxCaw3G9jaOJr8NdpoZQA9LEyQworqUBIIfLZi9 1tZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=kApAc8ju; 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=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f75si4025741pff.131.2019.02.14.17.27.29; Thu, 14 Feb 2019 17:27:45 -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; dkim=pass header.i=@chromium.org header.s=google header.b=kApAc8ju; 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=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389306AbfBNSAu (ORCPT + 99 others); Thu, 14 Feb 2019 13:00:50 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:35495 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730119AbfBNSAu (ORCPT ); Thu, 14 Feb 2019 13:00:50 -0500 Received: by mail-lj1-f196.google.com with SMTP id j13-v6so6063689ljc.2 for ; Thu, 14 Feb 2019 10:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cNdmBhJV6l2CrpOn23AdUvuvbdoQzPMeGeladPJyn9A=; b=kApAc8juLL1jfsml6kvJ912qHNEFbMQMO0HAg6aPT+R9mD7nmIVEz9780OYMNDENsy 5KLMqJuFyeTsEIyCMUFclXbwU7ny5JbACEz1fgVxx2hHfBVKBTdRRLgqMPi14FyENs/b phPeh1WjjPTFjNPwtwKLdYKZ2aZAM/miG+sR0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cNdmBhJV6l2CrpOn23AdUvuvbdoQzPMeGeladPJyn9A=; b=o2N0SGCuYrscyzcQlAnuQEVPr7Ysf1JTGhc0Cpoe5mFjQfNIjvv09KQHIZoe+5EoEb JtqgMEHL6z557/6P+Qwfxd+rKdw+SxIrGlZA4NmcpptLnBnw3xbEE0PJm5op3lqIhafA /wUjY+JVGa8EaDw4T9mabO+zMNjyfIj6Yl3beRTSno+4YZ86psU0kKBeoNQ4hYKx795D jzn+8L0YsM2Unbub2ZMx+kctsj8536Y+Jqr0tEcrFkvO2slkgJQRHW9Yfsk6jmT7Ljtt EU1KWPlnc5ivXpfsXgnONOWoGsQKlEfKa4eA22I5dSLclu9TybZloW6WPBhlUc+umHYA xOfA== X-Gm-Message-State: AHQUAuZJjwivBkv1pdLOjFg40R59cH6AgIKJRt7hZ4KxC6V2p8LRBqTJ 6m7sEsWtdiOTJntBvTavbzGGY/ajnNM= X-Received: by 2002:a2e:8105:: with SMTP id d5-v6mr3375665ljg.76.1550167247746; Thu, 14 Feb 2019 10:00:47 -0800 (PST) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com. [209.85.208.179]) by smtp.gmail.com with ESMTPSA id r10-v6sm554310ljj.71.2019.02.14.10.00.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 10:00:47 -0800 (PST) Received: by mail-lj1-f179.google.com with SMTP id z20so5026607ljj.10 for ; Thu, 14 Feb 2019 10:00:47 -0800 (PST) X-Received: by 2002:a2e:99c9:: with SMTP id l9mr2782851ljj.60.1550167242216; Thu, 14 Feb 2019 10:00:42 -0800 (PST) MIME-Version: 1.0 References: <20190207205730.199332-1-evgreen@chromium.org> <20190207205730.199332-3-evgreen@chromium.org> In-Reply-To: From: Evan Green Date: Thu, 14 Feb 2019 10:00:05 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 2/2] loop: Better discard support for block devices To: "Martin K. Petersen" Cc: Jens Axboe , Bart Van Assche , Gwendal Grignou , Alexis Savery , Ming Lei , linux-block , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 13, 2019 at 6:40 PM Martin K. Petersen wrote: > > > Evan, > > > If the backing device for a loop device is a block device, then mirror > > the discard properties of the underlying block device into the loop > > device. While in there, differentiate between REQ_OP_DISCARD and > > REQ_OP_WRITE_ZEROES, which are different for block devices, but which > > the loop device had just been lumping together. > > Bubbling up the queue limits from the backing device is fine. However, > I'm not sure why you are requiring a filesystem to be on a > discard-capable device for REQ_OP_DISCARD to have an effect? Punching a > hole in a file is semantically the same as discarding. > Hi Martin, Thanks so much for taking a look at this patch, I was getting nervous it was languishing again. I got confused by this comment though. My intention was to not change behavior for loop devices backed by a regular file system file. The changes in loop_config_discard() should result in QUEUE_FLAG_DISCARD being set for backings of regular files that support f_op->fallocate(), same as before my patch. The change in lo_discard() to call blk_queue_discard() on the loopback queue itself was just shorthand to avoid duplicating all those if statements from loop_config_discard again. Am I missing a spot where I've implicitly changed the behavior for file-backed loop devices? -Evan