From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: RE: Inode metadata and file data syncing Date: Thu, 19 Jul 2012 09:50:59 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Cc: To: , Return-path: Received: from hop-nat-141.emc.com ([168.159.213.141]:32697 "EHLO mexforward.lss.emc.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750907Ab2GSNvV convert rfc822-to-8bit (ORCPT ); Thu, 19 Jul 2012 09:51:21 -0400 In-Reply-To: Content-Language: en-US Sender: linux-fsdevel-owner@vger.kernel.org List-ID: I am simply curious what all the current file systems features we lack today as maybe others can contribute. Hope this makes sense /Sorin -----Original Message----- From: Jelinek, Sarah [mailto:sarah.jelinek@intel.com] Sent: Thursday, July 19, 2012 9:18 AM To: faibish, sorin; adilger@whamcloud.com Cc: linux-fsdevel@vger.kernel.org Subject: Re: Inode metadata and file data syncing No, I am sorry I can't give you any details at this time. Its still under development. On 7/19/12 7:12 AM, "faibish_sorin@emc.com" wrote: >Involving in writing a new file system as a job requirement? There should >be some value or special features that the file system has, maybe? Could >you tell what new FS features this introduces? > >/Sorin > >-----Original Message----- >From: linux-fsdevel-owner@vger.kernel.org >[mailto:linux-fsdevel-owner@vger.kernel.org] On Behalf Of Jelinek, Sarah >Sent: Thursday, July 19, 2012 8:45 AM >To: Andreas Dilger >Cc: linux-fsdevel@vger.kernel.org >Subject: Re: Inode metadata and file data syncing > >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 > >-- >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 >