The fact is that I've been able to reproduce the problem on LVM block devices, and sd* block devices so it's definitely not a loop device specific problem. By the way, I tried several other things other than "echo s >/proc/sysrq_trigger" I tried multiple sync followed with a one minute "sleep", "echo 3 >/proc/sys/vm/drop_caches" seems to lower the chances of "hash changes" but doesn't stops them. On Tue, Feb 23, 2010 at 12:09 AM, Andreas Dilger <adilger@xxxxxxx> wrote: > On 2010-02-22, at 16:05, Jan Kara wrote: >> >> Hmm, and apparently there is some subtlety in the loopback device code >> because even when I use sync(1), the first and second images sometimes >> differ (although it's much rarer). But I see a commit block of the >> transaction already in the first image (the commit block is written last) >> but the contents of the transaction is present only in the second image. > > > It has never been safe to run ext3 on top of a loop device, because the loop > device does not preserve ordering, and I'm not sure whether it properly > passes barriers either. > > Cheers, Andreas > -- > Andreas Dilger > Sr. Staff Engineer, Lustre Group > Sun Microsystems of Canada, Inc. > > -- Camille Moncelier http://devlife.org/ If Java had true garbage collection, most programs would delete themselves upon execution. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
