On Thu, 2015-04-30 at 15:11 +0200, Greg Kroah-Hartman wrote: > On Wed, Apr 29, 2015 at 04:09:45PM -0700, James Bottomley wrote: > > From: James Bottomley <JBottomley@xxxxxxxx> > > > > This is necessary to allow sysfs operations to return error in close (we are > > using close to initiate and return a possible error from a transaction). > > > > Signed-off-by: James Bottomley <JBottomley@xxxxxxxx> > > Are there any side-affects now that we have a flush() call for binary > files that the vfs will act differently from not defining one at all? See answer to Andy, but basically, no, VFS flush is only used to tidy up before close. To be honest, it might be nice if fsync *would* issue a transaction because I think having a multi-transaction API with write/fsync/write is not such a bad thing. It turns out that fsync and fdatasync do have a VFS op, but it's ->fsync() not ->flush(), so we have the option to wire this up if anyone finds a use case. > if not, no objection to me for this change. Thanks, James > thanks, > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-efi" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
