1.linux磁盘分区Linux磁盘分区
2.Linux下软件包类故障排错方案详解
3.DF和Linux的命令命令缩写解析一文了解dflinux缩写
4.å¦ä½å¨Ubuntuä¸ä½¿ç¨TF/SD å¡å¶ä½Exynos 4412 u-bootå¯å¨ç
5.linux里面df-h左边一列filesystem作用是什么?
6.df命令有哪些参数?
linux磁盘分区Linux磁盘分区
在Linux磁盘分区中,与Windows的源码原理分区方式不同,Linux首先创建目录,命令命令然后将物理地址映射到这些目录。源码原理路径在Linux中从根目录开始,命令命令系统默认分为三个主要分区:boot、源码原理残风社区源码论坛swap和根分区。命令命令每个分区可以采用不同的源码原理文件系统,例如FAT、命令命令NTFS或Yaffs2。源码原理 (1) Boot分区,命令命令即/boot目录,源码原理约MB,命令命令存放Linux的源码原理启动加载器Grub和内核源代码,用户通过访问这个目录间接操作该分区。命令命令 (2) Swap分区,是虚拟内存区域,不对应任何目录,用于内存不足时临时存储数据,系统自动管理和释放。虚拟内存大小通常为物理内存的两倍。 (3) 根分区包含除/boot外的所有其他目录,用户通过访问这些目录访问根分区。充电宝免流源码 在Linux中,用户可以根据需求修改分区,例如将/home目录下的子目录挂载到不同的分区。但要注意,一块磁盘最多可以有个分区,包括1个主分区和最多个逻辑分区。在安装Linux时,通常会自动分配这三部分区,对应盘符hda1、hda2和hda3。 使用fdisk -l和df -h命令,用户可以查看和管理硬盘分区,但df命令无法显示swap分区的大小。在PC机中,A、B盘在Linux中代表hda1和hda2,而C盘类似hda3,D、E、F盘则对应于其他磁盘。 最后,如果MBR(主引导记录)损坏,大盘走势公式源码磁盘将无法作为引导盘,只能作为数据盘使用,因为MBR的位置无法通过软件修复。硬盘的其他部分损坏可以通过软件修复或跳过。扩展资料
要掌握Linux磁盘分区,先了解一下硬盘的物理结构.Linux下软件包类故障排错方案详解
软件包类故障在Linux系统中比较常见,例如:需要编译源码包程序时系统中没有安装gcc编译工具,安装RPM软件包时有未解决的依赖关系,程序库文件或头文件的安装路径不正确等,软件包类故障产生的原因非常多,通常只需要根据相应的错误提示信息,确认安装好编译环境,找到所需要的依赖软件包,纠正库文件或对应的头文件路径即可。下面主要介绍rpm数据库损坏和找不到.so文件的故障解决方法。
1、rpm数据库损坏
rpm数据库损坏的故障并不多见,出现该故障的原因一般是由于经常强制关机,误删除运行中的文件,强制替换一些rpm包文件等。rpm数据库损坏后,在使用rpm工具查询或安装软件时,电脑工具箱源码将无法正常运行。
eg:模拟rpm数据库损坏故障,并验证错误信息。
RPM作为Linux系统中的软件包管理机制,维护着一份独立的文件数据库,用于存储在系统中已安装的rpm包信息。当数据文件损坏时,将导致不能使用rpm命令或yum命令来查询、安装、升级、删除rpm类软件包。解决该故障一般只需要执行rpm --rebuilddb命令,重建数据库即可。
Ps:本系统/Linux/-/.htmã
U-Bootæºä»£ç ä¸è½½å°å /Linux/-/.htm
硬件ï¼è¿ 为iTop ç²¾è±ç & TFå¡
软件ï¼ç³»ç»èªå¸¦ç»ç«¯å³å¯
é¦å ï¼æ们åºè¯¥æ¸ æ¥TF/SDå¡å¯ä»¥çä½ä¸å¼ å®å ¨ç©ºç½çâç½çº¸âï¼ä¹æ以æååºãååºæ ¼å¼çåºå«ä¸è¿æ¯å¨å¨è¿å¼ âç½çº¸âçæäºç¹å®ä½ç½®åå ¥äºä¸äºæ°æ®æ¥æ示ååºãååºæ ¼å¼ã
å ¶æ¬¡ï¼æ们è¿åºè¯¥æ¸ æ¥ï¼å¨TF/SDå¯å¨æ¨¡å¼ä¸ï¼exynos ä¸ä¸çµï¼å é¨iROMä¼ä»TF/SDç第1个Blockï¼ç¬¬ä¸ªåèå¼å§ï¼è¯»å8KBçæ°æ®å°å é¨iRAMï¼ç¶åä»å é¨iRAMç0å°åå¼å§è¿è¡ã
åçææ¸ æ¥äºï¼é£ä¹é¦å éè¦æTF/SDä½çº§æ ¼å¼åï¼ææBlockå ¨é¨å0xã
1ãè¿æ¥TF/SDå¡ï¼æå¼ç»ç«¯
使ç¨ls /dev/sd* å½ä»¤æ¥çææè¿æ¥å°çµèä¸ç£çã
é®é¢ï¼å¨è¿é为ä»ä¹ä¸ç¨dfå½ä»¤ï¼
åå æ¯åè®¾ä½ çTFï¼SDå¡åªæä¸ä¸ªååºä½è¿ä¸ªååºå·²æåï¼æè æå¤ä¸ªååºä½æ¯æ²¡æä¸ä¸ªå¯ä»¥è¯å«çååºï¼é£ä¹æ¤æ¶dfå½ä»¤æ æ³æ¥çå°tfï¼sdå¡ï¼æ以说ç´æ¥ååºdevä¸ææsdå¼å¤´ç设å¤ï¼æ¯ç»ææ¹æ¡ã
ï¼1ï¼åè®¾ä½ çtfï¼sdå¡åªæä¸ä¸ªååºï¼æ 论è¿ä¸ªååºæ¯å¦æåï¼ç°è±¡åºè¯¥æ¯ç±»ä¼¼è¿æ ·çï¼
æä¸tfï¼sdå¡ä¹åï¼
NewImage
æä¸tfï¼sdå¡ä¹åï¼
NewImage
å¾ææ¾å¤åºç/dev/sdbå°±æ¯æ¬æåç»æä½ç对象ã
ï¼2ï¼åè®¾ä½ çtfï¼sdå¡å·²æå¤ä¸ªååºï¼æ 论è¿äºååºæ¯å¦æåï¼ç°è±¡åºè¯¥æ¯ç±»ä¼¼è¿æ ·çï¼
æä¸tfï¼sdå¡ä¹åï¼
NewImage
æä¸tfï¼sdå¡ä¹åï¼
NewImage
è¿éå¤åº5个设å¤ï¼ä½æ¯æ们ä»ç¶å°/dev/sdbä½ä¸ºæ¬æåç»æä½ç对象ã
注æï¼æè¿éæ¯/dev/sdbï¼ä½æ¯è¿æå¯è½æ¯/dev/sdcççå ¶å®ç¬¦å·ï¼å¿ é¡»æ ¹æ®ä½ å®é åºç°ç设å¤å称è¿è¡ä»¥ä¸æä½ï¼å¦åæå¯è½æåç³»ç»ååºï¼é常éè¦ï¼åè®°ï¼ï¼ï¼
2ã使ç¨è¿å¶æ¨¡å¼æå¼TFå¡æ¥çæ°æ®ï¼å¯è·³è¿ï¼
æ们使ç¨linuxèªå¸¦å½ä»¤hexdumpæ¥çtfï¼sdå¡ä¸çæ°æ®ï¼
å½ä»¤ä¸ºï¼
sudo hexdump -n /dev/sdb
å ¶ä¸-n 代表æå°åºå1Mï¼*=åèçæ°æ®ã
æ§è¡ç»æï¼é¨åï¼å¦ä¸ï¼
NewImage
ï¼ä»£è¡¨å 容为0xï¼ä¸ºäºèç空é´æ ä½çç¥ã
3ãæ¸ ç©ºTFå¡ä¸å1MBçæ°æ®
ç±äºçuboot大å°åºæ¬å¨å ç¾kBçé级ï¼æä»¥æ¸ ç©ºå1MB空é´è¶³å¤ç¨ï¼æ³¨æè¿éçæ¸ ç©ºä¸æ¯æ ¼å¼åï¼èæ¯å¡«å 0xã
æ们å©ç¨ç³»ç»/devä¸çzero设å¤ï¼æ¸ é¶tfï¼sdå¡å1MBã
æ§è¡ç»æå¦ä¸ï¼
NewImage
è¿éçcountï¼ä»£è¡¨æ¸ 空个blockï¼ä¸ä¸ªblockï¼Bï¼ä¸ªæ£å¥½ä¸º1MBã
å次hexdumpæ¥çtfï¼sdå¡æ°æ®ï¼åç°ï¼
NewImage
å1MB空é´æåæ¸ 0xã
4ãç§åubootå¯å¨æ件
å¨è¿éï¼æä»¬å¾ ç§åçæ件为 u-boot-iTOP-.bin è¿ä¸ªæ件ã
ç»ç«¯æ§è¡å½ä»¤ï¼
NewImage
if代表è¾å ¥æ件å°åï¼ä»¥ä½ u-boot-iTOP-.bin è¿ä¸ªæ件çå®é å°å为åï¼of代表è¾åºå°åï¼ä»¥ä½ tfï¼sdå¡çå®é 设å¤å·ä¸ºåã
å°è¿éï¼å°±å¯ä»¥å°tfï¼sdå¡æå ¥å¼åæ¿ä¸çµå¯å¨äºï¼ä¸ºäºè¯ææ们ç§åæ 误ï¼æ们æ§è¡åç»æä½ã
5ã确认ç§åæ£ç¡®ï¼å¯è·³è¿ï¼
æ们éè¦ç¡®å®ä»tfï¼sdå¡ç第ä¸ä¸ªblockå¼å§å¤ï¼ç¡®å®æ£ç¡®ç§åäºu-boot-iTOP-.binè¿ä¸ªæ件ï¼ä¸é¢æ们对æ¯ä¸ä¸ï¼ç¨å°çå½ä»¤åæ ·è¿æ¯hexdumpã
å¨è¿éï¼æ们为äºæ¾ç¤ºæ¹ä¾¿ï¼åªæå°å5KBæ°æ®ï¼åç°binæ件被æ£ç¡®çå¤å¶å°äºsdå¡çåèå¤ï¼
NewImage
6ãå°TFå¡æ¥å°å¼åæ¿ä¸ï¼æ¨ç å¼å ³éæ©TFå¯å¨ï¼ä¸çµï¼
NewImage
Doneã
linux里面df-h左边一列filesystem作用是什么?
在解释df命令前,需要先对mount基本操作做一下解释。一般挂载一个文件系统系统的时候我们会用命令(例如):
或者额外指定一些选项:
那mount后面的那些东西都是什么呢?ext4肯定是文件系统的类型,/dev/sda1是带有ext4文件系统ondisk结构的一个存储设备,/mnt就是挂载点(mountpoint),再后面的就是挂载选项。
对比上面的命令,我们看一下df -h的输出:
问题问最左侧一列是什么。从最左侧一列的td交易指标全源码标题我们可以看到"Filesystem",那么说这一列对应的是文件系统类型吗?看到tmpfs和devtmpfs的时候,似乎是文件系统类型。但是这一列还有诸如:/dev/sda1和/dev/mapper/fedora_xxx---root这样的设备名,这么看的话这一列似乎又不是文件系统类型名,而是设备名。
那到底最左侧一列是什么呢?有一点可以肯定的是最左侧这列肯定不是挂载点,因为很明显挂载点在最右侧"Mounted on"那列,所以所有告诉你最左侧那列是挂载点的都不要相信。
那最左侧一列到底是文件系统类型还是设备名呢?我们继续往下看。
为了更深入了解df -h最左侧一列到底是什么,我们需要了解mount系统调用的格式,我们看mount(2)的手册:
(新mount API的话可以看fsopen, fsconfig, fsmount等,没有的就看mount的就行)。
我们看到mount一个文件系统的时候有五个参数,后两个和options/flags有关(“大部分”和mount命令里-o选项后面那些有关),我们暂且不管,我们就看前三个:source, target和filesystemtype。
filesystemtype肯定是对应mount命令里面诸如“-t ext4”的选项(在不用-t选项指明文件系统类型的时候,mount命令也会尝试从设备上获取文件系统的类型)。总之这个参数没什么可讨论的,它肯定就是诸如ext4, xfs, btrfs, tmpfs等表示文件系统类型的字符串。
再看target,我觉得它也很好理解,顾名思义它就是挂载的目的地,也基本上就是mountpoint。
最后就剩下source这个参数了,我们也只剩下设备名没有对应了,那这个source就是设备名了呗?并不准确!
即使不深入内核查看mount系统调用的过程,我们也可以通过mount(2)手册描述"DESCRIPTION"的第一句话来了解个大概:
mount() attaches the filesystem specified by source (which is often a pathname referring to a device, but can also be the pathname of a directory or file, or a dummy string) to the location (a directory or file) specified by the pathname in target.
直接翻译这句话就是:mount系统调用把一个由"source"指明的文件系统附/挂在由target指明的路径上。解释这个问题的重点在一个第一个括号里!这个source通常是指向设备的路径名,但也可以是一个目录或文件的路径名,甚至可以是一个虚构的没用的字符串。
source是设备名
通常我们挂载文件系统的时候都是指定一个含有文件系统ondisk结构的设备名。
这时候我们就可以从df -h的输出中看到:
设备名对应df -h最左侧一行。
source是目录名或文件名
source除了可以是存储设备以外,还可以是目录或文件名,比如:
这时候我们得到df -h的输出是:
(为了得到bind mount的情况,我额外使用的-a选项)我们看到df最左侧并不是/etc,而是/dev/mapper/fedora_xxx-root。这其实和bind原理有关,因为/etc在fedora_xxx-root所含的文件系统上,所以这里直接显示为/dev/mapper/fedora_xxx-root。
其实通过findmnt可以看到bind的关系:
findmnt给出了mount source是/etc。
source是虚设的名字
第三种情况就是dummy name的情况,在挂载诸如tmpfs, proc这样的文件系统的时候,由于这些文件系统只存在于内存中,所以它们不需要指定设备名或文件名之类的,因为文件系统类型(filesystemtype)已经可以足够表明要挂载的文件系统对象了。这时候source这个参数就显得有些没用了,这种情况我们允许source可以是随便一个名字,比如:
这时候-t proc和-t tmpfs已经足够指定我们要挂载的文件系统了,所以后面我们随便起了个名字,比如myproc和mytmp。这时候我们得到df -h的输出如下:
可以看到我们所用的dummy name出现在了df -h输出的最左侧一列。也就是说此时最左侧一列是虚设的字符串,是挂载的时候随便起的名字。你可以随便起一个你觉得合适的能起到提示作用的名字,而一般人将这个名字起的和文件系统名一样,所以你才会看到诸如:
这样的输出,其实最左侧一列并不非得是文件系统的名字,只是挂载的时候故意将source设置为这样的名字而已。
推测结论
到此我相信很多人应该已经可以猜到df -h最左侧一列到底是什么了,它并不是文件系统类型,更不是挂载点,而是基本上和mount系统调用的source参数相对应。一般来说是文件系统所在的设备的名字,同时也可以是一个虚设的名字,而一般习惯将这个虚设的名字设置为和文件系统类型同名。
验证
作为开源软件,没有什么比源代码更有说服力。虽然我认为上面的结论已经很站得住脚了,但是代码就放在那,不打开看一把真是愧对程序员这三个字。下面我们就粗略的看一下df.c的代码:
df这个命令的源程序就在GNU的coreutils这个项目里,可以通过下面的途径获得源代码:
拿到代码后我们迫不及待的找到df.c文件开始翻看。在省略掉大量翻阅细节后,我在df.c:main()函数里找到了和获取挂载信息有关的一段代码:
这个read_file_system_list就是我们下面要看的一个函数,它不在df.c里,而是在gnulib/lib/mountlist.c文件里。因为不止df命令需要获取mountlist,很多其它命令也有需要获取mountlist的时候(比如mount -l),所以获取mountlist就作为了一个库函数。这个函数比较长,我截取一小部分:
大概的意思就是从/proc/self/mountinfo这个文件中获取mountlist(或退回使用老方法)。通过 Linux/Documentation/filesystems/proc我们可以找到/proc/self/mountinfo的格式:
这里也提到了mount source,而read_file_system_list()代码中我们看到这里将source和me_devname关联到了一起,而me_devname又和dummy关联到了一起。所以一切都指向source。
再回过头看df.c,它在main函数得到通过read_file_system_list()函数得到mount_list(包括me_devname)后调用了get_all_entries。而这个get_all_entries就是通过get_dev把mount_list遍历一遍:
这里我们看到me_devname给了get_dev的第一个参数:
get_dev的第一个参数device又给了dev_name变量,最后dev_name变量和SOURCE_FIELD这个输出关联了起来。那这个SOURCE_FIELD又和什么有关联呢?从df.c中我们找到了:
关键字“Filesystem”这个title就和SOURCE_FIELD关联了起来。
想想df -h的输出最左侧一列的tile是什么?就是这个"Filesystem"。
这样一切都串联了起来df -h调用read_file_system_list从/proc/self/mountinfo得到mount list信息,将mount list中的mount source和mount_entry的me_devname关联起来,后通过get_all_entries和get_dev将这个me_devname(也就是mount source)打印在“Filesystem”这列的下面,作为了df -h最左侧的输出。
知识还是要求甚解,不要你觉得,要现实逻辑觉得,要事实依据觉得。
df命令有哪些参数?
df -h命令代表什么意思呢?我们一起了解一下吧!
df -h是df命令加上参数h,日常普遍用该命令可以查看磁盘被占用了多少空间、还剩多少空间等信息。
Linux 是一种自由和开放源码的类 UNIX 操作系统。df命令是Linux命令之一,df命令的英文全称即“Disk Free”,顾名思义功能是用于显示系统上可使用的磁盘空间,默认显示单位为KB。“df -h”命令的参数组合,是可以根据磁盘容量自动变换合适的容量单位,更利于阅读和查看。
参考实例:
[root@linux ~]# df -h
文件系统 容量 已用 可用 已用% 挂载点
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 2.0G 1.1M 2.0G 1% /run
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/mapper/fedora_linuxhell-root G 2.0G G % /
tmpfs 2.0G 4.0K 2.0G 1% /tmp
/dev/sda1 M M M % /boot
tmpfs M 0 M 0% /run/user/0
显示的单词分别代表的具体含义如下。
Filesystem:表示该文件系统位于哪个分区,因此该列显示的是设备名称;
Used:表示用掉的磁盘空间大小;
Available:表示剩余的磁盘空间大小;
Use%:磁盘空间使用率;
Mounted on:文件系统的挂载点,也就是磁盘挂载的目录位置
Filesystem:表示该文件系统位于哪个分区,因此该列显示的是设备名称;
Used:表示用掉的磁盘空间大小;
Available:表示剩余的磁盘空间大小;
Use%:磁盘空间使用率;
Mounted on:文件系统的挂载点,也就是磁盘挂载的目录位置。
关于df -h命令,我们就了解到这啦!
2024-12-24 10:38
2024-12-24 10:28
2024-12-24 10:17
2024-12-24 09:07
2024-12-24 09:03
2024-12-24 09:02
2024-12-24 08:51
2024-12-24 08:48