文章目錄
參考文章系列
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)
邏輯卷的組合,也就是卷組.在邏輯卷管理系統中,對待卷組相當於操作系統對待一塊物理磁盤.
也就是說多個邏輯卷一起組成一塊卷組.邏輯卷管理系統在邏輯上動態管理添加邏輯卷,並把它加入卷組中,而不必像物理磁盤那樣換一塊新的大磁盤.