From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jelinek, Sarah" Subject: Re: Inode metadata and file data syncing Date: Thu, 19 Jul 2012 12:44:55 +0000 Message-ID: References: <3175C1A2-9231-4F77-867C-487EFA26B7C7@whamcloud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Cc: "linux-fsdevel@vger.kernel.org" To: Andreas Dilger Return-path: Received: from mga11.intel.com ([192.55.52.93]:64532 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751594Ab2GSMo5 convert rfc822-to-8bit (ORCPT ); Thu, 19 Jul 2012 08:44:57 -0400 In-Reply-To: <3175C1A2-9231-4F77-867C-487EFA26B7C7@whamcloud.com> Content-Language: en-US Content-ID: <85A60733AB5CBA42AD25996D5E998E6E@intel.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: I am doing a project for my company. On 7/18/12 7:48 PM, "Andreas Dilger" wrote: >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