Re: Inode metadata and file data syncing

["Jelinek, Sarah" <sarah.jelinek@intel.com>]

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" <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" <adilger@whamcloud.com> wrote:
>
>>On 2012-07-18, at 9:53, "Jelinek, Sarah" <sarah.jelinek@intel.com> 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
>