Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > During the statx session at LSF last week I asked if filesystems ought > to fill in fields that weren't asked for (btime, specifically) and the > impression I got was that it's ok to go ahead and fill out fields that > weren't asked for if we already have the data. Yes. The filesystem may return data that it wasn't asked for. > Since statx backends can do that, they'll have to check the structure > size, and not rely on "you asked for this field so we assume that you > allocated enough memory in userspace to hold it". Kind of. I'm assuming that the extension fields will be in struct kstat and can be set directly by the filesystem unconditionally, and the core can choose whether to copy them or not. However, assuming that one of the mask bits is reserved to indicate a buffer extension, this will be made available to the fs to let the fs know whether it's pointless to return it. However, at the moment I have no extensions to play with. Would it help you if I marked one of the mask bits reserved for this purpose? > Or we could just shift the precedent now -- programs only get the > information they ask for, and in asking for it we assume that we can > write to that part of the buffer. Frankly I'd prefer that behavior (see > the XFS statx patch), but I don't own the interface. :) That means a filesystem can't simply return non-basic data unconditionally if possible. I prefer letting it do so if it doesn't incur any extra I/O overheads. David -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
