Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 26 Mar 2002 08:00:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 26 Mar 2002 08:00:30 -0500 Received: from bay-bridge.veritas.com ([143.127.3.10]:32357 "EHLO svldns02.veritas.com") by vger.kernel.org with ESMTP id ; Tue, 26 Mar 2002 08:00:19 -0500 Date: Tue, 26 Mar 2002 13:02:12 +0000 (GMT) From: Hugh Dickins To: Andrew Morton cc: Christoph Hellwig , Christoph Rohland , linux-mm@kvack.org, linux-kernel@vger.kernel.org, velco@fadata.bg Subject: Re: [PATCH] updated radix-tree pagecache In-Reply-To: <3CA045BC.AA75D788@zip.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 26 Mar 2002, Andrew Morton wrote: > > Aside: This is not related to ratcache: shmem_getpage_locked() is > setting PG_dirty but not adding the page to mapping->dirty_pages. Is > this intended? Yes. It used to be the case that if a tmpfs file page got on to mapping->dirty_pages, fsync on that file would never escape from filemap_fdatasync if there was no swap. Hence also "SetPageDirty" in several places which originally said "set_page_dirty". Nowadays the "if (!PageLaunder(page)) return fail_writepage(page);" at the start of shmem_writepage would prevent that hang, and prevents a subtler tmpfs file corruption we realized later on. But the dirty_pages list is still a waste of time for tmpfs: its data does not need to be committed to stable storage. Hugh - 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/