On Tue, May 02, 2006 at 05:10:09PM -0400, Maury Markowitz wrote:
> >Unfortunately, embedding the extended attributes in the znode_phys_t (as
> >you suggest) is not really practical. The extended attributes are
> >full-fledged files
>
> I think that's the disconnect. WHY are they "full-fledged files"?
Because that's what the specification calls for. If they weren't
full-fledged files, they wouldn't be compatable with existing
interfaces. That wouldn't necessarily be a bad thing, just a different
thing. As I mentioned, a new, lighter-weight interface could be
designed in addition to extended attributes.
> >windowing information with the directory entry. That change would be
> >fairly straightforward: use the ZAP to store a larger value in the
> >directory entry, adding words that describe the window information.
>
> I think I need a little hand holding here. Where is the ZAP in relation to
> the directory or file? I read the documentation to imply that the ZAP was
> the directory (page 46, bottom) effectively. However, looking at it now, I
> see there is no file name for instance.
>
> Reading over section 5, and I correct that a znode_phys_t is "built up
> inside" a ZAP (potentially micro), and the ZAP itself holds the
> znode_phys_t and other additional information? If this is correct, is there
> a diagram somewhere that illustrates the resulting overall structure?
Ah, I see that you've been reading the on-disk format document. Section
6.2 describes the relation between the ZAP, directory entries, and the
znode_phys_t:
Filesystem directories are implemented as ZAP objects. Each
directory holds a set of name-value pairs which contain the
names and object numbers for each director entry. Traversing
through a directory tree is as simple as looking up the value
for an entry and reading that object number.
All filesystem objects contain a znode_phys_t structure in the
bonus buffer of it's dnode. This structure stores the
attributes for the filesystem object.
To recap, the ZAP implements a directory, mapping from file name to
object number. That object number identifies (ie. refers to) a
particular dnode, which contains a znode_phys_t in the bonus buffer.
As I mentioned, the directory could potentially map from file name to
object number + some additional information, since the values stored in
the ZAP can be variable-length.
Could elaborate on what makes it seem like there "is no file name" and
that the "ZAP itself holds the znode_phys_t"? Then we can change that
documentation to make it clear that that is not the case.
--matt
_______________________________________________
zfs-discuss mailing list
[EMAIL PROTECTED]
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
