From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from newverein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 7C84721D49110 for ; Sat, 12 Aug 2017 00:32:06 -0700 (PDT) Date: Sat, 12 Aug 2017 09:34:26 +0200 From: Christoph Hellwig Subject: Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap Message-ID: <20170812073426.GB12679@lst.de> References: <150181368442.32119.13336247800141074356.stgit@dwillia2-desk3.amr.corp.intel.com> <20170805095013.GC14930@lst.de> <20170811104429.GA13736@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Andy Lutomirski Cc: Jan Kara , "linux-nvdimm@lists.01.org" , Linux API , "Darrick J. Wong" , Dave Chinner , "linux-kernel@vger.kernel.org" , linux-xfs@vger.kernel.org, Alexander Viro , linux-fsdevel , Christoph Hellwig List-ID: On Fri, Aug 11, 2017 at 08:57:18PM -0700, Andy Lutomirski wrote: > One thing that makes me quite nervous about S_IOMAP_IMMUTABLE is the > degree to which things go badly if one program relies on it while > another program clears the flag: you risk corrupting unrelated > filesystem metadata. I think a userspace interface to pin the extent > mapping of a file really wants a way to reliably keep it pinned (or to > reliably zap the userspace application if it gets unpinned). The nice thing is that no application can rely on it anyway.. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm