On 2012-07-18, at 9:53, "Jelinek, Sarah" <sarah.jelinek@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
