我想知道我是否在写入/更新之间移动某些文件在闪存(内部存储器)上移动。
有些方法我可以在闪存上获取文件的位置吗?
(群集号码,扇区号等)
我正在使用Android v8,
并且可以安装使用应用程序,
或者使用命令行,如果在Linux命令中存在相关命令,则Android具有。
我想知道我是否在写入/更新之间移动某些文件在闪存(内部存储器)上移动。
有些方法我可以在闪存上获取文件的位置吗?
(群集号码,扇区号等)
我正在使用Android v8,
并且可以安装使用应用程序,
或者使用命令行,如果在Linux命令中存在相关命令,则Android具有。
I would like to know If I certain file moves on the Flash memory (internal storage), between writes/updates to it.
Is there some way I can get the file's location on the Flash memory?
(Cluster Number, Sector Number, etc)
I am using Android v8,
and can either install use an App for that,
or use the Command Line, If a relevant command exists in the Linux command-prompt that Android has.
我假设 群集 你是指Windows'分配单元,在Linux世界中常见于 块 。它是一个数据存储的单位文件系统使用。群集/块可以包含或对应于底层存储介质(HDD或闪存存储)上的多个 扇区 。扇区是存储OS可以读取或写入的最小原子单元。块大小在文件系统创建时决定,即我们格式化分区时( high-level formatting
)。分区和文件系统使其易于对物理存储设备进行分类和组织我们的数据。
硬盘驱动器
"扇区" 可以参考 物理扇区 或 逻辑扇区 。在HDD的早期,只有通过将簇/轨道分成旋转磁盘进入小部分而产生的物理扇区。 c ylinder / h ead / s ector(chs)是在 l ogical之前的一种流行的解决方法 b 锁定 a dddressing(lba)。操作系统而不是直接处理物理扇区,而是通过引用LBA号码与磁盘控制器固件(通过SATA / SCSI命令)交谈。返回的固件维护 lba到chs mapping 本身,其中包括 ecc , G-List (磁盘的缺陷表)等。此映射(1:1 / semence / linear)( abcdefghijklmnabcdefghijklmnlow-level formatting
期间创建的,除了某些扇区的磁盘驱动器时,它永远不会改变,除了标记坏并重新映射到某些备用扇区。因此,操作系统/文件系统了解磁盘的物理几何形状,它是授权的LBA的几何形状。
闪存存储
在闪存介质(SSD,EMMC,UF,SD卡等)上没有旋转磁盘,因此没有汽缸。 NAND闪光由硅电池制成,每个细胞由一个(<强> S ingle- l evel- c ell),两个( m ulti- lc ),三( t riple- lc )或四( q aad - <强> lc )位。将细胞分为<强>页面(例如4kb),并进入<强>擦除块(例如128 kB)。 lbas到 p hysical b lock a ddresses映射由 f leash t 播回<强> l ayer;闪存控制器固件的一部分。操作系统一无所知,它可以在最大限度地看到LBA,而不是下面发生的事情。甚至不是 Ecc 的失败的内存单元,这就是我们不实现的原因emmc的不良健康,除非它失败,除非阅读 EXT_CSD
(需要root)使用 mmc-utils 或来自 /sys/class/mmc_host/*/*/life_time
(如果驱动程序支持)。
由于内存页面不能只是覆盖与HDD不同,因此整个 eraseBlock 必须是 擦除 <强之前> 编程 (写)。副作用是删除/重写的数量的页面,并且即使编辑小文件,物理映射也会发生变化。这种不必要的读取修改 - 写入( RMW w 仪式 a mplification。在HDD上,除非缩短或伸长,否则文件不会物理更换。操作系统知道硬盘上的这些物理更改,但不在闪存上。
什么是扇区?
所以毕竟我们关注的是逻辑领域。 存储媒体通知操作系统其逻辑扇区大小,但"the ,因为HDD已经使用 512B
from早期,虽然事情已经发生了与 4kn格式用于HDD。 512B
是尺寸的尺寸,在实际上,对于标题,ECC等空间,闪存存储上的一些空间是一个更大的空间是 No USE 给我们。
您的查询:
我想知道某个文件是否在闪存(内部存储器)上移动,写入/更新之间。
取决于"移动" 的定义。在闪存存储上,即使您没有写入文件,它可能会继续通过背景 g 插头 c ollection来改变其真实的物理位置;由FTL内部控制的现象以减少WA,实现<强> 磨损水平 ,并通过删除提供高写入吞吐量(程序操作) 无效的页面 在背景中(擦除操作)。
有些方法可以在闪存(群集号,扇区号等)上获取文件的位置吗?
是,您可以获得文件的文件系统块地址,该文件具有线性映射与底层块设备的LBA(分区)。但这些地址不是闪存上的实际/物理文件的位置。然而,除非涉及某些取证或数据恢复,否则通常一个人不关心真实的物理位置。
示例
~# cat /sys/block/mmcblk0/queue/logical_block_size 512 ~# blockdev --getss /dev/block/by-name/cache 512 ~# tune2fs -l /dev/block/by-name/cache | grep 'Block size' Block size: 4096
所以这里的扇区大小是512b,而文件系统块大小为4kib。让我们创建一个测试文件:
~# echo foobar >/cache/test_file ~# cat /cache/test_file foobar ~# filefrag -sv -b512 /cache/test_file Filesystem type is: ef53 File size of /cache/test_file is 7 (8 block of 512 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 7: 307200.. 307207: 8: last,eof /cache/test_file: 1 extent found
* debugfs -R 'stat test_file' /dev/block/by-name/cache
也可以用代替 filefrag
创建的文件(7个字节大小)占用1个文件系统块。 low-level formatting0
将块大小(4096b)转换为扇区大小(512b)。 "test_file" 应在307200 th 扇区,同样适用于分区和文件系统,因为文件系统占用整个分区:
low-level formatting1
让我们直接从分区读取文件:
low-level formatting2
它在那里。现在从emmc的开始定位文件:
low-level formatting3
因此即使文件系统和分区被删除,您也可以读取该文件(提供它未被覆盖)。
让我们做一些更多的挖掘:
low-level formatting4
文件从文件系统中删除,但在身体上仍然存在。让我们询问FTL永久删除它:
low-level formatting5
它已经消失了。但大多数可能仍然存在于 o ver- p rovision空间中,计划在下一个gc中的擦除 ,我们不知道它在哪里。
注意:
low-level formatting6
在naked partitions上是一个杀手。 谨慎! low-level formatting7
和 low-level formatting8
是 e2fsprogs 。 low-level formatting9
未与android一起发货,从源或尝试这个< / a>。 EXT_CSD0
是一个busybox applet。相关:
I assume by saying cluster you mean Windows' allocation unit, commonly called block in Linux world. It's a unit of data storage a filesystem uses. A cluster/block may consist of or correspond to multiple sectors on underlying storage media (HDD or flash storage). Sector is the minimum atomic unit of storage an OS can read or write. Block size is decided at the time of filesystem creation i.e. when we format a partition (high-level formatting
). Partitions and filesystems make it easy to categorize and organize our data on the physical storage device.
HARD DISK DRIVES
"Sector" may refer to a physical sector or logical sector. In early days of HDDs there were only physical sectors created by dividing clusters/tracks on rotating disks into small parts. Cylinder/Head/Sector (CHS) has been a popular method of addressing before the Logical Block Addressing (LBA) was devised. Instead of directly dealing with physical sectors, OS now talks to disk controller firmware (through SATA/SCSI commands) referring an LBA number. Firmware in return maintains an LBA to CHS mapping itself, which includes ECC, G-list (disk's defect table) etc. This mapping (1:1 / sequenced / linear) (ref) is created during low-level formatting
of disk drive when manufacturing, which never changes except if some sector is marked bad and remapped to some spare sector. So the OS / filesystem is aware of the physical geometry of the disk, which is propotional to the geometry of LBAs.
FLASH STORAGE
On flash media (SSDs, eMMC, UFS, SD cards etc.) there are no rotating disks and hence no cylinders. NAND flash is made of silicon cells, each cell consists of one (Single-Level-Cell), two (Multi-LC), three (Triple-LC) or four (Quad-LC) bits. Cells are grouped into pages (e.g. of 4KB) and pages into erase blocks (e.g. of 128 KB). LBAs to Physical Block Addresses mapping is fully controlled by Flash Translation Layer; a part of flash controller firmware. OS knows nothing about it, it can see at maximum the LBAs, not what's happening below it. Not even the ECC of failed memory cells, and that's why we don't realize the bad health of eMMC unless it fails, except by reading EXT_CSD
(requires root) using mmc-utils or from /sys/class/mmc_host/*/*/life_time
(if driver supports).
Since a page of memory can't be just overwritten unlike HDDs, a whole EraseBlock has to be Erased first before being Programmed (written). A side effect is that a number of pages are erased/re-written and the physical mapping changes even if a small file is edited. This unnecessary read-modify-write (RMW) is called Write Amplification. On HDDs, files aren't physically replaced unless shortened or elongated. OS is aware of these physical changes on HDD, but not on flash memory.
WHAT IS SECTOR?
So after all what we are concerned with is logical sector. Storage media informs the OS of its logical sector size but xe2x80x9cthe default of 512 covers most hardwarexe2x80x9d because HDDs have been using 512B
from early days, though things have changed with 4Kn format for HDDs too. 512B
is the size what OS sees, in actual it's a bit larger to make some room for header, ECC etc. Physical sector size on flash storage is of no use to us.
Your queries:
I would like to know if a certain file moves on the Flash memory (internal storage), between writes/updates to it.
It depends on the definition of xe2x80x9cmovexe2x80x9d. On flash storage, even if you don't write to a file, it may keep on changing its true physical location due to background Garbage Collection; a phenomenon controlled by FTL internally to reduce WA, to achieve Wear Leveling and to provide high write throughput (Program operations) by deleting invalid pages in background (Erase operations).
Is there some way I can get the file's location on the Flash memory (Cluster Number, Sector Number etc.)?
Yes you can get the filesystem block addresses of a file which have a linear mapping with LBAs of underlying block device (partition). But these addresses aren't the actual/physical file's location on the Flash memory. However usually one isn't concerned with true physical location unless some forensics or data recovery is involved.
EXAMPLE
~# cat /sys/block/mmcblk0/queue/logical_block_size 512 ~# blockdev --getss /dev/block/by-name/cache 512 ~# tune2fs -l /dev/block/by-name/cache | grep 'Block size' Block size: 4096
So the sector size here is 512B while filesystem block size is 4KiB. Let's create a test file:
~# echo foobar >/cache/test_file ~# cat /cache/test_file foobar ~# filefrag -sv -b512 /cache/test_file Filesystem type is: ef53 File size of /cache/test_file is 7 (8 block of 512 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 7: 307200.. 307207: 8: last,eof /cache/test_file: 1 extent found
* debugfs -R 'stat test_file' /dev/block/by-name/cache
can also be used in place of filefrag
Created file (of 7 bytes size) occupies 1 filesystem block. -b 512
converts block size (4096B) to sector size (512B). "test_file" should be at 307200th sector, same for partition and filesystem because filesystem occupies whole partition:
~# blockdev --getsize64 /dev/block/by-name/cache | awk '$1 /= 4096' 65536 ~# tune2fs -l /dev/block/by-name/cache | grep 'Block count' Block count: 65536
Let's read the file directly from partition:
~# dd if=/dev/block/by-name/cache skip=307200 count=1 | head -c7 foobar
It's there. Now locate the file from the start of eMMC:
~# readlink /dev/block/by-name/cache /dev/block/mmcblk0p25 ~# cat /sys/block/mmcblk0/mmcblk0p25/start 7471104 ~# dd if=/dev/block/mmcblk0 skip=$(( 7471104 + 307200 )) count=1 | head -c7 foobar
So even if filesystem and partition are deleted, you can read the file (provided that it's not overwritten).
Let's do some more digging:
~# rm /cache/test_file; sync; echo -n 1 >/proc/sys/vm/drop_caches ~# dd if=/dev/block/mmcblk0 skip=$(( 7471104 + 307200 )) count=1 | head -c7 foobar
File is deleted from filesystem, but physically still there. Let's ask FTL to delete it permanently:
~# fstrim /cache; sync; echo -n 1 >/proc/sys/vm/drop_caches ~# dd if=/dev/block/mmcblk0 skip=$(( 7471104 + 307200 )) count=1 | head -c7
And it's gone. But most probably it's still there somewhere in Over-Provisioning Space, scheduled to be Erased in next GC, just we don't know where it is.
Note:
dd
on naked partitions is a killer. Be cautious!tune2fs
and filefrag
are part of e2fsprogs. filefrag
isn't shipped with Android, build from source or try this one. fstrim
is a busybox applet.RELATED:
© 2022 it.wenda123.org All Rights Reserved. 问答之家 版权所有