Oleg Drokin wrote: > I have separated stat fields into arbitrary categories based on my idea of how this needs to be done, > that could of course be refined in other ways if desired. Type should get its own category - which is finer grained than mode. Type (dir, file, link, etc.) is sometimes a lot cheaper than the other attributes to get, because on some filesystems you don't need to read the inode to get the type. See readdir() and d_type. atime should get its own category, because on at least one filesystem - Tux3 - atime is kept in a separate part of the storage. Not reading the atime if you don't care about it would be good. Most programs don't look at atime. Separate categories for mtime and ctime make sense, although I don't know of an implementation where it would make a performance difference at present. Once you have fine-grained selection of stat fields - it's natural to ask why not allow _additional_ stat fields in an future-extensible fashion? A few things would be handy sometimes, such as inode generation number, modification generation number (to detect changes across reboots), and extra flags indicating COW or other properties. If an "extensible" attribute is not asked for, the kernel must not fill in that field of the structure as the app may be not have allocated space for it. Or it must use a tag-length-value sort of structure for the result, similar to network CMSGs. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
