From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1759C00306 for ; Thu, 5 Sep 2019 18:51:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9F3852082C for ; Thu, 5 Sep 2019 18:51:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390457AbfIESvx (ORCPT ); Thu, 5 Sep 2019 14:51:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46642 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388895AbfIESvx (ORCPT ); Thu, 5 Sep 2019 14:51:53 -0400 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BF6A0C0546F2 for ; Thu, 5 Sep 2019 18:51:52 +0000 (UTC) Received: by mail-wr1-f72.google.com with SMTP id x12so1406432wrs.0 for ; Thu, 05 Sep 2019 11:51:52 -0700 (PDT) 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=/+X/R0y41DuJD8stDaaFF/mk4jlVxfRDTjRBOtakznc=; b=iT3Pe6eLMqniuOmVDsCBK4dT55I3j+/xN6D76ptuHtqd2bEpFP2Z1C90Tfw0PEa04h vLy712p42t1qX7CutLgX9GvowU4G0vxaCEpZZIme0pWLUGpFbZQmPQ1+j5jc3x+XRdhb XA1FjefTodZyPaaKo1u/Cnw8JzkIWAg73QXxBM+bPUxFiteE30tCtFDW3m6wc578cqrN StQsz0IBcxbb+MVCv1kIcXlhyqufhDc1bllsMAs6+imvQ0fFSTMnuwp2btaW1eUDo8ho V3uTZtMHpAsHou0LpTS0dSQ56LYHeIc95mHFCSbEAhYWGsadnFifA5nkZy91P1BeQVh4 D3JA== X-Gm-Message-State: APjAAAU3njsIIurd4yqZoPZtq4C5N1y+ZF4W+sQ1rC58yIrXAwLqt7FJ F0Z/CsgZcKHIFUgVOY5n3aYs2V3RvaQ/Sc8pNss9oD/GcT7n4+AMKF3qYjHzltfE1XZREiGdtE0 Dn/gWHhzMxBuyJxUmB/Janj6Vsty2JK9MOi0lCMw= X-Received: by 2002:a05:600c:21d1:: with SMTP id x17mr3763572wmj.123.1567709511265; Thu, 05 Sep 2019 11:51:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqxxppOJbXRzr0HT1qBIm7hjC+zxuRCss37FvJwDjsHuKSxoe+byuVe16izziNYRTPD8dFxdzcLlPcTR/VI7zzA= X-Received: by 2002:a05:600c:21d1:: with SMTP id x17mr3763540wmj.123.1567709510985; Thu, 05 Sep 2019 11:51:50 -0700 (PDT) MIME-Version: 1.0 References: <156763534546.18676.3530557439501101639.stgit@warthog.procyon.org.uk> <17703.1567702907@warthog.procyon.org.uk> <11667f69-fbb5-28d2-3c31-7f865f2b93e5@redhat.com> In-Reply-To: <11667f69-fbb5-28d2-3c31-7f865f2b93e5@redhat.com> From: Ray Strode Date: Thu, 5 Sep 2019 14:51:14 -0400 Message-ID: Subject: Re: Why add the general notification queue and its sources To: Steven Whitehouse Cc: Linus Torvalds , David Howells , Greg Kroah-Hartman , Nicolas Dichtel , raven@themaw.net, keyrings@vger.kernel.org, linux-usb@vger.kernel.org, linux-block , Christian Brauner , LSM List , linux-fsdevel , Linux API , Linux List Kernel Mailing , David Lehman , Ian Kent Content-Type: text/plain; charset="UTF-8" Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Hi, On Thu, Sep 5, 2019 at 2:37 PM Steven Whitehouse wrote: > The original reason for the mount notification mechanism was so that we > are able to provide information to GUIs and similar filesystem and > storage management tools, matching the state of the filesystem with the > state of the underlying devices. This is part of a larger project > entitled "Project Springfield" to try and provide better management > tools for storage and filesystems. I've copied David Lehman in, since he > can provide a wider view on this topic. So one problem that I've heard discussed before is what happens in a thinp setup when the disk space is overallocated and gets used up. IIRC, the volumes just sort of eat themselves? Getting proper notification of looming catastrophic failure to the workstation user before it's too late would be useful, indeed. I don't know if this new mechanism dhowells has development can help with that, and/or if solving that problem is part of the Project Springfield initiative or not. Do you know off hand? --Ray From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ray Strode Date: Thu, 05 Sep 2019 18:51:14 +0000 Subject: Re: Why add the general notification queue and its sources Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit List-Id: References: <156763534546.18676.3530557439501101639.stgit@warthog.procyon.org.uk> <17703.1567702907@warthog.procyon.org.uk> <11667f69-fbb5-28d2-3c31-7f865f2b93e5@redhat.com> In-Reply-To: <11667f69-fbb5-28d2-3c31-7f865f2b93e5@redhat.com> To: Steven Whitehouse Cc: Linus Torvalds , David Howells , Greg Kroah-Hartman , Nicolas Dichtel , raven@themaw.net, keyrings@vger.kernel.org, linux-usb@vger.kernel.org, linux-block , Christian Brauner , LSM List , linux-fsdevel , Linux API , Linux List Kernel Mailing , David Lehman , Ian Kent Hi, On Thu, Sep 5, 2019 at 2:37 PM Steven Whitehouse wrote: > The original reason for the mount notification mechanism was so that we > are able to provide information to GUIs and similar filesystem and > storage management tools, matching the state of the filesystem with the > state of the underlying devices. This is part of a larger project > entitled "Project Springfield" to try and provide better management > tools for storage and filesystems. I've copied David Lehman in, since he > can provide a wider view on this topic. So one problem that I've heard discussed before is what happens in a thinp setup when the disk space is overallocated and gets used up. IIRC, the volumes just sort of eat themselves? Getting proper notification of looming catastrophic failure to the workstation user before it's too late would be useful, indeed. I don't know if this new mechanism dhowells has development can help with that, and/or if solving that problem is part of the Project Springfield initiative or not. Do you know off hand? --Ray