On Thursday 13 March 2008 12:32:33 Dave Quigley wrote: > On Thu, 2008-03-13 at 11:06 +1300, Charles Manning wrote: > > I'm trying to figure out a reasonable approach to implementing xattr in > > YAFFS. > > > > >From my (limited) knowledge of xattr it seems that in theory you could > > > store a > > > > multi-Mbyte database in xattr, but in practice a smaller size is far more > > reasonable. Clearly storing/managing a small blob is going to be a lot > > simpler. > > > > What is the cut off of a reasonable xattr blob size? 1kbytes? 2kbytes?... > > > > Thanx. > > > > Charles > > > > > > -- > > 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 > > I just realized that I never really answered your question. I've yet to > see a reasonable SELinux context over 128 characters and Smack labels > should be shorter than that. I don't know what beagle places in xattrs > but I think that would be a good place to take a look for more practical > xattr sizes. > > Dave Is that 128 characters per xattr value or for the whole set of xattribs attached to a file? What I'm trying to figure out is a reasonable size for all the xattribs together. ie. If I store xattribs as a single blob containing all the name:value pairs, how big will that blob need to be? I should have perhaps given some extra context here. I'm trying to find the bang-for-bucks trade-off point for a simple implementation. YAFFS is a flash file system and is typically used in embedded systems (phones, routers, printers, point-of-sale,... etc). I guess limited use of SELinux is a reasonable benchmark for what is used here. Huge fs for corporate servers don't really fit in this picture so I guess vastly complex ACLs , while theoretically possible, don't really fall into the yaffs space. -- 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