Android Mount输出信息解惑

#Android Mount输出信息解惑| 来源: 网络整理| 查看: 265

Android Mount输出信息解惑 Android mount信息一、存储设备挂载问题二、Overlay问题

Android mount信息

在Android adb shell终端，当你执行mount指令时，你是否会对它输出的信息有以下问题？

一个块设备(dm-6)挂载到了不同的目录，为何内容却是不同的？overlay是什么？ XXXXX:/ # mount ...... overlay on /system type overlay (rw,seclabel,relatime,lowerdir=/system,upperdir=/mnt/scratch/overlay/system/upper,workdir=/mnt/scratch/overlay/system/work,override_creds=off) overlay on /system_ext type overlay (rw,seclabel,relatime,lowerdir=/system_ext,upperdir=/mnt/scratch/overlay/system_ext/upper,workdir=/mnt/scratch/overlay/system_ext/work,override_creds=off) overlay on /product type overlay (rw,seclabel,relatime,lowerdir=/product,upperdir=/mnt/scratch/overlay/product/upper,workdir=/mnt/scratch/overlay/product/work,override_creds=off) overlay on /vendor type overlay (rw,seclabel,relatime,lowerdir=/vendor,upperdir=/mnt/scratch/overlay/vendor/upper,workdir=/mnt/scratch/overlay/vendor/work,override_creds=off) overlay on /odm type overlay (rw,seclabel,relatime,lowerdir=/odm,upperdir=/mnt/scratch/overlay/odm/upper,workdir=/mnt/scratch/overlay/odm/work,override_creds=off) ...... /dev/block/dm-6 on /data type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier) /dev/block/sda20 on /metadata type ext4 (rw,sync,seclabel,nosuid,nodev,noatime,discard,nodelalloc,data=journal) /dev/block/dm-6 on /data/user/0 type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier) tmpfs on /data_mirror type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime,size=3595000k,nr_inodes=898750,mode=700,gid=1000) /dev/block/dm-6 on /data_mirror/data_ce/null type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier) /dev/block/dm-6 on /data_mirror/data_ce/null/0 type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier) /dev/block/dm-6 on /data_mirror/data_de/null type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier) /dev/block/dm-6 on /data_mirror/cur_profiles type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier) ...... /dev/block/dm-6 on /mnt/pass_through/0/emulated type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier) /dev/block/dm-6 on /mnt/user/0/emulated/0/Android/data type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier) /dev/block/dm-6 on /storage/emulated/0/Android/data type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier) /dev/block/dm-6 on /mnt/androidwritable/0/emulated/0/Android/data type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier) 一、存储设备挂载问题

事实上通过mount指令输出的信息并不完整的，这个信息只能看到确定的挂载点，但挂载源却是不能确定的，这个时候需要我们通过其他途径来确认挂载源是什么。

首先通过df指令确定块设备的真实挂载目录（如dm-6 ）： dev/block/dm-6 107338316 4840748 102497568 5% /data

我们从df指令可以知道dm-6块设备(/dev/block/dm-6)真实挂载目录是/data；那从mount指令输出的信息中，dm-6挂载到这么多不同目录又是怎么回事呢？其实是通过"mount --bind"将一个目录mount到另外一个目录上，而mount指令的输出结果中是看不到实际挂载源的，只能显示挂载源的块设备名称。这时候就需要通过/proc/self/mountinfo节点进一步确认挂载源。

cat /proc/self/mountinfo | grep "dm-6"输出结果(部分)： 4232 2646 253:6 /media/0/Android/data /mnt/installer/0/emulated/0/Android/data rw,nosuid,nodev,noatime shared:51 master:40 - f2fs /dev/block/dm-6 rw,lazytime,seclabel,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier 4419 2557 253:6 /media/0/Android/obb /mnt/user/0/emulated/0/Android/obb rw,nosuid,nodev,noatime shared:40 - f2fs /dev/block/dm-6 rw,lazytime,seclabel,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,inlinecrypt,alloc_mode=default,fsync_mode=nobarrier

通过上面的信息，我们可以看到挂载点目录 "/mnt/installer/0/emulated/0/Android/data"的实际挂载源是 "/media/0/Android/data"目录。然后这个挂载源目录和dm-6挂载目录/data/组合就是 “/data/media/0/Android/data”。

二、Overlay问题

在Android开始采用动态分区（DP）后，就开始利用overlayfs来实现Android remount的功能。主要原因是DP分配的分区都是固定大小的，没有多余的空间，因此remount成可写也没有意义。那要怎么实现remount功能呢？overlayfs就是一个很好的解决方案（overlayfs原理和用法可以百度搜索），Android在remount时会使用一个备用分区（物理分区cache或新建立一个虚拟分区scratch）作为overlayfs的上层目录，然后和底层目录合并成一个新的目录呈现给用户。文件的修改、增加或删除都不会改动底层目录的内容，而是修改上层目录的文件。

overlay on /system type overlay (rw,seclabel,relatime,lowerdir=/system,upperdir=/mnt/scratch/overlay/system/upper,workdir=/mnt/scratch/overlay/system/work,override_creds=off)

如上表(remount system分区)： /system目录是底层目录，同时也是合并上层目录后呈现给用户的目录 /mnt/scratch/overlay/system/upper是上层目录 /mnt/scratch/overlay/system/work是工作目录其中/mnt/scratch是挂载了前面提到的备用分区，remount后修改的内容也保存在这个分区。

【本文地址】

公司简介

联系我们