From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f178.google.com ([209.85.223.178]:33280 "EHLO mail-io0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727293AbeH2WvG (ORCPT ); Wed, 29 Aug 2018 18:51:06 -0400 Received: by mail-io0-f178.google.com with SMTP id r196-v6so5415072iod.0 for ; Wed, 29 Aug 2018 11:52:53 -0700 (PDT) From: Andreas Dilger Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E9190CAB-F3B7-48F9-A777-72AB9E1C28FD"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Streams support in Linux Date: Wed, 29 Aug 2018 12:52:47 -0600 In-Reply-To: <20180829155922.GA114671@jra3> Cc: Tom Talpey , Steve French , Theodore Tso , Matthew Wilcox , "ebiggers@kernel.org" , Al Viro , linux-fsdevel To: Jeremy Allison References: <20180825180026.GR6515@ZenIV.linux.org.uk> <20180825205716.GA2664@bombadil.infradead.org> <20180825223615.GS6515@ZenIV.linux.org.uk> <20180827170531.GC217636@jra3> <20180827182143.GB24544@bombadil.infradead.org> <20180828004523.GB2304@thunk.org> <20180828181245.GE41380@jra3> <20180829155922.GA114671@jra3> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --Apple-Mail=_E9190CAB-F3B7-48F9-A777-72AB9E1C28FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 29, 2018, at 9:59 AM, Jeremy Allison wrote: >=20 > On Wed, Aug 29, 2018 at 01:46:30PM +0000, Tom Talpey wrote: >>>=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. >>=20 >> Wait, you're saying that Macs and Windows clients need to start = issuing these new magical ioctl's to Samba/Linux servers? Not a = solution, IMO. >=20 > Nope, that's not an option obviously. The ioctls only exist > on the Linux userspace client side. Inside cifsfs they get > converted to standard SMB1/2/3 calls. >=20 > I'm trying to create a way for Linux userspace to get > access to these Windows/Mac/Samba features without having > to completely change the VFS model to introduce the > horrible Solaris semantics of opening a file as a > directory to get access to internal streams. Note that ext4 recently added support for xattrs larger than the previous one-block (usually 4KB) total size. The large xattrs were implemented as a separate inode attached to the file/directory to reference the multiple data blocks allocated to the xattr, which simplifies e2fsck and ext4 block allocation/freeing/traversal. There is no real limit on the size of such xattr inodes, except as currently imposed by the xattr userspace APIs. If there was an API (e.g. openat() or an ioctl() to start) that allowed opening the named xattrs, normal read/write should be useable to modify them. I don't think I'd go as far as Matthew to allow link, rename, etc. of these attributes, as that introduces unnecessary complexity for no clear use case or benefit. That doesn't preclude future usage in this manner, but I don't think it makes sense to add that until there is a clear use for this. For the original FS Verity case, using xattrs attached to the inode is IMHO far preferable to using a separate hidden directory and/or special file to store the verity information, as it will properly follow the lifetime of the original file. Rename will keep the verity data, and unlink will delete the verity data, without the need for fsck to keep them consistent or do garbage collection. Cheers, Andreas --Apple-Mail=_E9190CAB-F3B7-48F9-A777-72AB9E1C28FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAluG638ACgkQcqXauRfM H+CFJxAAqrzBbNcvIcY0WvCRZWCL4OAWKC2I/h002imnmdiF7N1ycRYxOfcFw9Xl 3rxKvQvAJQfQgRLL1BIlQuSjSIVfo9wpO1z3JZHAu6ciVNXGwU31s+GRcxM1MVvu V11e0k/QS1a04pDF9ikvcKDVDKHpvGXWc4dAg0I6oYlI+yj8WmCjfsVWy/GXZjki oKbdBsUqM+QoGhrgo2Z1RnJlb+6TIIlvyg9GQ3YO68SdxS8yidEMCg/nUzckeiNA NBd/PxlD/BvKXhbbG/qNmBY1ATwQPp24iv19piDeuVahIB1jyeZjconj1iQt7D3u VA98oZkXBu/2XJQsnCq2+52ntt+qEBYPebMzgi5K5e8YUjYiKqXfiRmASHSCbwgP xvWSOESLz1MHGHMaL9yKOFZySUwM+JW+N69JQKLi6DM91iqTDDTWVzdWB288G/UK 94zK+ptry3soukmgx0myfsoRRHNQe700i8hoh05avnC5ipRb8dH/VYNN2Wzt5mwt sZAGzZp/7+BqwL+d80X+mBQxDWkmIYA5f/r8idUy6/USvSpi5wPMRfaPxxsd4PxS h7B8oDH2GjM1jnBB82VThYbxZQZC4PeqNX5uQd5SNXaYiBMjySEC/5A9K00ebFi8 QEFAGF1FH8jSNve/MPyE/f/nPRfLoL+WqEs6VMcZ1nx9Mf9W6bs= =UB6U -----END PGP SIGNATURE----- --Apple-Mail=_E9190CAB-F3B7-48F9-A777-72AB9E1C28FD--