From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C47143290AF; Mon, 25 May 2026 05:34:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779687260; cv=none; b=Dj1iVarRNm25XA/cJTL/hfA0gB1XSpioVCu11mLDJbtRZ66tHuyaQK50+ZH5/+Z2tZJUocmMTlq4arnIZNJ8mXwA06BLoGKo5v/BHOdhdgoDc51y8vFl+TnuSELshMo9ZrV58W4eyCPd68MmJxi7fKzVRuNb9IbRduvBnc1texs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779687260; c=relaxed/simple; bh=rlzfsikjcTeBvKH78vVn3QkG8ywL4adoIMr9+m2S2xY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=o/H4kGx9S0om17vs2DyOl1jl/Ct9YJ47LNwK41uBXsVR7nvxdtBebDuwi7EzIsuUwVQei1zQJuXWZyGm4uvuf1jDRpsrOlMCh/TRmaTOLuEntXFWNw3hGkt/eqHBamdlt5pwOENjGtq0iEAyu1obpJFRcU/IjltTTSflJ4e5JzM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=fbl7TUFK; arc=none smtp.client-ip=198.137.202.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="fbl7TUFK" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=JI2Zr6lMZzUwZhHfb31tRyecuT+FmnHjjuc47PlOF88=; b=fbl7TUFKkiazs7kdxhPNZcZYtr UoSs6GmpWA4sd06xY0mSmOJbz1vTEv0NX/in/duJG0tl7QLnFyjlGUNxwr7I0TWbZUC+A4s9djYdU 4bhcVb7ocFo2e1fhGL4xiWcqzMti7C4Mb0ixnz6UJM6Y63h5ng5Uz/dP1ozLEUkkx38vBNm6aa+7j gD9BXH6jklrKy4duOsz5t3vPHgHry/+IC9DIIZRqldDVethOXzNRpRy5XYaveSU4JU4HQR1uEqbdF 3FObmy1NIUnEwGbzE0qkkHl70qcM9kbu0TNXQ4He5AkG+OM4yrslhu738ntt5f7h43S58pFLVF2n2 bTmAfl+Q==; Received: from hch by bombadil.infradead.org with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1wRNxD-0000000GKaP-0cbs; Mon, 25 May 2026 05:34:19 +0000 Date: Sun, 24 May 2026 22:34:19 -0700 From: Christoph Hellwig To: Matthew Wilcox Cc: Theodore Tso , Christoph Hellwig , Jaegeuk Kim , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Akilesh Kailash , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org, Christian Brauner Subject: Re: [PATCH v2] f2fs: another way to set large folio by remembering inode number Message-ID: References: <20260409134538.3692605-1-jaegeuk@kernel.org> <20260521155748.GA79343@macsyma-wired.lan> Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html On Thu, May 21, 2026 at 06:42:03PM +0100, Matthew Wilcox wrote: > On Thu, May 21, 2026 at 11:57:48AM -0400, Theodore Tso wrote: > > So let me get this straight. This is a magic xattr interface which is > > not even persisted in the file system, but instead sets a 32-bit > > bitmask in the struct inode which disappears once the inode gets > > flushed from the inode stack. And it uses a generic xattr name, > > "user.fadvise". > > > > There's no way in *hell* any other file system is likely to adopt such > > a broken interface, so why didn't you just use an ioctl to set this > > magic f2fs-specific flag? > > I mean, yes, this API is horrendous. But it's just another example of > f2fs thinking it's somehow special and not just enabling large folios > like other filesystems do. This hurts everyone, not just people who use > f2fs. Yes. And assuming we'd have a legit use to unconditionally use smaller folios for given files we'd really need to control it in the MM. Even if it ends up being a Android-only hack.