Re: what is our answer to ZFS?

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, Nov 22, 2005 at 04:55:08PM +0000, Anton Altaparmakov wrote:
> > That assumption is probably made because that's what POSIX and Single
> > Unix Specification define: "The st_ino and st_dev fields taken together
> > uniquely identify the file within the system."  Don't blame code that
> > follows standards for breaking.
> 
> The standards are insufficient however.  For example dealing with named 
> streams or extended attributes if exposed as "normal files" would 
> naturally have the same st_ino (given they are the same inode as the 
> normal file data) and st_dev fields.

Um, but that's why even Solaris's openat(2) proposal doesn't expose
streams or extended attributes as "normal files".  The answer is that
you can't just expose named streams or extended attributes as "normal
files" without screwing yourself.

Also, I haven't checked to see what Solaris does, but technically
their UFS implementation does actually use separate inodes for their
named streams, so stat(2) could return separate inode numbers for the
named streams.  (In fact, if you take a Solaris UFS filesystem with
extended attributs, and run it on a Solaris 8 fsck, the directory
containing named streams/extended attributes will show up in
lost+found.)

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/