On Tue, 31 Jul 2007 15:29:01 -0700 Zach Brown <[EMAIL PROTECTED]> wrote:
> > For the large xattr case, it would actually point to an inode that > > would work just like a normal file. > > This makes me nervous, maybe we should talk about this point in more > detail. I don't like the idea of bringing all the per-file posix api > nonsense in the inode (i_uid, i_mode, etc) just so that xattrs can > store data. Well, its a trade off between ~100 bytes of inode for a large xattr, along with (hopefully) lots of code reuse vs something more specialized. > > I guess I'm hoping for structures with a finer granularity than that. > > I care because of the unfun time I had with fsck.ocfs2. It has to > jump through hoops to figure out when certain fields in an inode > could be ignored or not based on what that internal > "inode" (sometimes only a few fields!) was really being used for. The directory item will be able to store almost a full block worth (minus 200 bytes or so of header, the other goo and the xattr name). So, the large ones are a corner case that will be rarely used. I'd like them to be as simple as possible. Every xattr inode would have a flag set that says I'm an xattr inode!, and it shouldn't be all that hard on fsck. -chris _______________________________________________ Btrfs-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/btrfs-devel
