14

Reading from /dev/block/mmcblk0 returned old data while reading from /dev/block/mmcblk0p1 gave latest data. My question is does linux maintain a back up if data is written to /dev/block/mmcblk0? This is because i was able to read old contents of the SD card by reading through that node.

spitfire88
  • 1,596
  • 3
  • 19
  • 31
  • 6
    Are you sure it's returning "old data", as in the data before writing to it? It sounds to me like those two block devices are the entire disk and the first partition. IO on mmcblk0p1 is just like read/write on mmcblk0 with an offset. – cdleonard Sep 11 '12 at 12:21
  • 3
    cdleonard is correct. mmcblk0 is the whole disk (starting from the boot sector and containing the partition table) and mmcblk0p1 is the first partition. There is no way mmcblk0 contains "old" data. – Gnurou Sep 12 '12 at 02:54
  • `mmcblk0` is the device while `mmcblk0p1` is the device's partition. p = partition, 1 = second partition(bcz it start from 0) – Yousha Aleayoub May 15 '20 at 22:19
  • **Warning!** Those two devices share most blocks, but do not share the same cache! [See my answer](https://stackoverflow.com/a/69411025/490291) – Tino Oct 01 '21 at 19:19

2 Answers2

19

The mmc sub-system in the Linux kernel registers device nodes of the format mmcblkXpY.

  • Each mmc device registered within the Linux kernel receives it own mmc device number X.
  • Each partition on a particular device receives it own number Y

Normal file I/O can be performed after mounting a device node pointing to a partition.

Also note that unless a valid partition table is present on the /dev/mmcblkX device, there will be no subsequent /dev/mmcblkXpY nodes on the system.

nhed
  • 5,774
  • 3
  • 30
  • 44
TheCodeArtist
  • 21,479
  • 4
  • 69
  • 130
  • on my linux system, it comes as /dev/sdb1 and sdb2, why so? – Akay Mar 01 '19 at 14:02
  • 3
    Whether a storage block device is enumerated as `/dev/sd...` or `/dev/mmcblk...` depends on how the blocks device is registered in the Linux kernel. SCSI disks handled by `drivers/scsi/sd.c` are listed with names beginning with `sd`. MMC devices handles by `drivers/mmc/card/block.c` are listed with names beginning with `mmcblk`. – TheCodeArtist Mar 02 '19 at 11:03
0

Linux does not maintain a backup. It maintains a cache. This has nothing to do with the particular block device or driver (/dev/mmcblk* in your case), instead it has something to do how the block cache works.

Hence your observation is normal, but dangerous. (Normally this is not a problem, because only root can find this "feature".)

In Linux each block device is handled independently in the kernel when it comes to caching. As the raw device (in your case /dev/mmcblk0) and the partition (dev/mmcblk0p1) are different block devices, both have independent caches!

If then the partition (/dev/mmcblk0p1) gets updated, the cache of the partition is updated, of course, but the cache of the raw device is not updated at all, hence it becomes stale (from the mapped data, the cache instance still is considered fresh).

If you then re-access the raw device again, the still (stale) cached data may be returned, as long as the cache is not flushed.

This is true in the opposite direction, like when updating the partition data through the raw device. This latter usually kills the filesystem on the partition!

If you want to get rid of the cache, you need to flush all caches before re-accessing the drive. This has two effects:

  • Flushing also syncs the data on the disk, so if forces out dirty data in the cache to the filesystem (aka. partition).

  • Flushing also gets rid of old cached data on the raw block device.

Flushing is done with:

echo 3 >/proc/sys/vm/drop_caches

But beware. Active partitions still may change quickly afterwards. And you cannot read dirty data of the partition cache from the raw device and vice versa.

Tino
  • 9,583
  • 5
  • 55
  • 60