From owner-freebsd-fs@freebsd.org Wed Mar 6 21:49:02 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36FB51528B54 for ; Wed, 6 Mar 2019 21:49:02 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 92B167277F for ; Wed, 6 Mar 2019 21:49:01 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 531C81528B52; Wed, 6 Mar 2019 21:49:01 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B9A21528B51 for ; Wed, 6 Mar 2019 21:49:01 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f174.google.com (mail-it1-f174.google.com [209.85.166.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B03A272774; Wed, 6 Mar 2019 21:48:57 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f174.google.com with SMTP id z131so12023075itf.5; Wed, 06 Mar 2019 13:48:57 -0800 (PST) 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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=cP1E0h/PXcIA92G8kvw/AB34PxT7HNTWFUBWEWGsZ/o=; b=P8cnn/bXKEJR73WlrppMgG7/J+Jp9bCTmwXXvP5+rQ09kALyeIj0KmSwwJpPoDqOZN 7Nkonu8yT3G5EWWE6v0RRtReGqsHt5SIju9jy9KDEbvf2jMAs610nJ+PtSDecQuTz7EW d3lTMvsvk6PboU2aztfn4VbOsL/3c3OwVirHvSyCdNVCTm5at3j93X0GVNIY+g2Y4i1j xOhS4mU+ekmHPFK93iUxDk+SWj095n5zqXueVWQ4A8/3gOeeKlNRmhEAUSkhKu+GG67X yyDVPtoQWHuSTy2PTVejor17CGn6cftmSZoN3s7YCk7MVdBQfUqPQ9pjyzCumWnZHq/E pCMw== X-Gm-Message-State: APjAAAVE7UAe1hrQyctONtdLGlZml8dJdlUxb+BhpWY1lUmyqj4cUqUd KS9ekVmKVGkqU91UKL3wxHC6wLQO X-Google-Smtp-Source: APXvYqyHyDIji4Q6QEdDDKjf8qEINd9H19GLx+zywSu7LzX2Ll/2f7L6bRiWv4UoAH8kv9f3Frcdiw== X-Received: by 2002:a24:f6c6:: with SMTP id u189mr3276086ith.6.1551908931276; Wed, 06 Mar 2019 13:48:51 -0800 (PST) Received: from mail-it1-f172.google.com (mail-it1-f172.google.com. [209.85.166.172]) by smtp.gmail.com with ESMTPSA id r15sm947657ioc.75.2019.03.06.13.48.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 13:48:50 -0800 (PST) Received: by mail-it1-f172.google.com with SMTP id z124so12601367itc.2; Wed, 06 Mar 2019 13:48:50 -0800 (PST) X-Received: by 2002:a24:bdcc:: with SMTP id x195mr3433026ite.149.1551908930748; Wed, 06 Mar 2019 13:48:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Wed, 6 Mar 2019 13:48:39 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [Bug 235774] [FUSE]: Need to evict invalidated cache contents on fuse_write_directbackend() To: Rick Macklem Cc: "bugzilla-noreply@freebsd.org" , "fs@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B03A272774 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 21:49:02 -0000 Hi Rick, On Wed, Mar 6, 2019 at 1:32 PM Rick Macklem wrote: > > --- Comment #4 from Conrad Meyer --- > >I think fuse's IO_DIRECT path is a mess. Really all IO should go throug= h the > >buffer cache, and B_DIRECT and ~B_CACHE are just flags that control the > >buffer's lifetime once the operation is complete. Removing the "direct" > >backends entirely (except as implementation details of strategy()) would > >simplify and correct the caching logic. > > Hmm, I'm not sure that I agree that all I/O should go through the buffer = cache, > in general. (I won't admit to knowing the fuse code well enough to commen= t > specifically on it.) The scope of the bug and comment you've replied to is just FUSE IO. > =E2=80=A6 having the NFS (or FUSE) client do a > large amount of writing to a file can flood the buffer cache and avoiding= this > for the case where the client won't be reading the file would be nice. > What I am not sure is whether O_DIRECT is a good indicator of "doing a lo= t of > writing that won't be read back". This is the known failure mode of LRU cache policies plus finite cache size plus naive clients. It's not specific to any particular filesystem. You can either enlarge your LRU cache to incorporate the entire working set size, incorporate frequency of access in eviction policy, or have smart clients provide hints (e.g., POSIX_FADV_DONTNEED). O_DIRECT -> IO_DIRECT -> B_DIRECT is already used as a hint in the bufcache to release bufs/pages aggressively. Best, Conrad