讀指定物理扇區：
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>