From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f54.google.com ([209.85.218.54]:36090 "EHLO mail-oi0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751005AbdAPOQX (ORCPT ); Mon, 16 Jan 2017 09:16:23 -0500 MIME-Version: 1.0 In-Reply-To: References: <1484488652-611-1-git-send-email-amir73il@gmail.com> <1484488652-611-3-git-send-email-amir73il@gmail.com> From: Amir Goldstein Date: Mon, 16 Jan 2017 16:16:17 +0200 Message-ID: Subject: Re: [PATCH 2/6] ovl: check if upperdir fs supports O_TMPFILE To: Miklos Szeredi Cc: Al Viro , "linux-unionfs@vger.kernel.org" , linux-fsdevel Content-Type: text/plain; charset=UTF-8 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Jan 16, 2017 at 4:02 PM, Miklos Szeredi wrote: > On Sun, Jan 15, 2017 at 2:57 PM, Amir Goldstein wrote: >> This is needed for choosing between concurrent copyup >> using O_TMPFILE and legacy copyup using workdir+rename. > > I'm really wondering if we should constrain upper fs to those that: > > - can do RENAME_EXCHANGE and RENAME_WHITEOUT > - can do ->tmpfile() which is currently a superset of the above > - can do xattr, again a superset Makes sense to me. Let me know if you want me to add the rename flag test. > > The question is whether anybody actually using it with an fs that > doesn't have all of the above. Because if so, we need to keep > supporting them. Perhaps we should add warnings about deprecation and > if nobody complains we can remove support for non-conformant fs. > But how exactly do we "support" those fs right now? Any attempt to use them would result in -EINVAL, because we will bw requesting RENAME_EXCHANGE and RENAME_WHITEOUT