From: Josef Bacik <jbacik@fusionio.com>
To: "Jelinek, Sarah" <sarah.jelinek@intel.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: Inode metadata and file data syncing
Date: Wed, 18 Jul 2012 13:21:32 -0400 [thread overview]
Message-ID: <20120718172132.GD2112@localhost.localdomain> (raw)
In-Reply-To: <CC2C4609.1A9A5%sarah.jelinek@intel.com>
On Wed, Jul 18, 2012 at 10:53:00AM -0600, 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.
>
> 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.
>
All the major file systems do this currently. If you just don't implement
->write_inode() you can control when the metadata is written out, the data will
be flushed normally and you can write out the metadata whenever you feel like
it, like the rest of us do without doing horrible things to the i_state.
Thanks,
Josef
next prev parent reply other threads:[~2012-07-18 17:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-18 16:53 Inode metadata and file data syncing Jelinek, Sarah
2012-07-18 17:21 ` Josef Bacik [this message]
2012-07-18 17:52 ` Jelinek, Sarah
2012-07-19 1:48 ` Andreas Dilger
2012-07-19 12:44 ` Jelinek, Sarah
2012-07-19 13:12 ` faibish_sorin
2012-07-19 13:18 ` Jelinek, Sarah
2012-07-19 13:50 ` faibish_sorin
2012-07-19 16:49 ` Zach Brown
2012-07-19 17:11 ` Andreas Dilger
2012-07-19 18:08 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120718172132.GD2112@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sarah.jelinek@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).