Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available
David Howells <[email protected]>
| Newsgroups | gmane.comp.lib.glibc.alpha,gmane.linux.file-systems,gmane.linux.nfs,gmane.linux.kernel.cifs,gmane.network.samba.internals,gmane.comp.file-systems.ext4,gmane.comp.emulators.wine.devel,gmane.comp.kde.devel.kfm,gmane.comp.gnome.nautilus,gmane.linux.kernel.api |
|---|---|
| Message-ID | <[email protected]> |
Andreas Dilger <[email protected]> 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