Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp732033pxb; Wed, 15 Sep 2021 11:49:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyFDoXHXE2GQYMizElNSdH0Rj8Vn9G5qfxaI3btbCcWlG20Cbh4k3cNNj475lUVzlL85yVs X-Received: by 2002:a02:2b25:: with SMTP id h37mr1238616jaa.33.1631731772347; Wed, 15 Sep 2021 11:49:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631731772; cv=none; d=google.com; s=arc-20160816; b=W1J8DC+7c2021WI9fAh2CKlJdlOSefM4Clu8Yd5DH7183ZB//Cqcx0iI1aSt1FxR8Y D5k2xBP+DaOP/soBnQuUzloADEUGRzhqOpxJAItJcMzu9QaLBWkYV3JpUwBZXOFTTLl4 ZKHakJ9Zumln+Y37jhSp2uywcmjBep8qW/dh9Np97U06x8LQe1mrucjgJI9BSx3d5mDc PDEqSZSXYyqFR2OuDMcP9V4wx6P745HYnqi5wzMZSe7A251OD6dClgtXLVOjHmuXuMvV cNfsNR0sIn7xgYx8ASIixG/4cfSjZAYOWS183Ye42gafCWSbbUvfacqscbuNfigIN+de P0bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to; bh=GObnz4mflsanDPrXdTYJlgfai7Dv+1rnj4EcUBx1Sgo=; b=WODj9tmZ87Ubtv2fDFSmqJcdBUdim7f+ddF2z27/0jH6DVcIlG2zp5xEqeUY1h1+7y 3R9arGYERVo7U37Stq6TdeYtonxbpQcdv9VeTLqX3XBjInSKcljvUF2OdXS/9OlWxMlG wUWZSq2K8VfNTYtbJnzbs9YsdBRLEYqCZKnvZNzg7nmE6B2Mn/Te0pOdYHQHylx5yXnY dLsIiLEjtjlnDEmnz+lm7gPEZgqv4ROTDWTXV7LG7azkeJdAT7WJ4DlF/g6iJenZ3Bfg NzTO73bli0F7K4dVP4i9sCaGhksqloIhkMeZNHo7AsRuI+3uhd45qTliH1nmBZQv/MG7 lnkg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h30si731681ila.1.2021.09.15.11.49.16; Wed, 15 Sep 2021 11:49:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230480AbhIOSuM (ORCPT + 99 others); Wed, 15 Sep 2021 14:50:12 -0400 Received: from sandeen.net ([63.231.237.45]:37700 "EHLO sandeen.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231384AbhIOSuM (ORCPT ); Wed, 15 Sep 2021 14:50:12 -0400 Received: from liberator.local (h114.53.19.98.static.ip.windstream.net [98.19.53.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 99924877; Wed, 15 Sep 2021 13:48:39 -0500 (CDT) To: Dan Williams , Eric Sandeen Cc: linux-xfs , linux-ext4 , linux-fsdevel , Shiyang Ruan References: <1631726561-16358-1-git-send-email-sandeen@redhat.com> From: Eric Sandeen Subject: Re: [PATCH 0/3 RFC] Remove DAX experimental warnings Message-ID: Date: Wed, 15 Sep 2021 13:48:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On 9/15/21 1:35 PM, Dan Williams wrote: > On Wed, Sep 15, 2021 at 10:23 AM Eric Sandeen wrote: >> >> For six years now, when mounting xfs, ext4, or ext2 with dax, the drivers >> have logged "DAX enabled. Warning: EXPERIMENTAL, use at your own risk." >> >> IIRC, dchinner added this to the original XFS patchset, and Dan Williams >> followed suit for ext4 and ext2. >> >> After brief conversations with some ext4 and xfs developers and maintainers, >> it seems that it may be time to consider removing this warning. >> >> For XFS, we had been holding out for reflink+dax capability, but proposals >> which had seemed promising now appear to be indefinitely stalled, and >> I think we might want to consider that dax-without-reflink is no longer >> EXPERIMENTAL, while dax-with-reflink is simply an unimplemented future >> feature. > > I do regret my gap in engagement since the last review as I got > distracted by CXL, but I've recently gotten my act together and picked > up the review again to help get Ruan's patches over the goal line [1]. > I am currently awaiting Ruan's response to latest review feedback > (looks like a new posting this morning). During that review Christoph > identified some cleanups that would help Ruan's series, and those are > now merged upstream [2]. The last remaining stumbling block (further > block-device entanglements with dax-devices) I noted here [2]. The > proposal is to consider eliding device-mapper dax-reflink support for > now and proceed with just xfs-on-/dev/pmem until Mike, Jens, and > Christoph can chime in on the future of dax on block devices. > > As far as I can see we have line of sight to land xfs-dax-reflink > support for v5.16, does anyone see that differently at this point? Thanks for that update, Dan. I'm wondering, even if we have renewed hopes and dreams for dax+reflink, would it make sense to go ahead and declare dax without reflink non-experimental, and tag dax+reflink as a new "EXPERIMENTAL feature if and when it lands? -Eric