| Message ID | 1269620462-25906-1-git-send-email-surbhi.palande@canonical.com |
|---|---|
| State | New, archived |
| Headers | show |
Surbhi Palande <surbhi.palande@canonical.com> writes: > Ensure that in the no journal mode the write cache is flushed to the disk by > calling a blkdev_issue_flush() which issues a WRITE_BARRIER if necessary. As soon as i understand, nojournal mode is assumed to be used for fail-free block devices(raid + UPS). So we don't have to worry about blkdev's wcache vs persistent storage correctness. > > Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com> > --- > fs/ext4/fsync.c | 8 ++++++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/fs/ext4/fsync.c b/fs/ext4/fsync.c > index d6049e4..1d73a50 100644 > --- a/fs/ext4/fsync.c > +++ b/fs/ext4/fsync.c > @@ -67,8 +67,12 @@ int ext4_sync_file(struct file *file, struct dentry *dentry, int datasync) > if (ret < 0) > return ret; > > - if (!journal) > - return simple_fsync(file, dentry, datasync); > + if (!journal) { > + ret = simple_fsync(file, dentry, datasync); > + if (test_opt(inode->i_sb, BARRIER)) > + blkdev_issue_flush(inode->i_sb->s_bdev, NULL); > + return ret; > + } > > /* > * data=writeback,ordered: -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/26/2010 12:37 PM, Dmitry Monakhov wrote: > Surbhi Palande<surbhi.palande@canonical.com> writes: > > >> Ensure that in the no journal mode the write cache is flushed to the disk by >> calling a blkdev_issue_flush() which issues a WRITE_BARRIER if necessary. >> > As soon as i understand, nojournal mode is assumed to be used for > fail-free block devices(raid + UPS). So we don't have to worry about > blkdev's wcache vs persistent storage correctness. > I don't think that is a safe assumption. If users want that behavior, they can mount with fs without barriers... ric >> Signed-off-by: Surbhi Palande<surbhi.palande@canonical.com> >> --- >> fs/ext4/fsync.c | 8 ++++++-- >> 1 files changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/fs/ext4/fsync.c b/fs/ext4/fsync.c >> index d6049e4..1d73a50 100644 >> --- a/fs/ext4/fsync.c >> +++ b/fs/ext4/fsync.c >> @@ -67,8 +67,12 @@ int ext4_sync_file(struct file *file, struct dentry *dentry, int datasync) >> if (ret< 0) >> return ret; >> >> - if (!journal) >> - return simple_fsync(file, dentry, datasync); >> + if (!journal) { >> + ret = simple_fsync(file, dentry, datasync); >> + if (test_opt(inode->i_sb, BARRIER)) >> + blkdev_issue_flush(inode->i_sb->s_bdev, NULL); >> + return ret; >> + } >> >> /* >> * data=writeback,ordered: >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/26/2010 12:16 PM, Ric Wheeler wrote: > On 03/26/2010 12:37 PM, Dmitry Monakhov wrote: >> Surbhi Palande<surbhi.palande@canonical.com> writes: >> >> >>> Ensure that in the no journal mode the write cache is flushed to the disk by >>> calling a blkdev_issue_flush() which issues a WRITE_BARRIER if necessary. >>> >> As soon as i understand, nojournal mode is assumed to be used for >> fail-free block devices(raid + UPS). So we don't have to worry about >> blkdev's wcache vs persistent storage correctness. No, I don't think so - even with "fail-free" storage, a system crash still results in an inconsistent filesystem; with nojournalling you've made the decision to either fsck or re-mkfs after that event. > I don't think that is a safe assumption. If users want that behavior, > they can mount with fs without barriers... yes, I agree with Ric - even if you don't have journalling, the proper sequence of sync calls should still result in data permanently on disk by default. (though I think using mount -o nobarrier for this purpose, in absence of journalling, overloads the option a little...) -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/ext4/fsync.c b/fs/ext4/fsync.c index d6049e4..1d73a50 100644 --- a/fs/ext4/fsync.c +++ b/fs/ext4/fsync.c @@ -67,8 +67,12 @@ int ext4_sync_file(struct file *file, struct dentry *dentry, int datasync) if (ret < 0) return ret; - if (!journal) - return simple_fsync(file, dentry, datasync); + if (!journal) { + ret = simple_fsync(file, dentry, datasync); + if (test_opt(inode->i_sb, BARRIER)) + blkdev_issue_flush(inode->i_sb->s_bdev, NULL); + return ret; + } /* * data=writeback,ordered:
Ensure that in the no journal mode the write cache is flushed to the disk by calling a blkdev_issue_flush() which issues a WRITE_BARRIER if necessary. Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com> --- fs/ext4/fsync.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-)