Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761545AbZDFWEe (ORCPT ); Mon, 6 Apr 2009 18:04:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759387AbZDFWEX (ORCPT ); Mon, 6 Apr 2009 18:04:23 -0400 Received: from yw-out-2324.google.com ([74.125.46.28]:42094 "EHLO yw-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753619AbZDFWEW convert rfc822-to-8bit (ORCPT ); Mon, 6 Apr 2009 18:04:22 -0400 MIME-Version: 1.0 In-Reply-To: <003001c9b6ff$a9259ce0$fb70d6a0$@com> References: <1239022088-29002-1-git-send-email-jens.axboe@oracle.com> <20090406151054.GD5178@kernel.dk> <20090406183157.GD7376@mit.edu> <002501c9b6f3$f85b4910$e911db30$@com> <20090406211931.GB8586@mit.edu> <003001c9b6ff$a9259ce0$fb70d6a0$@com> Date: Mon, 6 Apr 2009 15:04:05 -0700 Message-ID: <2c0942db0904061504l6504934bi446f7425fcd38470@mail.gmail.com> Subject: Re: [PATCH 0/8][RFC] IO latency/throughput fixes From: Ray Lee To: Hua Zhong Cc: Theodore Tso , Linus Torvalds , Jens Axboe , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1932 Lines: 38 On Mon, Apr 6, 2009 at 2:35 PM, Hua Zhong wrote: >> I've added workarounds for 2.6.30 that provide the replace-via-rename >> and replace-via-truncate workarounds for ext3 data=writeback cases. >> See commits e7c8f507 and f7ab34ea. >> >> There won't be an implied fsync for newly created files, yes, but you >> could have crashed 5 seconds earlier, at which point you would have >> lost the newly created file anyway.  Replace-via-rename and >> replace-via-truncate solves the problem for applications which are >> editing pre-existing files, which was most of people's complaints >> about depending on data=ordered semantics. > > I am not talking about "most" people's complaints. There are use cases for > ext3 far beyond the desktop. > > I worked on a user-space library on top of ext3 before on embedded systems. > It may not have been the case for me but I could well imagine where it could > get too clever and depend upon "ordered". Speaking as another embedded Linux guy, I don't update kernels on my embedded platforms willy-nilly, nor do I design a library that relies upon some default behavior without specifying it explicitly. That's just one of the prices of doing embedded development. Your argument seems to be that someone may be relying upon default kernel behavior and, at the same time, is willing to continually upgrade their kernel. I'd argue that person is, y'know, nuts. If they're willing to upgrade their kernel on something that has that stringent of requirements, then they should be willing to force a mount option at the same time. If they're willing to upgrade their kernel blindly, then they shouldn't be doing embedded development. -- 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/