Re: [rfc] Ignore Fsync Calls in Laptop_Mode

[D. Jansen]

On Mon, May 30, 2011 at 8:43 PM,  <Valdis.Kletnieks@xxxxxx> wrote:
> On Mon, 30 May 2011 20:28:24 +0200, "D. Jansen" said:
>
>> I'm not really sure I why shouldn't have that choice as a user. Just
>> because someone else could be running a mailserver on his system and
>> configure it in a way that it doesn't behave as it should?
>
> It cuts both ways. ÂIf a piece of software really wants to be sure that the
> fsync() semantics it's expecting are actually adhered to and refuses to run
> otherwise, how does it tell that you're lying to it?

Well if we allow to use a library to wrap fsync into write barriers
that doesn't seem to matter because software doesn't need to know what
happens and isn't even supposed to be able to work around it.

If this was to go into the kernel as an option, the situation was
different. But really, if you look at this discussion and the feedback
so far I don't think that's an option we need to discuss at this
point...
>
>> The big problem is that so far only fsync existed and lots of software
>> seemingly abuses it as an expensive write barrier. And it would really
>> be lovely to have the choice to stop that on an opt-in basis in laptop
>> mode.
>
> It's not "seemingly abuses it". ÂThat's the existing userspace API for
> inserting a barrier. ÂThe problem is that as defined, it will wait for the
> writeback to actually finish - which is actually as good as you can get without
> getting into the async I/O support. ÂIf there was a "insert barrier and return"
> API, how would it report back that the barrier had failed with EIO after it had
> already returned to userspace?

I guess with another call some time later, to check for the success of
the previous call?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/