Linux block layer
 help / color / mirror / Atom feed
* [PATCH] block: flush the disk cache on BLKFLSBUF
@ 2023-06-26 20:25 Mikulas Patocka
  2023-06-27  4:52 ` Christoph Hellwig
  2023-06-27 15:31 ` Mikulas Patocka
  0 siblings, 2 replies; 4+ messages in thread
From: Mikulas Patocka @ 2023-06-26 20:25 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-block, dm-devel, Marc Smith

The BLKFLSBUF ioctl doesn't send the flush bio to the block device, thus
flushed data may be lurking in the disk cache and they may not be really
flushed to the stable storage.

This patch adds the call to blkdev_issue_flush to blkdev_flushbuf.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

---
 block/ioctl.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6/block/ioctl.c
===================================================================
--- linux-2.6.orig/block/ioctl.c
+++ linux-2.6/block/ioctl.c
@@ -351,6 +351,7 @@ static int blkdev_flushbuf(struct block_
 		return -EACCES;
 	fsync_bdev(bdev);
 	invalidate_bdev(bdev);
+	blkdev_issue_flush(bdev);
 	return 0;
 }
 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] block: flush the disk cache on BLKFLSBUF
  2023-06-26 20:25 [PATCH] block: flush the disk cache on BLKFLSBUF Mikulas Patocka
@ 2023-06-27  4:52 ` Christoph Hellwig
  2023-06-27 15:31 ` Mikulas Patocka
  1 sibling, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2023-06-27  4:52 UTC (permalink / raw)
  To: Mikulas Patocka; +Cc: Jens Axboe, linux-block, dm-devel, Marc Smith

On Mon, Jun 26, 2023 at 10:25:28PM +0200, Mikulas Patocka wrote:
> The BLKFLSBUF ioctl doesn't send the flush bio to the block device, thus
> flushed data may be lurking in the disk cache and they may not be really
> flushed to the stable storage.
> 
> This patch adds the call to blkdev_issue_flush to blkdev_flushbuf.

Umm, why?  This is an ioctl no one should be using, and we certainly
should not add new functionality to it.  Can you explain what you're
trying to do here?


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] block: flush the disk cache on BLKFLSBUF
  2023-06-26 20:25 [PATCH] block: flush the disk cache on BLKFLSBUF Mikulas Patocka
  2023-06-27  4:52 ` Christoph Hellwig
@ 2023-06-27 15:31 ` Mikulas Patocka
  2023-06-27 15:49   ` Christoph Hellwig
  1 sibling, 1 reply; 4+ messages in thread
From: Mikulas Patocka @ 2023-06-27 15:31 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-block, Jens Axboe, dm-devel, Marc Smith



> On Mon, 26 Jun 2023, Mikulas Patocka wrote:
> 
> > The BLKFLSBUF ioctl doesn't send the flush bio to the block device, thus
> > flushed data may be lurking in the disk cache and they may not be really
> > flushed to the stable storage.
> > 
> > This patch adds the call to blkdev_issue_flush to blkdev_flushbuf.
> 
> Umm, why?  This is an ioctl no one should be using, and we certainly
> should not add new functionality to it.  Can you explain what you're
> trying to do here?

Marc Smith reported a bug where he wrote to the dm-writecache target using 
O_DIRECT, then reset the machine without proper shutdown and the freshly 
written data were lost. It turned out that he didn't use the fsync or 
fdatasync syscall (and dm-writecache makes its metadata persistent on a 
FLUSH bio).

When I was analyzing this issue, it turned out that there is no easy way 
how to send the FLUSH bio to a block device from a command line.

The sync command synchronizes only filesystems, it doesn't flush cache for 
unmounted block devices (do you think that it should flush block devices 
too?).

The "blockdev --flushbufs" command also doesn't send the FLUSH bio, but I 
would expect it to send it. Without sending the FLUSH bio, "blockdev 
--flushbufs" doesn't really guarantee anything.

Mikulas


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] block: flush the disk cache on BLKFLSBUF
  2023-06-27 15:31 ` Mikulas Patocka
@ 2023-06-27 15:49   ` Christoph Hellwig
  0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2023-06-27 15:49 UTC (permalink / raw)
  To: Mikulas Patocka
  Cc: Christoph Hellwig, linux-block, Jens Axboe, dm-devel, Marc Smith

On Tue, Jun 27, 2023 at 05:31:12PM +0200, Mikulas Patocka wrote:
> Marc Smith reported a bug where he wrote to the dm-writecache target using 
> O_DIRECT, then reset the machine without proper shutdown and the freshly 
> written data were lost. It turned out that he didn't use the fsync or 
> fdatasync syscall (and dm-writecache makes its metadata persistent on a 
> FLUSH bio).

Which so far is expected.  Even with O_DIRECT you need O_(D)SYNC or
fsync/fdatasync to persist data.

> When I was analyzing this issue, it turned out that there is no easy way 
> how to send the FLUSH bio to a block device from a command line.

xfs_io -c fsync /dev/foo

> The "blockdev --flushbufs" command also doesn't send the FLUSH bio, but I 
> would expect it to send it. Without sending the FLUSH bio, "blockdev 
> --flushbufs" doesn't really guarantee anything.

I wouldn't expect it.  It's a really weird legacy thing that calls
back up into the file system, but only if it sets s_bdev to this
device.  I don't think we should add new users of it that overload the
semantics.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-06-27 15:50 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-26 20:25 [PATCH] block: flush the disk cache on BLKFLSBUF Mikulas Patocka
2023-06-27  4:52 ` Christoph Hellwig
2023-06-27 15:31 ` Mikulas Patocka
2023-06-27 15:49   ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox