Re: [Regression] Commit 02c24a82187d5a628c68edfe71ae60dc135cd178 breaks s2disk

On Tuesday, August 02, 2011, Rafael J. Wysocki wrote:

Hi,

Unfortunately s2disk (which is a user space tool for saving hibernate images)
doesn't work any more after your commit 02c24a82187d5a628c68edfe71ae60dc135cd178
(fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers).
The symptom is that the s2disk's resume counterpart cannot find the image in
the device even though s2disk considers it as successfully saved.

What happens is that s2disk opens a block device (disk partition to be precise)
directly and writes to it eventually calling fsync().  My interpretation of the
failure is that before commit 02c24a82187d5a628c68ed, when s2disk called fsync()
the VFS layer would run filemap_write_and_wait_range() that in turn would cause
the data to go to the disk, but after that commit this doesn't happen any more.

If I'm right, then not only s2disk, but any process writing directly to a block
device will have a problem with fsync().

Well, I'm not sure if the patch below is the right fix, but it evidently makes
s2disk work for me again.

Thanks,
Rafael

---
 fs/block_dev.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: linux-2.6/fs/block_dev.c
===================================================================

--- linux-2.6.orig/fs/block_dev.c
+++ linux-2.6/fs/block_dev.c

@@ -387,6 +387,10 @@ int blkdev_fsync(struct file *filp, loff
 	struct inode *bd_inode = filp->f_mapping->host;
 	struct block_device *bdev = I_BDEV(bd_inode);
 	int error;
+	
+	error = filemap_write_and_wait_range(filp->f_mapping, start, end);
+	if (error)
+		return error;
 
 	/*
 	 * There is no need to serialise calls to blkdev_issue_flush with

On Mon, Aug 1, 2011 at 2:17 PM, Rafael J. Wysocki [off-list ref] wrote:

Well, I'm not sure if the patch below is the right fix, but it evidently makes
s2disk work for me again.

Looks right to me.

The only issue is whether we should use "db_mapping->i_mapping" or
"file->f_mapping". I think they are the same for block devices.

Al?

Also, what about some of the other fsync things that apparently
weren't updated to write back page caches. ps3flash_fsync? Others?

                Linus