文件系统结构

# 查配置
/etc/nginx/          # Nginx 配置
/etc/systemd/system/ # systemd 服务文件
/etc/ssh/sshd_config # SSH 服务端配置
/etc/fstab           # 开机自动挂载表

# 查日志
/var/log/syslog      # 系统主日志（Debian/Ubuntu）
/var/log/messages    # 系统主日志（RHEL/CentOS）
/var/log/auth.log    # 认证日志（登录、sudo 记录）
/var/log/nginx/      # Nginx 日志

# 查运行时状态
/proc/cpuinfo        # CPU 详细信息
/proc/meminfo        # 内存信息
/proc/loadavg        # 系统负载
/var/run/            # PID 文件在这（或 /run/）

# 临时文件
/tmp/                # 注意：不要放重要数据

# 查看 CPU 信息
cat /proc/cpuinfo | grep "model name"

# 查看系统启动了多久
cat /proc/uptime

# 查看进程信息
ls /proc/          # PID 为名的目录就是进程的信息
cat /proc/1234/cmdline  # 进程 1234 的启动命令
cat /proc/1234/status   # 进程 1234 的状态和内存使用

# 绝对路径：写脚本/配置文件时必须用——不依赖"当前在哪"
cat /etc/nginx/nginx.conf       # 不管在哪个目录，都能正确读取

# 相对路径：日常交互时省敲键
cd /var/log                     # 先到日志目录
less syslog                      # 相对路径，省去 /var/log/syslog

cd ../../home/alice             # 向上两级再到 alice 家目录

inode 编号 (inode number)
文件类型 (普通文件/目录/链接...)
权限  (rwxr-xr-x)
UID / GID（所有者/所属组）
文件大小  (字节数)
时间戳：
  - atime：最后访问时间
  - mtime：最后修改内容时间
  - ctime：最后修改元数据时间
链接数 (link count)
数据块指针：指向真正存数据的磁盘块

# -i 显示 inode 编号
ls -li /etc/passwd
# 输出：1234567 -rw-r--r-- 1 root root 2540 Jan 1 12:00 /etc/passwd
#       ^ inode号

# 查看 inode 使用情况
df -i
# Filesystem     Inodes IUsed IFree IUse% Mounted on
# /dev/sda1      655360 45321 610039    7% /

# 准备一个普通文件（link count = 1）
echo "hello" > test.log

# 当文件没有被任何进程打开：
rm test.log
  → 1. 删除目录项（文件名消失）
  → 2. inode 的 link count 从 1 变成 0
  → 3. 内核释放 inode 和对应的数据块

# 当文件被进程打开时：
> app.log                # 假设有进程正在写这个文件
rm app.log               # 文件名消失了
ls -l app.log            # 显示：No such file or directory
df -h                    # 但磁盘空间没有释放！

# 为什么？因为进程还持有文件句柄（file handle）
# inode 的 link count 变 0，但 open count 不是 0
# inode 和数据块会保留到进程关闭文件才真正释放

df -h
# /dev/sda1       50G   50G   0  100% /     ← 磁盘满了

du -sh /* | sort -rh | head
# 加起来才 30G，那 20G 去哪了？

# 真相：有进程持有已删除文件
lsof | grep deleted | awk '{print $1, $7}' | sort -nrk2 | head
# mysqld    1052672000   ← MySQL 还在写一个已删除的日志
# java      524288000    ← Java 写一个已删除的日志

# 解决方法：重启对应进程（不推荐直接杀）
systemctl restart mysqld   # 重启后空间就回来了

# 创建硬链接
ln source.txt hard_link.txt

# 创建软链接（符号链接）
ln -s source.txt soft_link.txt

# 查看
ls -li
# 12345 -rw-r--r-- 2 user group  0 Jul  1 10:00 hard_link.txt   ← inode=12345, link count=2
# 12345 -rw-r--r-- 2 user group  0 Jul  1 10:00 source.txt       ← 同一个 inode!
# 67890 lrwxrwxrwx 1 user group 10 Jul  1 10:00 soft_link.txt -> source.txt
#       ↑ 类型是 l（link），inode 不同，大小是"目标路径名长度"

# 软链接：给长路径起个短名
ln -s /opt/application-v3.2.1-current /opt/app
cd /opt/app   # 实际进到 /opt/application-v3.2.1-current

# 软链接：版本切换（滚动更新）
rm /opt/app
ln -s /opt/application-v3.2.2-current /opt/app  # 一键切版本

# 硬链接：备份保护
ln important_file important_file.backup
# 即使有人 rm important_file，数据还在（link count > 0）

# 软链接：配置文件管理
ln -s /etc/nginx/sites-available/myapp.conf /etc/nginx/sites-enabled/
# Nginx 只加载 sites-enabled 下的配置

# 软链接要注意相对路径陷阱
ln -s ../config/app.conf /etc/myapp/link_app.conf
# 软链接里存的是字面字符串；解析时相对「软链接自己所在的目录」(/etc/myapp/)，
# 而不是你的当前目录——这里实际指向 /etc/config/app.conf。
# 坑在于：数 .. 要从软链接的位置数（容易数错），且一旦软链接被移动，目标就跟着错位

# 建议：创建软链接时目标用绝对路径
ln -s /opt/app/config/app.conf /etc/myapp/link_app.conf  # 安全

# 查看软链接的真正目标
readlink /etc/myapp/link_app.conf      # 显示目标路径
readlink -f /etc/myapp/link_app.conf   # 递归解析到最终绝对路径

# Step 1：确认告警
df -h /data
# /dev/sdb1       100G   98G  2G  98% /data

# Step 2：定位大户
du -sh /data/* 2>/dev/null | sort -rh | head -5
# 52G     /data/mysql
# 18G     /data/logs
# 5.2G    /data/backup
# ...加起来才 75G，98G - 75G = 23G 去哪了？

# Step 3：查是不是"已删文件句柄没释放"
lsof +L1 /data  2>/dev/null | awk '{print $1, $2, $7}' | sort -nrk3 | head
# java      12345   15032385536    ← 一个 14G 的已删除文件！
# syslog-ng  8876    8589934592   ← 一个 8G 的已删除日志！

# Step 4：确认是哪个进程
ps aux | grep 12345
# appuser   12345  5.2  ... java -jar /data/app.jar

# Step 5：通知开发/业务方，重启对应的进程
systemctl restart myapp

# Step 6：确认释放
df -h /data
# /dev/sdb1       100G   75G  25G  75% /data   ← 恢复