On Fri, Mar 23, 2012 at 6:22 PM, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > 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 > Hi, Thanks for clarification. Indeed everything works just with dm_bufio_write_dirty_buffers(). Reboot notifier is to issue the flush only.. As I understand, dm-bufio will do the flush but currently once per 10 seconds. if data on the block device and metadata on other block device get out of sync, what you can do then? how journal helps then? - Dmitry -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
