文章目录
参考文章系列
shell三种登录模式
1. 登录shell模式
用户通过ssh /tty 方式(ctrl+alt+F1…F7)等登录方式登录的模式
特点
1. 会加载 /etc/profile 中的代码块
2. 在之前的基础上依次加载登录用户home目录中的 /home/.bash_profile(.bashrc)(.bash_login)(.profile) 文件定义的变量与函数
2. 交互式shell模式
在登录模式内(用户登录状态下)，用户使用bash命令或者在GUI等桌面情况下创建的terminal,此时会继承当前登录shell模式下的变量.
特点
1. 不加载 /etc/profile代码块,意味着即使在当前交互式shell模式下修改了/etc/profile中暴露的变量,也不会在新创建的交互式shell模式中显示新的被修改结果,如果要使修改之后的变量生效,有两种方法
a) 临时生效
宏方法(C++ 中的内联函数/#define)
source /etc/profile
b) 永久生效
重新新建一个登录模式的terminal,或者重启
2. 很显然,会加载 /home/$USER/.bash_profile(.bashrc)(.bash_login)(.profile) 中的代码块, 而且每次新建交互式shell模式都会加载这些文件,因此,在这些模块中修改暴露的变量
３. 非交互式shell模式
运行可执行文件所处的状态，可以理解为 无提示符的模式
后台进程 (daemon)
通过 top 查看被挂起的进程ip
普通命令转换为后台进程的方式
-
通过 &指定
并通过jobs查看，但是一旦退出当前会话（shell），进程就会结束，这样也好理解
-
通过nohup 。。。 & 指定
通过nohup 是忽略（免疫）挂断信号的，也就是说当以远程terminal连接到服务器的时候，通过nohup 执行一条命令，即使当前会话被各种原因（人为。网络环境）掐断了，nohup说包裹的命令也不会接收到挂断信号，也就不会停止了
# man nohup
NAME
nohup - run a command immune to hangups, with output to a non-tty
执行一条免疫挂断的命令，不在普通的tty终端输出结果
SYNOPSIS
nohup COMMAND [ARG]...
nohup OPTION
DESCRIPTION
Run COMMAND, ignoring hangup signals.
忽略挂断信号
子shell (非后台)(child shell 也叫 subshell这两者是等价的)
进入子shell的三种方式
$1 (ls;pwd;echo $BASH_SUBSHELL)(进程列表)
$2 coproc sleep 10 (协程)
$bash (/bin/bash启动命令)
特点
1. 子shell无法修改全局变量的值,但是会继承父shell暴露的全局变量
无论是修改,删除(unset)变量都不会影响父shell中暴露的变量,但是会影响子shell进程,毕竟子shell是通过父shell继承的
$ my_var="I am"
$ export my_var
$ bash
$ my_var="I am sub"
$ echo $my_var
I am sub
$ exit
$ echo $my_var
I am
2. 子shell同样不会获取父进程的局部变量
这个与一般的高级语言中有些出入,不过也好理解,在子shell中意味这是被开辟一个新的进程用来执行代码段的,不过在开辟新进程的时候会继承父进程所暴露(export)的变量.但不会传递父进程的局部变量(没有export的变量)
3. BASH_ENV 环境变量
默认情况下 BASH_ENV是没有设置的,所以很多用户也不会去关注它,但是它的存在,为一些实际情况提供了便利
比如,有些变量不想暴露给登录模式／交互式模式，只是想在非交互式环境中能使用的变量，那么设置BASH_ENV就非常有意义
环境变量什么时候加$ ,什么时候不需要
在想要获取值的场景加$,而操作变量的时候不用
文件管理系统
文件类型
ext
extended system 在基本的unix文件系统的基础上做的一个扩展
扩展的内容
- 文件名
- 文件大小
- 文件的属主
- 文件的属组
- 文件的访问权限
- 指向存有文件数据的每个硬盘块的指针
该系统核心之一时使用索引节点号来标志文件（搜索，查找，删除等等，都是通过这个id，该id存在内核中的索引节点表中）
ext2
在ext基础上扩展
k扩展内容
- 支持文件大小 由ext（2g） 到 2T (32T)进发，适用于数据库的存储
- 按组分配磁盘，优化ext（磁盘碎片导致搜索性能降低）
缺点
如果计算机系统在存储文件和更新索引节点表之间发生了什么，这二者的内容就不同步了。
ext2文件系统由于容易在系统崩溃或断电时损坏而臭名昭著。即使文件数据正常保存到了物理设备上，如果索引节点表记录没完成更新的话，ext2文件系统甚至都不知道那个文件存在！
元数据就是保存在索引节点表中
日志服务系统
在hbase中也有相关的思想 wal
其扩展了 ext2
原理
在文件更改写入临时文件（journal），等到文件成功写入磁盘中，再删除临时文件
根据写入临时文件的数据类型分为
表8-1 文件系统日志方法
方 法 描 述
数据模式 索引节点和文件都会被写入日志；丢失数据风险低，但性能差
有序模式 只有索引节点数据会被写入日志，但只有数据成功写入后才删除；在性能
和安全性之间取得了 良好的折中
回写模式 只有索引节点数据会被写入日志，但不控制文件数据何时写入；丢失数据风险高，但仍比不用 日
ext3
默认为有序模式，折中方案，可以通过命令修改日志模式
ext4
在ext3的基础上添加，加密，压缩，误删恢复等等功能
- Reiser文件系统 ===> 只支持回写日志模式
- JFS 文件系统 ===> 有序日志模式
- XFS 文件系统 ===> 系统采用回写模式的日志
写时复制文件系统 copy-on-write，COW
特点：
在修改文件的时候，只是在另一块磁盘中添加修改的记录，并不覆盖原有数据，在合适的时间进行合并？？
B tree 节点可删可增加
Btrf文件系统
能够动态调整已挂载文件系统的大小
操作文件系统实战
核心指令 fdisk 分盘
# fdisk -l
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 1832AEB2-F335-4847-8271-1E2C04174EED
Device Start End Sectors Size Type
/dev/sda1 2048 1050623 1048576 512M EFI System
/dev/sda2 1050624 1936914431 1935863808 923.1G Linux filesystem
/dev/sda3 1936914432 1953523711 16609280 7.9G Linux swap
目前系统有三个分区
进入sda2分区中
homewell:/home/hadoop/shareh/abcd$ sudo fdisk /dev/sda2
[sudo] password for homewell:
Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
/dev/sda2: device contains a valid 'ext4' signature; it is strongly recommended to wipe the device with wipefs(8) if this is unexpected, in order to avoid possible collisions
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x6508267c.
主分区
系统直接格式化的分区
默认一个分区中如上面的sda2分区中，只有4个主分区
所以再进行划分的时候想要多于4个分区，那么，至少其中一个是扩展分区，用来扩展逻辑上的分区
扩展分区
用来支持逻辑分区的分区，在扩展分区中可以定义多个扩展分区
缺点肯定是性能不好啊，要多绕几个弯才能找到数据
常用的fdisk 命令
m => 查看相关指令
l => 查看相关文件系统格式及其标志码
p => 查看当前分区的情况，是否有分区，分区的情况
n => 创建一个新分区，并根据提示依次创建 分区类型，大小，
w => write 保存退出
查看系统支持的系统文件类型
homewell:/home/hadoop/shareh/abcd$ type mkefs
-bash: type: mkefs: not found
homewell:/home/hadoop/shareh/abcd$ type mke2fs
mke2fs is /sbin/mke2fs
homewell:/home/hadoop/shareh/abcd$ type mkfs.ext3
mkfs.ext3 is /sbin/mkfs.ext3
homewell:/home/hadoop/shareh/abcd$ type mkfs.ext4
mkfs.ext4 is /sbin/mkfs.ext4
homewell:/home/hadoop/shareh/abcd$ type mkreiserfs
-bash: type: mkreiserfs: not found
homewell:/home/hadoop/shareh/abcd$ type jfs_mkfs
-bash: type: jfs_mkfs: not found
homewell:/home/hadoop/shareh/abcd$ type mkfs.xfs
-bash: type: mkfs.xfs: not found
homewell:/home/hadoop/shareh/abcd$ type mkfs.zfs
-bash: type: mkfs.zfs: not found
homewell:/home/hadoop/shareh/abcd$ type mkfs.btrfs
-bash: type: mkfs.btrfs: not found
启动直接挂载磁盘
核心文件 /etc/fstab
默认分区之后需要
# mount -t ext4 /dev/sdba /home/someplace
此系统重启之后是不会自动挂载的
需要在核心文件中挂载磁盘
homewell:/home/hadoop/shareh/abcd$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=aef31698-9b53-4c50-9148-1eacc2f14ce8 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=F934-6BE1 /boot/efi vfat umask=0077 0 1
# swap was on /dev/sda3 during installation
UUID=0317d445-f233-46a1-b89a-a5a57ff262d6 none swap sw 0 0
文件修复
计算机不是万能的,她也有脆弱的时候,一旦断电或者程序出现问题,会有一定的小概率出现数据损坏,如何修复是一件很头痛的事情,不过有这么一个前端脚本命令(fsck)能够根据系统分配的唯一的分区id(UUID),来对其上的块的类型做修复
前提是要umount才能修复
逻辑卷管理
一般，要对磁盘进行扩容，不得不先copy一份数据到新的大磁盘中，然后再挂载,这样太麻烦
但是在逻辑卷管理的世界中，不必这么麻烦.
在其中的有两大非常重要的概念
逻辑卷(LV)
在物理世界中相当于物理磁盘分区(C盘,D盘,E盘等等)
是逻辑卷管理系统管理的单位
特点
因为是逻辑的,所以可以跨磁盘 ,以不同磁盘上的物理分区同时加载到一块逻辑卷中
卷组 (VG)
逻辑卷的组合,也就是卷组.在逻辑卷管理系统中,对待卷组相当于操作系统对待一块物理磁盘.
也就是说多个逻辑卷一起组成一块卷组.逻辑卷管理系统在逻辑上动态管理添加逻辑卷,并把它加入卷组中,而不必像物理磁盘那样换一块新的大磁盘.