From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757535Ab2CIQJU (ORCPT ); Fri, 9 Mar 2012 11:09:20 -0500 Received: from mga09.intel.com ([134.134.136.24]:36889 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754530Ab2CIQJT (ORCPT ); Fri, 9 Mar 2012 11:09:19 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="119448307" Message-ID: <1331309451.29445.42.camel@sauron.fi.intel.com> Subject: Re: [PATCH 5/9] writeback: introduce the pageout work From: Artem Bityutskiy Reply-To: dedekind1@gmail.com To: Jan Kara Cc: Fengguang Wu , Andrew Morton , Greg Thelen , Ying Han , "hannes@cmpxchg.org" , KAMEZAWA Hiroyuki , Rik van Riel , Mel Gorman , Minchan Kim , Linux Memory Management List , LKML , Adrian Hunter Date: Fri, 09 Mar 2012 18:10:51 +0200 In-Reply-To: <20120309095135.GC21038@quack.suse.cz> References: <20120228160403.9c9fa4dc.akpm@linux-foundation.org> <20120301123640.GA30369@localhost> <20120301163837.GA13104@quack.suse.cz> <20120302044858.GA14802@localhost> <20120302095910.GB1744@quack.suse.cz> <20120302103951.GA13378@localhost> <20120302115700.7d970497.akpm@linux-foundation.org> <20120303135558.GA9869@localhost> <1331135301.32316.29.camel@sauron.fi.intel.com> <20120309073113.GA5337@localhost> <20120309095135.GC21038@quack.suse.cz> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2012-03-09 at 10:51 +0100, Jan Kara wrote: > > However I cannot find any ubifs functions to form the above loop, so > > ubifs should be safe for now. > Yeah, me neither but I also failed to find a place where > ubifs_evict_inode() truncates inode space when deleting the inode... Artem? We do call 'truncate_inode_pages()': static void ubifs_evict_inode(struct inode *inode) { ... truncate_inode_pages(&inode->i_data, 0); ... } -- Best Regards, Artem Bityutskiy