LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Christoph Hellwig <email@example.com> To: Nick Piggin <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, Roman Zippel <firstname.lastname@example.org>, "Tigran A. Aivazian" <email@example.com>, Boaz Harrosh <firstname.lastname@example.org>, OGAWA Hirofumi <email@example.com>, Dave Kleikamp <firstname.lastname@example.org>, Bob Copeland <email@example.com>, firstname.lastname@example.org, Christoph Hellwig <email@example.com>, Evgeniy Dushistov <firstname.lastname@example.org>, Jan Kara <email@example.com> Subject: Re: [RFC][PATCH] Possible data integrity problems in lots of filesystems? Date: Thu, 25 Nov 2010 07:01:33 -0500 [thread overview] Message-ID: <20101125120133.GA22222@infradead.org> (raw) In-Reply-To: <20101125115457.GB3643@amd> On Thu, Nov 25, 2010 at 10:54:57PM +1100, Nick Piggin wrote: > On Thu, Nov 25, 2010 at 06:49:09PM +1100, Nick Piggin wrote: > > Second is confusing sync and async inode metadata writeout > > Core code clears I_DIRTY_SYNC and I_DIRTY_DATASYNC before calling > > ->write_inode *regardless* of whether it is a for-integrity call or > > not. This means background writeback can clear it, and subsequent > > sync_inode_metadata or sync(2) call will skip the next ->write_inode > > completely. > > Hmm, this also means that write_inode_now(sync=1) is buggy. It > needs to in fact call ->fsync -- which is a file operation > unfortunately, Christoph didn't you have some patches to move it > into an inode operation? No, it doesn't really make much sense either. But what I've slowly started doing is to phase out write_inode_now. For the cases where we really only want to write the inode we should use sync_inode_metadata. That only leaves two others callsers: - iput_final for a filesystem during unmount. This should be caught by the need to call ->sync_fs rule you mentioned above, but needs a closer audit. - nfsd. Any filesystem that cares should just use the commit_metadata export operations, which is a subsystem of ->fsync as it only need to guarantee that metadata is on disk, but not actually any file data - so no cache flush mess as in a real fsync implementation.
prev parent reply other threads:[~2010-11-25 12:01 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-11-25 7:49 [RFC][PATCH] Possible data integrity problems in lots of filesystems? Nick Piggin 2010-11-25 9:28 ` Boaz Harrosh 2010-11-25 10:06 ` Nick Piggin 2010-11-25 10:51 ` Boaz Harrosh 2010-11-25 10:52 ` [PATCH] exofs: simple fsync race fix Boaz Harrosh 2010-11-25 11:50 ` Nick Piggin 2011-02-03 11:44 ` Boaz Harrosh 2010-11-25 11:47 ` [RFC][PATCH] Possible data integrity problems in lots of filesystems? Nick Piggin 2010-11-25 12:18 ` Boaz Harrosh 2010-11-25 11:54 ` Nick Piggin 2010-11-25 12:01 ` Christoph Hellwig [this message]
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=20101125120133.GA22222@infradead.org \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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: linkBe 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).