Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp839524img; Tue, 26 Feb 2019 09:25:57 -0800 (PST) X-Google-Smtp-Source: AHgI3IbFD4eE1c7OlLrs+BHOCBRGgsfUVSrPP8xH8KsscO82NYZhpPfT21dhkqbRGixspALcYFKR X-Received: by 2002:a63:6a47:: with SMTP id f68mr25168171pgc.82.1551201957814; Tue, 26 Feb 2019 09:25:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551201957; cv=none; d=google.com; s=arc-20160816; b=vngwSXjtsUZLlM1Isq6Tu/xBwqy/6j+BWgGRM0/07jFqIUijDyoJLDPuMMvT3zcc8A Rw8IhN79Q6qdKfKAENlQBGxtY6r6iIHgA0NCbsoBGFaVKZYqvURtJQso6Sea6RJKDIZm n4fVbRFb1WHpGsn1FL4P8FJB24VswiraC5pxPxhlC+Djz1nMxYGSwfqxu6YLNult7NTj an9bKxyPfM5bmA8isbEtd9zzjErbRU+CkdwExWegqvI/EA8LCHW4GMwDXHfSkrr6f2Sf O0z2i0JUcKOfGz8SYFQqOEBzZ/y7Zf4UDLsBLutg/D8wGFbYeJ3gtj0c6wywk1jEPC6H xtBw== 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=9RhU8uM0ad+0+mYh4+yrj9Diioag2qapPokY1EYhEhY=; b=kyFf/CLSsNlJNO7aR5u+8j/VLerld7eHJNwOhW9RdVoDeroaKV8QmQ3vrVbyCpIDwd Ih+c/l+R0+VoCbF2Nr0YM981mGc69lFT1eCdhxkQPJvmwZGPtLJWWJFcCWnTlq3h+IIZ dRrUJy8Fdv7RnFW/TQr4B6alTriy2KKJl6IJ/eHDcVnaCMrdampN/oI+3y6Jv4s1G2dv g+UuxyF0PpIfcQXMt0InykMwWuUFJZVMlCIUxUUB9vdkuoBz22VWVBQPGJRH8yEiISYG rqjsg5t7+Ktj4KPdNjJaqD9rBL9bp/qHONOdMDHUgCvH711ENT0kCpJc5HiS5JIHmyao 7efQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="V4/9s7fu"; 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 p33si12836369pld.132.2019.02.26.09.25.40; Tue, 26 Feb 2019 09:25:57 -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="V4/9s7fu"; 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 S1728303AbfBZRX4 (ORCPT + 99 others); Tue, 26 Feb 2019 12:23:56 -0500 Received: from mail-lf1-f66.google.com ([209.85.167.66]:35181 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727054AbfBZRXz (ORCPT ); Tue, 26 Feb 2019 12:23:55 -0500 Received: by mail-lf1-f66.google.com with SMTP id m73so4670070lfa.2 for ; Tue, 26 Feb 2019 09:23:54 -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=9RhU8uM0ad+0+mYh4+yrj9Diioag2qapPokY1EYhEhY=; b=V4/9s7fusoKlP5TdYrlE40KrLOJs5jr9+p0GabO7V7BSBppp76w4X4LFDhHrt7GZTI hyM0pPL5rAKMNj+C3UV7FuJt6YF+K1UO/NL/wFRmF8QhzrGcY8wkZWk0p1ieN546u75F QcPU39mz0C9u4xzEzZOG4TRF/SHIZCgHkuFsE= 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=9RhU8uM0ad+0+mYh4+yrj9Diioag2qapPokY1EYhEhY=; b=iaoQPWIcGNW7UPd6Ls4f58YZ+HG7PpLTHguSR3oeVQdoXO5WIbWja4RSJtb+ARvyfY xTfL5i144//wWX+08e5tOuKPtPYRxbT5/K+G86Wod6uoLNEGObAzPTJ4fuTUb8m52+z6 B3FTDVqfsCwIXZPS6I0yoIwKT9VE08EAAyLfCRTNzHz6DEOANsDtVVkoxRhyl3nFopld tbmqo5cfCpIAQvsWoPxSZh69rcRVRW8jlS5FL+j8CterZiKbPPmS+WODoASWXU/JjkC8 DvfsPxlrMngnB0HVe0LmlEljVEf4GYz/HptMSSOs+6PjR9Ci0lg0FbCwOitJMjZmG+Ev fP4w== X-Gm-Message-State: AHQUAubRj1IcRgD9OEGhvXtn/YKSxxeERB4qKANig421LOjnVcwnGpPe 08Fb45K+fwrzg1rn/WoZ7OsbOwEqwbo= X-Received: by 2002:ac2:4436:: with SMTP id w22mr4190976lfl.155.1551201833991; Tue, 26 Feb 2019 09:23:53 -0800 (PST) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com. [209.85.208.181]) by smtp.gmail.com with ESMTPSA id e21sm66342lfc.90.2019.02.26.09.23.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 09:23:53 -0800 (PST) Received: by mail-lj1-f181.google.com with SMTP id l5so11513993lje.1 for ; Tue, 26 Feb 2019 09:23:52 -0800 (PST) X-Received: by 2002:a2e:9ad1:: with SMTP id p17mr14356563ljj.30.1551201831984; Tue, 26 Feb 2019 09:23:51 -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: Tue, 26 Feb 2019 09:23:13 -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 Thu, Feb 14, 2019 at 10:00 AM Evan Green wrote: > > 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 Hi Martin, Did you get a chance to take a look at my reply? This error log plagues our Chrome OS installer, and I'm hopeful I've found an approach here that's upstream-friendly. But if it's not, let me know and I can fix it. -Evan