读指定物理扇区：
dd if=<源设备> of=<输出设备或文件> skip=<指定扇区值> bs=512 count=1
写指定物理扇区：
dd if=<输入设备或文件> of=<输出设备> seek=<指定扇区值> bs=512 count=1
实例：
我们以文件/root/linux-2.6.32.36-0.5/REPORTING-BUGS为例，该文件大小为4K。
通过debugfs，可以看到REPORTING-BUGS文件所占用的文件系统块号为584933，/dev/sda1分区文件系统类型为ext4，默认块大小4K。
则REPORTING-BUGS文件所在584933转换为扇区（512字节）为584933×8=4679464
而分区/dev/sda1的起始物理扇区为2048，因此REPORTING-BUGS文件在sda硬盘上的物理扇区起始位置为584933*8 + 2048=4681512。
通过dd命令读取指定4681512物理扇区，然后查看读取的数据，直接读写硬盘物理扇区的方法得到验证。
root@ubuntu:~/linux-2.6.32.36-0.5# ls -l REPORTING-BUGS
-rw-r–r– 1 root root 3371 2011-05-30 07:39 REPORTING-BUGS
root@ubuntu:~/linux-2.6.32.36-0.5# pwd
/root/linux-2.6.32.36-0.5
root@ubuntu:~/linux-2.6.32.36-0.5# du -s REPORTING-BUGS
4 REPORTING-BUGS
root@ubuntu:~/linux-2.6.32.36-0.5#
root@ubuntu:~/linux-2.6.32.36-0.5# debugfs /dev/sda1
debugfs 1.41.14 (22-Dec-2010)
debugfs: cd /root
debugfs: ls
debugfs: cd linux-2.6.32.36-0.5
debugfs: ls
debugfs: bmap REPORTING-BUGS 0
584933
debugfs:
root@ubuntu:~# dd if=/dev/sda of=test.dump skip=4681512 bs=512 count=1
root@ubuntu:~/linux-2.6.32.36-0.5# fdisk -lu
Disk /dev/sda: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000444d0
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 40894463 20446208 83 Linux
/dev/sda2 40896510 41940991 522241 5 Extended
/dev/sda5 40896512 41940991 522240 82 Linux swap / Solaris
root@ubuntu:~/linux-2.6.32.36-0.5#
root@ubuntu:~# cat test.dump
[Some of this is taken from Frohwalt Egerer’s original linux-kernel FAQ]
What follows is a suggested procedure for reporting Linux bugs. You
aren’t obliged to use the bug reporting format, it is provided as a guide
to the kind of information that can be useful to developers – no more.
If the failure includes an “OOPS:” type message in your log or on
screen please read “Documentation/oops-tracing.txt” before posting your
bug report. This explains what you should do with the “Oops” information
to root@ubuntu:~#
root@ubuntu:~/linux-2.6.32.36-0.5# pwd
/root/linux-2.6.32.36-0.5
root@ubuntu:~/linux-2.6.32.36-0.5# cat REPORTING-BUGS
[Some of this is taken from Frohwalt Egerer’s original linux-kernel FAQ]
What follows is a suggested procedure for reporting Linux bugs. You
aren’t obliged to use the bug reporting format, it is provided as a guide
to the kind of information that can be useful to developers – no more.
If the failure includes an “OOPS:” type message in your log or on
screen please read “Documentation/oops-tracing.txt” before posting your
bug report. This explains what you should do with the “Oops” information
to make it useful to the recipient.
Send the output to the maintainer of the kernel area that seems to
be involved with the problem, and cc the relevant mailing list. Don’t
worry too much about getting the wrong person. If you are unsure send it
to the person responsible for the code relevant to what you were doing.
If it occurs repeatably try and describe how to recreate it. That is
worth even more than the oops itself. The list of maintainers and
mailing lists is in the MAINTAINERS file in this directory. If you
know the file name that causes the problem you can use the following
command in this directory to find some of the maintainers of that file:
perl scripts/get_maintainer.pl -f <filename>
Leave a Reply