From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:32996 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726971AbeH0Wcz (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Mon, 27 Aug 2018 18:32:55 -0400
Date: Mon, 27 Aug 2018 19:45:00 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Matthew Wilcox <willy@infradead.org>
Cc: Jeremy Allison <jra@samba.org>, Steve French <smfrench@gmail.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        ebiggers@kernel.org,
        samba-technical <samba-technical@lists.samba.org>
Subject: Re: Streams support in Linux
Message-ID: <20180827184459.GC6515@ZenIV.linux.org.uk>
References: <20180825135107.GA12251@bombadil.infradead.org>
 <20180825144745.GQ6515@ZenIV.linux.org.uk>
 <20180825155150.GA3581@bombadil.infradead.org>
 <20180825180026.GR6515@ZenIV.linux.org.uk>
 <20180825205716.GA2664@bombadil.infradead.org>
 <20180825223615.GS6515@ZenIV.linux.org.uk>
 <CAH2r5mvFQbcUo+dWOMv1POFAgF+s52t_qm2XBdPFCLVKnpRdEw@mail.gmail.com>
 <20180827170531.GC217636@jra3>
 <20180827182143.GB24544@bombadil.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180827182143.GB24544@bombadil.infradead.org>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Mon, Aug 27, 2018 at 11:21:43AM -0700, Matthew Wilcox wrote:
> On Mon, Aug 27, 2018 at 10:05:31AM -0700, Jeremy Allison wrote:
> > I can't think of a *single* case where a stream adds more
> > utility than an EA used in the same case.
> > 
> > I don't want theoretical "well it would be nice if..",
> > I want clear "we couldn't have done it any other way"
> > kinds of things.
> 
> I started this thread with such an example.  The fs-verity patch proposed
> wants to store hundreds of megabytes of data associated with a particular
> file.  The current solution is to append it to the end of the data then
> magic to set i_size lower but not remove the data from the file like a
> truncate would.  Then more magic to read that data.
> 
> It can't be stored in an xattr; xattrs are limited to 64k in size.
> And you have to read them / write them all-in-one-go; you can't read
> a little bit of them.  How would you solve the fs-verity problem with
> less magic?

* create a subdirectory in root called e.g. .turdis
* prohibit lookups of that after mount has done the initial one and got a dentry
for it
* kernel-side, do O_TEMPFILE open, crap into it and link it in /.turdis/pile#42
* put that 42 into xattrs of the file that has served as, er, nutrient source.

No fs structure changes needed...