On 2015-04-30 at 19:56 +0300 Boaz Harrosh sent off: > Solvable use the infamous ....xxxx~1 encoding solution for the dirs I mentioned already, that this is not a good solution in any way. Apart from the fact that those file names would then not be allowed for clients to be created it decouples the meta-data from the files and that asks for obvious interoperability troubles. No need to discuss any external data storage here, really. > > Apart from the > > fact that the meta data is detached from the file, which also makes this > > workaround quite sub-optimal. Still the only real solution I see would be > > bigger EA sizes. I was hoping that this would be not a big challenge for the > > Linux kernel. > > > > Again you are ignoring my point. If the FS would like to (easily) keep these > xattrs for you, you have a POSIX API problem. You will need an alternate API > to be able to read/write these big xattrs in chunks. > > It might be possible to make that 64K say 2M but you need a CONST-MAX size. > with current API, is there a number that will satisfy you? the most prominent consumer of those data are OS X clients. 64MB might be a good number for most clients, even those that make quite heavy use of EAs. It would be a start if the hard coded kernel EA size limit would vanish. If that is done, we might start looking at extending the current xattr API as needed or maybe even think of coming up with an alternativ API to access EAs. Björn -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen ☎ +49-551-370000-0, ℻ +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
