[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] dm-bufio
- From: Mikulas Patocka <mpatocka redhat com>
- To: "Kasatkin, Dmitry" <dmitry kasatkin intel com>
- Cc: device-mapper development <dm-devel redhat com>, Zdenek Kabelac <zkabelac redhat com>
- Subject: Re: [dm-devel] dm-bufio
- Date: Fri, 23 Mar 2012 12:22:03 -0400 (EDT)
On Fri, 23 Mar 2012, Kasatkin, Dmitry wrote:
> When using dm-bufio and dm-io in general, how to ensure that all dirty
Regarding dm-io, you don't have to flush dirty buffers because dm-io does
no caching. You only need to flush hardware disk cache with
blkdev_issue_flush.
> At the moment, I have reboot notifier which does the following
>
> dm_bufio_write_dirty_buffers(d->bufio);
> sync_blockdev(d->dev->bdev);
> blkdev_issue_flush(d->dev->bdev, GFP_KERNEL, NULL);
>
> without first line on the next boot I got corrupted/not updated blocks.
> and I am not sure if I need last 2 lines...
You can drop sync_blockdev(d->dev->bdev) --- sync_blockdev flushes kernel
buffer cache and dm-bufio doesn't use the kernel buffer cache (you only
need sync_blockdev if you use kernel buffer cache on this device for
something else). If you drop sync_blockdev, you can also drop
blkdev_issue_flush, because dm_bufio_write_dirty_buffers already issues
the flush request.
BTW. how are you going to deal with kernel crashes or power faults?
It is much better to use journaling, phase tree, crash counts or other
method to maintain metadata integrity insted of reboot notifier --- these
methods maintain integrity even in case of unexpected crash.
Mikulas
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]