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? OK, fair enough. I concede that is a use-case that would be easier if Linux had streams. But as Al just pointed out, this is a case of a poor design. There are other ways of solving this problem without introducing a feature that adds *known* security issues and causes headaches for people attempting to secure systems (scanners for "hidden" data areas etc.). The greatest users of streams in Windows are the virus-writing fraternity. Let's not add features for them please. But you also said: > There are, of course, other clients for file streams. Samba is one, > GNOME could use streams for various desktoppy things, and I'm certain > other users would come out of the woodwork if we had them. This is not a good justification (IMHO). You have one case where streams would make things easier. Samba might use them on Linux if there were there, but we'd always have to keep our non-Linux stream emulation code around and up to date for our other important system FreeBSD (I'm considering Solaris dead now, plus we never implemented Solaris native streams in all the time they were available, due to their limited availability on all other platforms). This is a case of adding a nasty feature that encourages bad security design "just because" it might be useful for user space that currently works fine without it. EA's work OK for Gnome. I doubt they want to store hundreds of megabytes of extra meta-data hidden inside a file, and on the off chance they do they also have to emulate this on non-Linux systems anyway (as does Samba). Apple gets away with requiring streams in MacOSX as they don't care about interop with anything other than themselves and Windows. We're not in that position. All pain, no gain IMHO :-).
