Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752862AbZC2EyS (ORCPT ); Sun, 29 Mar 2009 00:54:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751255AbZC2EyB (ORCPT ); Sun, 29 Mar 2009 00:54:01 -0400 Received: from srv5.dvmed.net ([207.36.208.214]:36212 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751237AbZC2EyA (ORCPT ); Sun, 29 Mar 2009 00:54:00 -0400 Message-ID: <49CEFECE.8020008@garzik.org> Date: Sun, 29 Mar 2009 00:53:34 -0400 From: Jeff Garzik User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Theodore Tso , Matthew Garrett , Alan Cox CC: david@lang.hm, Linus Torvalds , Andrew Morton , David Rees , Jesper Krogh , Linux Kernel Mailing List Subject: Re: Linux 2.6.29 References: <20090327170208.GA27646@srcf.ucam.org> <49CD2C47.4040300@garzik.org> <49CD4DDF.3000001@garzik.org> <49CD7B10.7010601@garzik.org> <49CECDEB.7040704@garzik.org> <20090329034346.GA10984@mit.edu> In-Reply-To: <20090329034346.GA10984@mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Report: SpamAssassin version 3.2.5 on srv5.dvmed.net summary: Content analysis details: (-4.4 points, 5.0 required) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1146 Lines: 27 Theodore Tso wrote: > So having some mode where we can suspend all writes to the disk for up > to a user-defined limit --- and then once the disk wakes up, for > reading or for writing, we flush out all dirty data --- makes a lot of > sense. Laptop mode does most of this already, except that it doesn't > intercept fsync() requests. And as long as the user has given > permission to the operating system to defer fsync() requests by up to > some user-specified time limit, IMHO that's completely fair game. Overall I agree, but I would rewrite that as: it's fair game as long as the OS doesn't undercut the deliberate write ordering performed by the userland application. When the "laptop mode fsync plug" is uncorked, writes should not be merged across an fsync(2) barrier; otherwise it becomes impossible to build transactional databases with any consistency guarantees at all. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/