Thread (65 messages) read the whole thread 65 messages, 14 authors, 2015-08-04

Re: [PATCH 1/1] suspend: delete sys_sync()

From: Rafael J. Wysocki <hidden>
Date: 2015-07-08 21:36:45
Also in: lkml

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:
quoted
On Tuesday, July 07, 2015 04:38:26 PM Oliver Neukum wrote:
 
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help