On Thu, 2008-03-13 at 00:07 +0000, Jamie Lokier wrote: > Dave Quigley wrote: > > > >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?... > > > > 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. > > People copy files from other systems using rsync, so it's not just > Linux uses of xattrs. Also, some programs can store their own data, > such as search metadata, desktop metadata, checksums, descriptions > (similar to MP3 id tags, but in xattrs) and all sorts of things. > > On Macs, xattrs are used to store the "resource fork", which contains > icons etc. so can be quite large. Of course that's not done on Linux. > People do sometimes try to copy those files to Linux and back, and it > generally fails because Linux refuses the large xattrs. > > -- Jamie Linux xattrs are nothing more than named extensions to struct stat. It's unfortunate that Solaris reused the xattr name for a completely different concept that already had existing names (named streams AKA forks), but they aren't equivalent and are not intended to be equivalent. Pretending that xattrs are named streams is just a path to madness and suffering, considering the Linux API is based around atomic attribute querying and modification instead of the standard Unix I/O primitives and the Powers That Be are vehemently against the implementation of named streams in the Linux VFS. -- Nicholas Miell <nmiell@xxxxxxxxxxx> -- 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
