Re: [rfc] Ignore Fsync Calls in Laptop_Mode

[Dave Chinner]

On Fri, May 20, 2011 at 08:01:17AM +0200, D. Jansen wrote:
> On Fri, May 20, 2011 at 5:39 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> > On Thu, May 19, 2011 at 03:34:46PM +0200, Dennis Jansen wrote:
> >> This is my first proper kernel code proposal so please bear with me!
> >>
> >> =Summary for busy kernel hackers=
> >> Problem: laptop_mode wants to keep applications from waking the hard
> >> disks but fsync calls can "sneak through". (IMHO this is a bug.)
> >>
> >> Proposed solution: Pretend the fsync was executed and successful.
> >> Insert two lines into the fsync and fdatasync calls in fs/sync.c:
> >> if (unlikely(laptop_mode))
> >>    return 0;
> >
> > No, no, no, no, no, no, no, no, no, no.
> >
> > There is _absolutely no justification_ for putting people's data at
> > risk like this.  If you want to do make fsync/fdatasync calls
> > no-ops, then go install libeatmydata on your systems. It's your
> > data, and you make the decision to risk it, not us.
> 
> 1. I thought I (may) make that decision by using laptop mode.

Laptop mode does not change fsync guarantees, so no, you ar enot
making a decision to throw data away when you select laptop mode.

> 2. libeatmydata would _always_ be active.

Your choice, really. Just use it as a preload for your apps that you
want to avoid fsync for.

> 3. A lib doesn't fix the ordering guarantee problem.

A properly implemented filesystem will not have ordering problems
just because fsyncs are not issued.

> 4. It's clear that it's not the right code. (And it is a rfc and my
> first one, too...)
> 
> Any suggestions?

Your problem to solve in userspace. Changing a generic, 
widely used kernel option like this is not allowed, and in general
when there are ways in userspace of playing fast and loose with
data, it's up to the user to do that in userspace, not the kernel...

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
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/