Inode metadata and file data syncing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux