小菜鸟

Linux 文件系统命令详解：从磁盘配额到分区管理

在 Linux 系统中，文件系统命令用于管理磁盘空间、查看存储使用情况、配置配额限制及处理分区问题。本文将系统介绍磁盘配额配置、空间查看、分区管理等核心命令，帮助你高效管理系统存储资源。

磁盘配额管理：限制用户 / 组的存储使用

磁盘配额（Quota）用于限制用户或组对特定文件系统的存储空间或文件数量的使用，防止单个用户耗尽磁盘资源。

配额配置步骤

（1）准备文件系统

编辑 /etc/fstab，在需要设置配额的分区挂载参数中添加 usrquota（用户配额）或 grpquota（组配额）：

vi /etc/fstab
# 示例：为 /dev/sda5 启用用户和组配额
/dev/sda5  /data  ext4  defaults,usrquota,grpquota  0  0

（2）重新挂载文件系统

使 /etc/fstab 配置生效：

umount /data  # 卸载分区
mount /data    # 重新挂载（或使用 mount -a 挂载所有分区）

（3）创建配额数据库文件

在挂载目录下生成配额数据库（记录用户 / 组的存储使用情况）：

哈希冲突（Hash Collision）及解决方法详解

哈希冲突是指两个不同的键（key）通过哈希函数计算后得到相同的哈希值（hash code），导致在哈希表中映射到同一个存储位置的现象。无论哈希函数设计得多么精妙，冲突都无法完全避免，因此需要有效的冲突解决策略。本文将详细介绍常见的哈希冲突处理方法及其优缺点。

哈希冲突的本质

哈希表通过哈希函数将键映射到数组索引（index = hash(key) % capacity），但由于键的数量可能远大于数组容量，不同键必然会映射到同一索引，即产生冲突。例如：

• 键 key1 和 key2 不同，但 hash(key1) % 16 == hash(key2) % 16，则两者在容量为 16 的哈希表中冲突。

冲突处理的核心目标是：在发生冲突时，为冲突的键找到新的存储位置，同时保证后续查询、插入、删除操作的高效性。

常见的哈希冲突解决方法

1. 开放定址法（Open Addressing）

开放定址法的核心思想是：当冲突发生时，按照某种规则在哈希表中寻找下一个空闲位置，而非在原位置存储冲突数据。公式可表示为：
index_i = (hash(key) + d_i) % capacity
其中，d_i 是探测序列（决定如何寻找下一个位置），capacity 是哈希表容量。

（1）线性探测法（Linear Probing）

• 探测序列：d_i = 1, 2, 3, ..., capacity-1（每次冲突后，顺序向后查找下一个空闲位置）。
• 示例：
  若 hash(key) = 5，容量为 10，且索引 5 已被占用，则依次尝试 6、7、8… 直到找到空闲位置。
• 优点：实现简单，查找速度快（局部性原理，缓存友好）。
• 缺点：
  • 聚集效应：冲突的键会连续占用一片区域（如 5、6、7 被占用后，新键映射到 5 会继续占用 8），导致后续插入和查询效率骤降。
  • 删除困难：若删除中间元素，需标记为 “已删除” 而非直接清空，否则会断裂探测序列。

（2）二次探测法（Quadratic Probing）

• 探测序列：d_i = ±1², ±2², ±3², ...（通过平方数跳跃式查找，避免线性聚集）。
• 示例：
  若 hash(key) = 5，冲突后依次尝试 5+1=6、5-1=4、5+4=9、5-4=1…
• 优点：减少线性探测的聚集效应，冲突元素分布更均匀。
• 缺点：
  • 探测范围有限（若容量为质数，最多探测 capacity/2 次），可能找不到空闲位置。
  • 仍存在二次聚集：不同键的探测序列可能重叠（如 key1 探测 5→6→9，key2 探测 6→7→10）。

（3）双重哈希法（Double Hashing）

解决 Git 中文路径转义问题：让中文显示更友好

在使用 Git 管理包含中文文件名或路径的项目时，经常会遇到中文被自动转义为十六进制编码（如 \344\270\255\346\226\207.txt）的问题，导致 git status、git log 等命令的输出难以阅读，影响操作效率。本文将详细介绍这一问题的成因及解决方案。

问题现象

当项目中存在中文文件名（如 测试文件.txt）或中文目录（如 文档/）时，执行 git status 会看到类似以下的转义输出：

这种转义虽然不影响 Git 的功能，但会导致开发者无法直观识别文件，给 git add 等操作带来不便。

问题成因

Git 为了兼容不同操作系统和终端的字符编码，默认会对非 ASCII 字符（包括中文）进行 URL 编码转义（使用 core.quotepath 配置项控制）。该配置项的默认值为 true，即自动转义非 ASCII 路径。

解决方案：关闭路径转义

通过修改 Git 的 core.quotepath 配置，可禁用中文路径的自动转义，让中文正常显示。

1. 全局配置（推荐）

对当前用户的所有 Git 仓库生效：

使用 SCIP 求解线性规划（LP）问题

SCIP（Solving Constraint Integer Programs）是一款开源的约束整数规划求解框架，支持线性规划（LP）、整数规划（IP）、混合整数规划（MIP）等多种优化问题。它以高效性和灵活性著称，广泛应用于科研和工业领域。本文以具体示例介绍如何使用 SCIP 求解 LP 问题。

SCIP 简介

• 核心功能：求解各类约束优化问题，尤其擅长整数规划和混合整数规划。
• 支持格式：可直接读取 LP、MPS 等标准优化问题文件格式。
• 使用方式：提供命令行工具、C API 及多种语言绑定（如 Python、Java），本文重点介绍命令行使用。

问题定义与 LP 文件编写

示例问题

求解以下线性规划问题：
目标函数：maximize x₁ + 2x₂ + 3x₃ + x₄（最大化目标值）
约束条件：

1. -x₁ + x₂ + x₃ + 10x₄ ≤ 20
2. x₁ - 3x₂ + x₃ ≤ 30
3. x₂ - 3.5x₄ = 0
   变量边界：

• 0 ≤ x₁ ≤ 40
• 2 ≤ x₄ ≤ 3
• x₂, x₃ 为非负整数（通过General声明）

LP 文件格式

创建test_scip.lp文件，按 SCIP 支持的 LP 格式编写问题：

Maximize
obj: x1 + 2 x2 + 3 x3 + x4  # 目标函数：最大化x1 + 2x2 + 3x3 + x4
Subject To                  # 约束条件
c1: - x1 + x2 + x3 + 10 x4 <= 20  # 约束1
c2: x1 - 3 x2 + x3 <= 30          # 约束2
c3: x2 - 3.5 x4 = 0               # 约束3（等式约束）
Bounds                       # 变量边界
0 <= x1 <= 40                   # x1的范围
2 <= x4 <= 3                    # x4的范围
# x2、x3未声明边界，默认非负
General                      # 声明整数变量（General表示整型，binary表示二进制）
x1
x2
x3
x4
End                          # 文件结束标记

Redis ziplist（压缩列表）实现详解（基于 6.0.10 版本）

ziplist（压缩列表）是 Redis 为节省内存设计的紧凑数据结构，通过连续内存块存储数据，避免了传统链表的指针开销。它并非通过 “压缩算法” 压缩数据，而是通过紧凑布局减少内存浪费，广泛用于 Hash、List、ZSet 等数据类型的底层实现（当数据量较小时）。

ziplist 核心设计目标

• 节省内存：通过连续内存存储，消除链表节点的指针（prev/next）开销（传统双向链表每个节点需 16 字节指针）。
• 支持双向遍历：通过特殊结构设计，既支持正向遍历，也能高效反向遍历。
• 适配小数据：针对小尺寸元素（如短字符串、整数）优化，不适合存储大型数据或大量元素。

ziplist 整体结构

ziplist 由一系列连续的内存块组成，整体结构如下（单位：字节）：

+--------+--------+--------+----------------+----------------+--------+
| zlbytes| zltail | zllen  | entry 1        | entry 2        | zlend  |
| (4B)   | (4B)   | (2B)   | ...            | ...            | (1B)   |
+--------+--------+--------+----------------+----------------+--------+

各字段含义：

entry 节点结构

每个 entry 是 ziplist 的数据单元，结构如下：