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...
