On Wednesday, July 08, 2015 09:51:13 AM Oliver Neukum wrote: > On Wed, 2015-07-08 at 00:11 +0200, Rafael J. Wysocki wrote: > > On Tuesday, July 07, 2015 04:38:26 PM Oliver Neukum wrote: > > > > > That is a tough nut. But that's not a reason to make it worse. > > > I'd say there's no reason not to use a secondary interface to > > > suspend without syncing or to extend or introduce such an interface > > > if the API is deficient. > > > > Well, the point here is that the sync we have doesn't prevent all > > potentially > > possible bad things from happening. It's a partial measure at best in that > > respect. > > Well, removed hardware doesn't work. That is a very basic limitation. > But can we guarantee that any returned syscall actually wrote to disk? > Yes, but it must be done in kernel space. So doing a sync has a true > benefit. > I don't see why you would want to generally remove it. What is wrong > with an interface allowing a selection there to those who don't care > about additional guarantees?
Nothing and I'm not discussing that (I've said that already at least once in this thread). What I'm questioning is the "why" of calling sys_sync() from the kernel. If we had a good answer to why we do that to start with, the whole discussion wouldn't be necessary. So the answer I'm getting from this thread so far is something like "It is a safety measure to prevent users from losing data if they pull removable storage out of the system while suspended". Your point about the returned syscall guaranees is a good one, but still. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
