Prev: [GIT pull] generic irq updated for 2.6.36
Next: [PATCH 53/67] serial: fix missing bit coverage of ASYNC_FLAGS
From: Tom Weber on 5 Aug 2010 18:30
I stumbled upon this while setting up a new System with

dm-crypt (/dev/mapper/md3dec) on top of
/dev/md3 as raid1 (/dev/sd[ab]5)

and initially filling /dev/mapper/md3dec with zeros
dd if=/dev/zero of=/dev/mapper/md3dec bs=100M

i was curious about how far dd had progressed, so i played around with

dd if=/dev/md3 bs=1M count=1 skip=xx | hexdump

to see if there were still zeros or already crypted data.

now say i found crypted data at offset xx=390000 and zeros at xx=400000
this dd command would always return zeros at 400000 even if the
originial filling dd progressed beyond 400000 (dd at 410000 would give
my crypted data).

up until freeing the page cache with
echo 1 > /proc/sys/vm/drop_caches
a dd at 400000 would always give me zeros (the first result).

is this intended behaviour or is there something going wrong?

this is 2.6.35-vs2.3.0.36.31 (vanilla + vserver patch) on x86_64.

Tom




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [GIT pull] generic irq updated for 2.6.36
Next: [PATCH 53/67] serial: fix missing bit coverage of ASYNC_FLAGS