Malahal Naineni wrote: > Riches Jr, RobertX M [robertx.m.riches.jr@xxxxxxxxx] wrote: >> 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. > > I wonder why flushing the underlying device worked but not the actual > device itself. I expected the opposite! :-( > Why, no. That's exactly the point. The device keeps the underlying block devices pinned in the cache, so any page invalidation can only be triggered by the device itself, not the underlying ones. Any writes to the underlying devices won't trigger a page invalidation, so they'll stay in the cache forever. Hence you need to flush them explicitely. Not that I'll recommend that. It'll play silly buggers with the page cache. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
