From patchwork Mon Jan 5 15:14:07 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Artem Bityutskiy X-Patchwork-Id: 16644 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 8AA33DE004 for ; Tue, 6 Jan 2009 02:17:38 +1100 (EST) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.68 #1 (Red Hat Linux)) id 1LJrAF-0006dQ-Eg; Mon, 05 Jan 2009 15:14:47 +0000 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by bombadil.infradead.org with esmtps (Exim 4.68 #1 (Red Hat Linux)) id 1LJrAC-0006dL-Lq for linux-mtd@lists.infradead.org; Mon, 05 Jan 2009 15:14:45 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n05FETTH014866; Mon, 5 Jan 2009 17:14:39 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jan 2009 17:13:21 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jan 2009 17:13:21 +0200 Received: from [172.21.40.72] (esdhcp04072.research.nokia.com [172.21.40.72]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n05FDKVN026045; Mon, 5 Jan 2009 17:13:20 +0200 Subject: Re: about the _dtype_ parameter From: Artem Bityutskiy To: xiaochuan xu In-Reply-To: References: Date: Mon, 05 Jan 2009 17:14:07 +0200 Message-Id: <1231168447.6608.26.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 (2.24.2-2.fc10) X-OriginalArrivalTime: 05 Jan 2009 15:13:21.0370 (UTC) FILETIME=[2577B3A0:01C96F48] X-Nokia-AV: Clean X-Spam-Score: -4.0 (----) X-Spam-Report: SpamAssassin version 3.2.5 on bombadil.infradead.org summary: Content analysis details: (-4.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -4.0 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [192.100.122.230 listed in list.dnswl.org] Cc: linux-mtd@lists.infradead.org X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dedekind@infradead.org List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Mon, 2009-01-05 at 22:59 +0800, xiaochuan xu wrote: > Hi, > > >> In my test, I found that the third parameter of ubi_wl_get_peb() > >> function _dtype_ is always UBI_SHORTTERM. > > >Which test? > I write a temporary file in the ubifs with O_TRUNC flag over and over. > I see that all the @dtype variables are equal to 2 not 3. > why does this happen? Hmm, indeed, UBIFS uses UBI_SHORTTERM in 'reserve_space()', which looks wrong - thanks for noticing. Could you please try the attached patch? > Even though, as you say, most of the data are type of UBI_UNKNOWN, > the @dtype variable seems to make less sense in the current implemenation. > If this is ture, I think it's necessary to implement a > dynamic-data-type-classification > policy. Agree. I'll be happy to merge such an improvement, but I do not have plans to do this myself. Patch: diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c index 10ae25b..6a885c5 100644 --- a/fs/ubifs/journal.c +++ b/fs/ubifs/journal.c @@ -208,7 +208,7 @@ again: offs = 0; out: - err = ubifs_wbuf_seek_nolock(wbuf, lnum, offs, UBI_SHORTTERM); + err = ubifs_wbuf_seek_nolock(wbuf, lnum, offs, UBI_UNKNOWN); if (err) goto out_unlock;