Andreas Dilger <adilger@xxxxxxxxx> wrote: > > The idea was initially proposed as a set of xattrs that could be > > retrieved with getxattr(), but the general preferance proved to be > > for new syscalls with an extended stat structure. > > I would comment that it was the opposite. It was originally a > stat()-like extension that degraded into a messy getxattr() mess. Ummm... No, my first attempt was definitely through getxattr(). You even commented on it. > > The fields in struct xstat come in a number of classes: > > > > (0) st_dev, st_blksize, st_information. > > > > These are local data and are always available. > > For the extra two bits it would cost us, I don't think st_blksize > and st_information should always be returned. Fair enough. > st_blksize may be variable for a distributed filesystem, I wonder if there's a way to make this explicit - or is it something that if the bit isn't set, you can't use the value in st_blksize. I wonder if this value always has to be non-zero to make sure existing stat() doesn't explode. > and some of the fields in st_information (offline) may not be free to access > either. True. David -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
