Many thanks to those who responded with helpful suggestions. A couple of the suggestions were sufficient to make my test script behave as I expect--to liberate the data that had been stuck in the page cache twilight zone. :-) For the benefit of anyone who might come across the archives with a similar problem, here's what worked and what didn't, with all actions taken between writing and reading: - Using 'dd -iflag=direct' to read from /dev/vg1/lv1 (the underlying device) worked. - Doing 'blockdev --flushbufs /dev/vg1/lv1' (on the underlying device) worked. - Doing 'blockdev --flushbufs /dev/mapper/fred01' (on the device exposed by dm-linear or my module) did not solve the problem. - Doing 'dmsetup suspend fred01' did not work. - Doing fsync() on /dev/mapper/fred01 did not work. - Doing fsync() on /dev/vg1/lv1 did not work. Of those above that "worked", each was independently sufficient to solve the problematic symptoms. IOW, I only had to apply one solution, not all of them. Again, thanks for all the solutions. Robert Riches Azad Consultant at Intel -----Original Message----- From: Alasdair G Kergon [mailto:agk@xxxxxxxxxx] Sent: Wednesday, June 30, 2010 5:52 PM To: Riches Jr, RobertX M Cc: Dm-Devel Mailing List Send-To Address (dm-devel@xxxxxxxxxx) Subject: Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use? On Wed, Jun 30, 2010 at 04:53:23PM -0700, Riches Jr, RobertX M wrote: > I didn't see any queues or caches in dm-linear that would need to be flushed. It's your test script that is not behaving as you expect:) Add conv=odirect to dd Add blockdev --flushbufs after other writes. Alasdair -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
