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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3569DC433EF for ; Thu, 16 Jun 2022 13:17:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376631AbiFPNRr (ORCPT ); Thu, 16 Jun 2022 09:17:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52464 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242604AbiFPNRp (ORCPT ); Thu, 16 Jun 2022 09:17:45 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CB500255BD for ; Thu, 16 Jun 2022 06:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655385463; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=i5RADxigDcqh0YvPeRXWIXmEeyc1rLKtSi/HgTqXy+8=; b=iHdYKAiu/fLf69USyVajgWjOhADN5LPPR0sdkPC7Ph6GITIz3JB6Lpy9cC0SxhE9zKs+Xs lLfkSA2Ah/2dFBwnx4MXZz4oYe+dD0HzfDPM1fsADRo5PKC4sE+urJJ86nxP7dYWFtFIO4 uBYRkwVxrKvW5yyfxKa+s/U5syQtyjA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-56-Vaa9Q1p_O2qKExQL9JnB_Q-1; Thu, 16 Jun 2022 09:17:40 -0400 X-MC-Unique: Vaa9Q1p_O2qKExQL9JnB_Q-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 06ABA811E76; Thu, 16 Jun 2022 13:17:40 +0000 (UTC) Received: from horse.redhat.com (unknown [10.18.25.210]) by smtp.corp.redhat.com (Postfix) with ESMTP id ED6B02026985; Thu, 16 Jun 2022 13:17:39 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id A8F0E2209F9; Thu, 16 Jun 2022 09:17:39 -0400 (EDT) Date: Thu, 16 Jun 2022 09:17:39 -0400 From: Vivek Goyal To: Miklos Szeredi Cc: Bernd Schubert , Dharmendra Singh , linux-fsdevel@vger.kernel.org, fuse-devel , linux-kernel@vger.kernel.org, Dharmendra Singh Subject: Re: [PATCH v4 1/1] Allow non-extending parallel direct writes on the same file. Message-ID: References: <20220605072201.9237-1-dharamhans87@gmail.com> <20220605072201.9237-2-dharamhans87@gmail.com> <34dd96b3-e253-de4e-d5d3-a49bc1990e6f@ddn.com> <3d189ccc-437e-d9c0-e9f1-b4e0d2012e3c@ddn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Jun 16, 2022 at 11:01:59AM +0200, Miklos Szeredi wrote: > On Thu, 9 Jun 2022 at 15:53, Vivek Goyal wrote: > > > Right. If user space is relying on kernel lock for thread synchronization, > > it can not enable parallel writes. > > > > But if it is not relying on this, it should be able to enable parallel > > writes. Just keep in mind that ->i_size check is not sufficient to > > guarantee that you will not get "two extnding parallel writes". If > > another client on a different machine truncated the file, it is > > possible this client has old cached ->i_size and it will can > > get multiple file extending parallel writes. > > There are two cases: > > 1. the filesystem can be changed only through a single fuse instance > > 2. the filesystem can be changed externally. > > In case 1 the fuse client must ensure that data is updated > consistently (as defined by e.g. POSIX). This is what I'm mostly > worried about. > > Case 2 is much more difficult in the general case, and network > filesystems often have a relaxed consistency model. > > > > So if fuse daemon enables parallel extending writes, it should be > > prepared to deal with multiple extending parallel writes. > > > > And if this is correct assumption, I am wondering why to even try > > to do ->i_size check and try to avoid parallel extending writes > > in fuse kernel. May be there is something I am not aware of. And > > that's why I am just raising questions. > > We can probably do that, but it needs careful review of where i_size > is changed and where i_size is used so we can never get into an > inconsistent state. Ok. Agreed that non-extending parallel writes are safer option. Atleast for the case 1) above. For case 2) we can get multiple parallel extending writes with these patches if another client on another machine truncates file. So I don't have any objections to these patches. I just wanted to understand it better. Thanks Vivek