Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754508AbYFTJAy (ORCPT ); Fri, 20 Jun 2008 05:00:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751656AbYFTJAn (ORCPT ); Fri, 20 Jun 2008 05:00:43 -0400 Received: from www.church-of-our-saviour.org ([69.25.196.31]:41267 "EHLO thunker.thunk.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751292AbYFTJAm (ORCPT ); Fri, 20 Jun 2008 05:00:42 -0400 Date: Fri, 20 Jun 2008 04:59:22 -0400 From: Theodore Tso To: Holger Kiehl Cc: Eric Sandeen , "Aneesh Kumar K.V" , Jan Kara , Solofo.Ramangalahy@bull.net, Nick Dokos , linux-ext4@vger.kernel.org, linux-kernel Subject: Re: Performance of ext4 Message-ID: <20080620085922.GH9119@mit.edu> Mail-Followup-To: Theodore Tso , Holger Kiehl , Eric Sandeen , "Aneesh Kumar K.V" , Jan Kara , Solofo.Ramangalahy@bull.net, Nick Dokos , linux-ext4@vger.kernel.org, linux-kernel References: <20080612180605.GD22481@skywalker> <20080616175408.GF3279@atrey.karlin.mff.cuni.cz> <20080616181353.GA20686@skywalker> <20080619155645.GA8582@mit.edu> <485A8C2D.1090806@redhat.com> <20080619174211.GB9119@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1334 Lines: 31 On Fri, Jun 20, 2008 at 08:32:52AM +0000, Holger Kiehl wrote: >> It sounds like i_size is actually dropping in >> size at some pointer long after the file was written. If I had to sorry, "at some point"... >> guess the value in the inode cache is correct; and perhaps so is the >> value on the journal. But somehow, the wrong value is getting written >> to disk Or, "the right value is never getting written to disk". (Which as I think about it is more likely; it's likely that an update to i_size is getting *lost*, perhaps because the delalloc code is possibly modifying i_size without starting a transaction first. Again this is just a guess.) > What I find strange is that the missing parts of the file are not for > example exactly 512 or 1024 or 4096 bytes it is mostly some odd number > of bytes. Is there any chance the truncation point is related to how the program is writing its output file? i.e., if it is a text file, is the truncation happening after a new-line or when the stdio library might have done an explicit or implicit fflush()? - Ted -- 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/