From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: Inode metadata and file data syncing Date: Wed, 18 Jul 2012 18:48:41 -0700 Message-ID: <3175C1A2-9231-4F77-867C-487EFA26B7C7@whamcloud.com> References: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT Cc: "linux-fsdevel@vger.kernel.org" To: "Jelinek, Sarah" Return-path: Received: from mail-yx0-f174.google.com ([209.85.213.174]:55142 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755821Ab2GSBsu convert rfc822-to-8bit (ORCPT ); Wed, 18 Jul 2012 21:48:50 -0400 Received: by mail-yx0-f174.google.com with SMTP id l2so2286183yen.19 for ; Wed, 18 Jul 2012 18:48:50 -0700 (PDT) In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 2012-07-18, at 9:53, "Jelinek, Sarah" wrote: > I am in the process of writing a file system in Linux. This file system > has a separate mechanism by which we manage metadata so I do not want to > write the file inode metadata to disk without explicitly requesting an > update. I do need the file data pages to be written to disk as per the > normal writeback process. The first, most important, question is why are you writing a new filesystem for Linux? There are lots of filesystems already, and the amount of effort to write a complete filesystem (instead of a simple filesystem with only basic functionality) is fairly high. Unless there is an overwhelmingly good reason to implement a new filesystem, it is better to improve some other existing filesystem to have the feature(s) that you are missing, instead of creating a new one. That helps you avoid a lot of effort, and adds value to everyone else that is using the existing filesystem, instead of making a niche filesystem only useful to yourself and needing ongoing maintenance. > If I use the common mechanism of creating an inode and inserting it into > the hash via insert_inode_locked(), the inode will be in the I_NEW state > and when the inode is marked dirty it will be put on the dirty list and > eventually flushed out to disk. One way I thought I could get around this > is by initializing the inode to i_state = I_DIRTY, skipping I_NEW, and > using insert_inode_hash() instead, so that if mark_inode_dirty() is called > it won't get put on the dirty list. The issue with this approach is that > it looks like this inode's pages will not get flushed to disk either since > it won't ever get on the dirty list. I need the pages written just not the > inode itself. > > I am handling directory inodes differently. Looking at shmem I see that > the backing_dev_info is set to: > > struct backing_dev_info brnl_backing_dev_info = { > .ra_pages = 0, > .capabilities = BDI_CAP_NO_ACCT_AND_WRITEBACK | BDI_CAP_SWAP_BACKED, > }; > > > I have done the same in my code to prevent directory inodes from being > written to disk. > > Can I manage the inode->i_state with the I_DIRTY flag and then somehow > mark the inode pages dirty and add them to the dirty page list > independently? What I am worried about is what affect doing this will have > on the processing of anything in page cache or inode cache related to this > inode. > > Thank you for your help, > Sarah Jelinek > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html