在 Proxmox VE 中将 /var/lib/vz 挂载到独立 LVM 磁盘并实现启动容错

在 Proxmox VE(PVE)环境中,/var/lib/vz 是一个非常关键的目录,用于存放虚拟机磁盘、CT 容器、ISO 镜像、模板以及部分备份数据。如果该目录与系统盘混用,一旦发生磁盘故障,既可能影响虚拟化数据,也可能拖垮整个宿主机系统。 一种更加专业和稳健的做法,是将 /var/lib/vz 单独放在一块独立磁盘上,并使用 LVM(Logical Volume Manager)进行管理,同时设置为“即使磁盘缺失也不阻断系统启动”。 本文将完整介绍这种架构的设计思路与实现方式。 一、设计目标 该方案的目标是: 最终结构如下: 二、创建 LVM 磁盘结构 假设新磁盘为 /dev/sdb。 1. 初始化为物理卷 2. 创建卷组 3. 创建逻辑卷(占满磁盘) 三、创建文件系统 可以使用 ext4 或 xfs,这里以 ext4 为例: 四、迁移原有 /var/lib/vz 数据 1. 临时挂载新磁盘 2. 拷贝数据(保留权限与属性) 五、正式替换挂载点 确认挂载: 六、配置开机自动挂载(容错模式) 获取 UUID: 编辑 /etc/fstab: 添加一行: 这行配置的意义 …

日本「源泉徴収票」中各金额项目的真实含义与计算关系

在日本工作后,每年年底或离职时,公司都会发放一张名为 「給与所得の源泉徴収票」 的文件。这张表是日本税务系统中最重要的个人收入证明之一,既用于报税,也用于银行、签证、入籍等正式场合。 这张表里有几个看起来很相似、但含义完全不同的金额栏目,如果理解错误,很容易误判自己有没有被“多扣税”或“少扣税”。 本文用结构化方式说明这些金额之间的真实关系。 一、金额的整体结构(从“工资”到“税基”的路径) 源泉徴収票里的金额不是随便排列的,而是按日本税法的计算流程排列的: 也就是说,它描述的是一条 “工资 → 税务认定收入 → 可扣除 → 实际课税 → 已预扣税” 的完整路径。 二、支払金額(支付金额) 含义: 公司一年中实际支付给员工的全部工资总额(税前) 包括: 这是现实中的“赚到的钱”,但它 不是用来直接算税的数字。 三、給与所得控除後の金額(扣除工资所得控除后的金额) 这是整个日本工资税制度里最容易被误解的一项。 1. 什么是「給与所得控除」? 日本对工资收入者设定了一种 自动的标准扣除,叫「給与所得控除」。 它的本质是: 国家默认“上班的人一定有通勤、服装、生活等成本”,所以先给你扣一块,再算你有多少钱可以被视为“真正的收入”。 这个扣除: 2. 那「給与所得控除後の金額」是什么? 这是: 支払金額 − 工资所得控除 它不是“免税额”,它是税务上承认你“赚了多少钱”的起点。 这个数: 四、所得控除の額の合計額(所得扣除总额) 这是真正决定你交不交税的核心栏位。 它表示: 从“税务认定收入”中,国家允许你再减掉的各种免税额度总和。 常见包含: 这个数字越大,你最后要交税的那一块就越小。 五、为什么“扣除合计”可以比收入还大? 很多人会发现: 所得控除合计 …

日本常见的蛋糕类型整理

在日本的蛋糕店或便利店里,经常能看到各种片假名命名的蛋糕,比如:ショートケーキ、シフォンケーキ、モンブラン、ロールケーキ、チーズケーキ等。这些名字并不是随意起的,而是对应不同的制作方法和口感类型。 下面按日本日常使用方式,把常见蛋糕做一个系统整理。 一、以海绵蛋糕为基础的类型 这是日本最常见的一类蛋糕。 ショートケーキ(鲜奶油草莓蛋糕) 最典型的日式蛋糕。结构是:海绵蛋糕 + 鲜奶油 + 草莓。在日本,单独说「ケーキ」,很多情况下指的就是这种。 シフォンケーキ(戚风蛋糕) 用大量蛋白打发,几乎不使用黄油。特点是轻、松、干净,不油腻,常见为中间有孔的圆形蛋糕。 ロールケーキ(瑞士卷) 将薄海绵蛋糕卷入鲜奶油。日本的卷蛋糕通常追求蛋糕体柔软、奶油比例高。 二、巧克力类蛋糕 ガトーショコラ 以巧克力为主体的烤制蛋糕,口感比普通海绵蛋糕更湿润厚实。 ショコラケーキ 指用可可蛋糕胚和巧克力奶油叠加做成的层状蛋糕。 テリーヌショコラ 偏向浓稠巧克力点心,介于巧克力与蛋糕之间。 三、栗子和泥状装饰蛋糕 モンブラン 底部是蛋糕或蛋白饼,中间是奶油,外面挤上栗子泥。除了栗子,也有抹茶、紫薯等变体。 四、派和塔类 タルト 饼底 + 奶油馅 + 水果或巧克力。口感偏向酥脆。 パイ 如苹果派、奶油派等,以多层酥皮为特点。 五、芝士蛋糕 日本的芝士蛋糕分类比较细: 类型 日文 轻乳酪 スフレチーズケーキ 重乳酪 ベイクドチーズケーキ 生乳酪 レアチーズケーキ 巴斯克 バスクチーズケーキ 它们在口感和制作方式上差异很大。 六、日式风味蛋糕 在西式蛋糕基础上加入日式口味,例如: 结构仍是西式蛋糕,但风味偏向和式甜点。 总结 …

用命令行在 Linux 下启用并查看 USB 摄像头画面

在 Linux 桌面环境之外,直接用命令行控制和查看 USB 摄像头是一种非常高效、可控且可自动化的方式。无论是用于测试硬件、搭建服务器视频流、远程监控,还是排查驱动问题,V4L2 + FFmpeg 体系都是最稳定可靠的方案之一。 本文将完整介绍如何在 Linux 下,用命令行列出摄像头、识别正确设备,并以最佳参数输出画面。 一、Linux 摄像头的基本结构 Linux 中所有视频采集设备都通过 V4L2(Video4Linux2) 暴露为: 一个物理摄像头通常会暴露 两个或多个 video 节点: 如果选错节点,画面可能会黑屏、只有低分辨率,或者无法打开。 二、列出系统中所有摄像头 首先查看当前存在的 video 设备: 然后用 V4L2 查询设备归属: 示例输出结构如下: 同一组下面的两个 /dev/videoX 就属于同一个物理摄像头,其中 第一个通常是主视频流。 三、查看摄像头支持的格式和分辨率 确定主设备后(例如 /dev/video5),查询它的能力: 通常可以看到类似: 这里可以看出一个关键事实: MJPG 才是高分辨率高帧率的正确模式YUYV 在高分辨率下通常帧率极低 四、用 ffplay 直接显示画面 推荐使用 FFmpeg 自带的 ffplay: 2K(2560×1440 …

在 ext4 损坏后将 Raspberry Pi 系统从 64GB SD 卡无损迁移到 8GB SD 卡

摘要 在 Raspberry Pi 上运行 Ubuntu 或 Raspberry Pi OS 时,如果发生异常断电或 SD 卡老化,常会导致 ext4 文件系统元数据损坏,表现为启动进入 initramfs、fsck 报错、甚至出现异常输出(如大量负数刷屏)。当系统仍可启动时,最佳做法不是继续在原卡上修复,而是将当前系统整体迁移到一张健康的新存储介质。 本文记录了一次真实的灾难恢复流程:在原 64GB SD 卡发生 ext4 元数据错误后,将系统无重装迁移到一张 8GB 新 SD 卡,并保证系统可以从新卡稳定启动。 问题背景 系统在一次强制断电后启动失败,进入 initramfs,并提示: 执行 fsck 后虽然可以重新启动,但内核日志中出现: 这类错误并非单纯 journal 未回放,而是 ext4 从底层存储读到了不一致的数据,说明原 SD 卡已经出现 silent corruption(隐性数据损坏)。 此时继续在原卡上使用会导致未来随机文件损坏,因此必须迁移系统。 目标 环境 1. 对新 SD 卡重新分区 在 …