On Wed, May 03, 2006 at 03:22:53PM -0400, Maury Markowitz wrote: > >> I think that's the disconnect. WHY are they "full-fledged files"? > > > >Because that's what the specification calls for. > > Right, but that's my concern. To me this sounds like "historically > circular" reasoning... > 20xx) we need a new file system that supports xaddrs > well xaddrs are this second file, so... > To me it appears that there is some confusion between the purpose and > implementation.
> Certainly if xaddrs were originally introduced to store, well, "x" > addrs, then the implementation is a poor one. Years later the > _implementation_ was copied, even though it was never a good one. I think you are confusing the interface with the implementation. ZFS has "copied" (aka. adhered to) a pre-existing interface[*]. Our implementation of that interface is in some ways similar to other implementations. I believe that our implementation is a very good one, but if you have specific suggestions for how it could be improved, we'd love to hear them. [*] The solaris extended attributes interface is actually more accurately called "named streams", and has been used as the back-end for CIFS (Windows) and NFSv4 named-streams protocols. See the fsattr(5) manpage. We appreciate your suggestion that we implement a higher-performance method for storing additional metadata associated with files. This will most likely not be possible within the extended attribute interface, and will require that we design (and applications use) a new interface. Having specific examples of how that interface would be used will help us to design a useful feature. > The real problem is that there is nothing like a "general overview" of > the zfs system as a whole I agree that a higher-level overview would be useful. > COMPARING the system with the widely understood UFS would be > invaluable, IMHO. Agreed, thanks for the suggestion. Unfortunately, ZFS and UFS are sufficiently different that I think the comparison would only be useful for a very limited part of ZFS, say from the file/directory down. > But to the specifics. You asked why I thought it was that the file > name did not appear. Well, that's because the term "file name" (or > "filename") does not appear anywhere in the document. Thanks, maybe we should use that keyword in section 6.2 to help when doing a search. > So then, at a first glance it seems that one would expect to find the > directory description in Chapter 6, which has a subsection called > "Directories and Directory Traversal". I believe that that section does in fact describe directories. Perhaps the description could be made more explicit (eg. "The ZAP object which stores the directory maps from filename to object number. Each entry in the ZAP is a single directory entry. The entry's name is the filename, and its value is the object number which identifies that file. > That section describes the znode_phys_t structure. You're right, it also describes the znode_phys_t. There should be a section break after the first paragraph, before we start talking about the znode_phys_t. > Maybe I'm going down a dark alley here, but is there any reason this > split still exists under zfs? IE, I asumed that the znode_phys_t would > be located in the directory ZAP, because to my mind, that's where > metadata belongs. ZFS must support POSIX semantics, part of which is hard links. Hard links allow you to create multiple names (directory entries) for the same file. Therefore, all UNIX filesystems have chosen to store the file information separately for the directory entries (otherwise, you'd have multiple copies, and need pointers between all of them so you could update them all -- yuck). Hard links suck for FS designers because they constrain our implementation in this way. We'd love to have the flexability to easily store metadata with the directory entry. We've actually contemplated caching the metadata needed to do a stat(2) in the directory entry, to improve performance of directory traversals like find(1). Perhaps we'll be able to add this performance improvement in an future release. --matt _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
