From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-sn1nam01on0123.outbound.protection.outlook.com ([104.47.32.123]:4288
        "EHLO NAM01-SN1-obe.outbound.protection.outlook.com"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S1727595AbeH2Rng (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
        Wed, 29 Aug 2018 13:43:36 -0400
From: Tom Talpey <ttalpey@microsoft.com>
To: Jeremy Allison <jra@samba.org>, Steve French <smfrench@gmail.com>
CC: Theodore Tso <tytso@mit.edu>, Matthew Wilcox <willy@infradead.org>,
        "ebiggers@kernel.org" <ebiggers@kernel.org>,
        Al Viro <viro@zeniv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: RE: Streams support in Linux
Date: Wed, 29 Aug 2018 13:46:30 +0000
Message-ID: <BL0PR2101MB0993C4E61D3F7E8B6AB785CFA0090@BL0PR2101MB0993.namprd21.prod.outlook.com>
References: <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>
 <20180828004523.GB2304@thunk.org>
 <CAH2r5mtW53bxuTU9K0NODboy39G_8xqL5XqFHhaxjgU2E2jfEQ@mail.gmail.com>
 <20180828181245.GE41380@jra3>
In-Reply-To: <20180828181245.GE41380@jra3>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

> -----Original Message-----
> From: samba-technical <samba-technical-bounces@lists.samba.org> On Behalf
> Of Jeremy Allison via samba-technical
> Sent: Tuesday, August 28, 2018 2:13 PM
> To: Steve French <smfrench@gmail.com>
> Cc: Theodore Tso <tytso@mit.edu>; samba-technical <samba-
> technical@lists.samba.org>; Matthew Wilcox <willy@infradead.org>;
> ebiggers@kernel.org; Al Viro <viro@zeniv.linux.org.uk>; linux-fsdevel <li=
nux-
> fsdevel@vger.kernel.org>
> Subject: Re: Streams support in Linux
>=20
> On Mon, Aug 27, 2018 at 08:07:35PM -0500, Steve French wrote:
> > On Mon, Aug 27, 2018 at 7:45 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> > >
> > > 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 pr=
oposed
> > > > wants to store hundreds of megabytes of data associated with a part=
icular
> > > > 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 lik=
e a
> > > > truncate would.  Then more magic to read that data.
> > >
> > > Sure, but so what?  The Merkle Tree only needs to be read by the
> > > kernel, and we only need to install the fs-verity data once.  And
> > > putting it at the end of the file works just fine.  Theoretically we
> > > could do it other ways, but this is almost certainly easier and
> > > cleaner than if we had to open a streams file from kernel code.
> > >
> > > Doing it using streams would actually be *harder* and is only of use
> > > for people who like more structured designs.  But to be clear, this i=
s
> > > *not* something I'm asking for as one of the original designers of
> > > fs-verity.
> >
> > Given that streams need to be read to backup Macs and Windows
> > (and for a few features of these servers mentioned earlier)
> > and would be exposed in ntfs (and SMB3 remotely) locally on Linux,
> > seems useful to me to have some consistent way to open and read
> > them on Linux even if we don't want to generalize it to other local fs.
> > The protocol supports it fine (just a file with a reserved character
> > ':' in it) but a little tricky to avoid name conflict with posix ':'
> > in filenames
>=20
> This sounds like a case for a couple of ioctls. One to enumerate
> the streams on an open fd, one to open a given stream name on an
> open fd.

Wait, you're saying that Macs and Windows clients need to start issuing the=
se new magical ioctl's to Samba/Linux servers? Not a solution, IMO.

Tom.