From: Jan Kara <jack@suse.cz>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext3: enable cache flush in ext3_sync_file
Date: Tue, 8 Sep 2009 15:04:38 +0200 [thread overview]
Message-ID: <20090908130438.GA2528@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <4A9D66C5.4060806@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 802 bytes --]
> Christoph Hellwig wrote:
> > We need to flush the write cache unconditionally in ->fsync, otherwise
> > writes into already allocated blocks can get lost. Writes into fully
> > allocated files are very common when using disk images for
> > virtualization, and without this fix can easily lose data after
> > an fdatasync, which is the typical implementation for a cache flush on
> > the virtual drive.
> >
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Given that I tried to do the same thing 1.5 years ago (though not quite
> correctly) ...
>
> Acked-by: Eric Sandeen <sandeen@redhat.com>
But would the patch below be better? When we force a transaction
commit we don't have to flush caches again. Or am I missing something?
Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
[-- Attachment #2: 0001-ext3-Flush-disk-caches-on-fsync-when-needed.patch --]
[-- Type: text/x-diff, Size: 1628 bytes --]
>From 4412c3d5cc04849d959e9083d3bdf0b4a058e947 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Tue, 8 Sep 2009 14:59:42 +0200
Subject: [PATCH] ext3: Flush disk caches on fsync when needed
In case we fsync() a file and inode is not dirty, we don't force a transaction
to disk and hence don't flush disk caches. Thus file data could be just in disk
caches and not on persistent storage. Fix the problem by flushing disk caches
if we didn't force a transaction commit.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/ext3/fsync.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/fs/ext3/fsync.c b/fs/ext3/fsync.c
index d336341..451d166 100644
--- a/fs/ext3/fsync.c
+++ b/fs/ext3/fsync.c
@@ -23,6 +23,7 @@
*/
#include <linux/time.h>
+#include <linux/blkdev.h>
#include <linux/fs.h>
#include <linux/sched.h>
#include <linux/writeback.h>
@@ -73,7 +74,7 @@ int ext3_sync_file(struct file * file, struct dentry *dentry, int datasync)
}
if (datasync && !(inode->i_state & I_DIRTY_DATASYNC))
- goto out;
+ goto flush;
/*
* The VFS has written the file data. If the inode is unaltered
@@ -85,7 +86,16 @@ int ext3_sync_file(struct file * file, struct dentry *dentry, int datasync)
.nr_to_write = 0, /* sys_fsync did this */
};
ret = sync_inode(inode, &wbc);
+ goto out;
}
+flush:
+ /*
+ * In case we didn't commit a transaction, we have to flush
+ * disk caches manually so that data really is on persistent
+ * storage
+ */
+ if (test_opt(inode->i_sb, BARRIER))
+ blkdev_issue_flush(inode->i_sb->s_bdev, NULL);
out:
return ret;
}
--
1.6.0.2
next prev parent reply other threads:[~2009-09-08 13:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-31 19:37 [PATCH] ext3: enable cache flush in ext3_sync_file Christoph Hellwig
2009-09-01 18:24 ` Eric Sandeen
2009-09-08 13:04 ` Jan Kara [this message]
2009-09-08 13:10 ` Christoph Hellwig
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=20090908130438.GA2528@atrey.karlin.mff.cuni.cz \
--to=jack@suse.cz \
--cc=hch@lst.de \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.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).