Re: Inode metadata and file data syncing

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

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