你觉得,你的系统中大多数文件大概有多大?

这是一个很有意思的问题,你可以试着先猜一下。

基于对系统中保存文件的了解,可能有这样的思考过程:

  • 我收藏了好多照片,每个有 2~5MiB 吧。
  • 我下载了好多漫画,每个 100KiB 左右,这些大概占了不少比例。
  • 我还收藏了不少动画电影电视剧,虽然这些文件总数量可能不多?
  • 我下载了 Linux 的源码,那里面每个 C 代码文件都几千行,每行 100 字宽,平均也得有 30KiB 吧,有几万个源码文件呢,占比应该挺大的……

问题中「大多数」其实是个挺不精确的称呼,换个精确点的问法:你觉得你的系统中 文件大小的中位数 大概在什么范围内?或者说,文件系统中 文件大小的分布情况 一般是怎样的曲线?

这个问题其实还有多种别的问法,比如:一个常见的桌面或者服务器系统中,多大的文件算大文件, 多小的文件算小文件,什么范围内的大小算是普通呢?

经历过基本的科学教育的人 …

上篇 「柱面-磁头-扇区寻址的一些旧事」 整理了一下我对磁盘类存储设备(包括软盘、硬盘,不包括光盘、磁带)的一些理解, 算是为以后讨论文件系统作铺垫;这篇整理一下我对闪存类存储设备的理解。

这里想要讨论的闪存类存储是指 SSD 、SD卡、U盘、手机内置闪存等基于 NAND 又有闪存转换层的存储设备(下文简称闪存盘),但不包括裸 NAND 设备、3D Xpoint (Intel Optane)等相近物理结构但是没有类似的闪存转换层的存储设备。 闪存类存储设备这几年发展迅猛,SD卡和U盘早就替代软盘成为数据交换的主流, SSD 大有替代硬盘的趋势。 因为发展迅速,所以其底层技术变革很快,不同于磁盘类存储技术有很多公开资料可以获取, 闪存类存储的技术细节通常是厂商们的秘密,互联网上能找到很多外围资料, 但是关于其如何运作的细节却很少提到。所以我想先整理一篇笔记,记下我搜集到的资料,加上我自己的理解。 本文大部分信息来源是 Optimizing Linux with cheap flash drivesA Summary on …

在 SSD 这种新兴存储设备普及之前,很长一段时间硬盘是个人计算机的主要存储设备。 更往前的磁带机不常见于个人计算机,软盘的地位很快被硬盘取代,到 SSD 出现为止像 MiniDiscDVD-RAM 等存储设备也从未能挑战过硬盘的地位。硬盘作为主要存储设备,自然也影响了文件系统的设计。

这篇笔记稍微聊一聊硬盘这种存储设备的寻址方式对早期文件系统设计的一些影响,特别是 柱面-磁头-扇区寻址(Cylinder-head-sector addressing, 简称CHS寻址)的起源和发展。 大部分内容来自维基百科 Cylinder-head-sector 词条 这里只是记录笔记。现今的硬盘已经不再采用 CHS 寻址,其影响却还能在一些文件系统设计中看到影子。

柱面、磁头、扇区以及相关术语

磁盘示意图(来自维基百科 Cylinder-head-sector 词条
chs-illustrate-trans.svg

如右图所示,一块硬盘(Hard Disk Drive, HDD)是一个圆柱体转轴上套着一些磁碟片(platter), 然后有一条磁头臂(actuator arm)插入磁碟片间的位置 …

zfs 这个东西倒是名不符实。叫 z storage stack 明显更符合。 叫 fs 但不做 fs 自然确实会和 btrfs 有很大出入。
我反而以前还好奇为什么 btrfs 不弄 zvol , 直到我意识到这东西真是一个 fs ,名符奇实。
—— 某不愿透露姓名的 Ext2FSD 开发者

Btrfs 和 ZFS 都是开源的写时拷贝(Copy on Write, CoW)文件系统,都提供了相似的子卷管理和 快照(snapshot)的功能。网上有不少文章都评价 ZFS 实现 CoW FS 的创新之处,进而想说「 Btrfs 只是 Linux/GPL 阵营对 ZFS …

2020年2月9日更新过

ZFS 在设计之初源自于 Sun 内部多次重写 UFS 的尝试,背负了重构 Solaris 诸多内核子系统的重任,从而不同于 Linux 的文件系统只负责文件系统的功能而把其余功能(比如内存脏页管理, IO调度)交给内核更底层的子系统, ZFS 的整体设计更层次化并更独立,很多部分可能和 Linux/FreeBSD 内核已有的子系统有功能重叠。

似乎很多关于 ZFS 的视频演讲和幻灯片有讲到子系统架构,但是找了半天也没找到网上关于这个的说明文档。 于是写下这篇笔记试图从 ZFS 的早期开发历程开始,记录一下 ZFS 分层架构中各个子系统之间的分工。 也有几段 OpenZFS Summit 视频佐以记录那段历史。

早期架构

早期 ZFS 在开发时大体可以分为上下三层,分别是 ZPL, DMU 和 SPA ,这三层分别由三组人负责。

最初在 Sun 内部带领 ZFS …

惠狐 megumifox 写了篇 用PulseAudio将电脑的声音用手机放出来 ,文末提到想知道我怎么用树莓派转发 USB 的,于是写篇文章记录一下。

起因

家里有个装了 Arch Linux ARM 的树莓派3B 闲置着,装了 Arch Linux ARM 偶尔上电更新一下, 不过因为性能实在不适合做别的事情于是一直在吃灰。某日 给老婆安利幻想万华镜和老婆看片 的时候, 老婆不吃安利于是迁怒键盘鼠标键盘鼠标被长长的 USB 线扯着感觉很难受 ,于是偶发奇想,能不能利用一下树莓派的多达 4 个 USB 2.0 端口接鼠标键盘呢, 这样鼠标键盘就可以跟着树莓派来回走,不用拖着长长的 USB 线了。

上网搜了一下, Linux 环境有个 usbip 工具正好能做到这个。原理也很直观, usbip 能把 USB …

译注

这篇是翻译自 Brandon Invergo 的博客的英文文章 Using GNU Stow to manage your dotfiles 。 Brandon Invergo 的博客采用 CC-BY-SA 3.0 授权,因此本文也同样采用 CC-BY-SA 3.0 ,不同于其它我写的文章是 CC-BY-NC-SA 4.0 授权。

我自己已经使用此文中介绍的方案管理 我自己的 dotfiles 快 3 年了。最早想采用这样的管理方案是为了方便在多台 Arch Linux 系统之间同步配置, 后来逐渐主力系统也更新换代了一次,又同步到了自己的 vps 上去,目前管理多个 Arch Linux 上都多少都有这套配置。甚至装好 Arch Linux 添加好用户最初做的事情就是安装 …

从今天起本博客将启用 GitHub Issue 作为留言系统。 原本使用的 Disqus 将继续保留一段时间,目前没有关闭的计划。

换用 GitHub Issue 是计划了好久的事情了,最初重做这个主题的时候就有考虑过。 这个想法的契机是看到了这篇 GitHub hosted comments for GitHub hosted blogs ,然后立马觉得这个想法很符合寄宿在 GitHub Pages 上的博客。 一个限制是要求评论者必须有 GitHub 账户,考虑到我的博客的受众这个要求估计不算太过分。 使用 GitHub Issue 的好处么,比如自带的 GFMD 富文本格式,邮件通知,还有订阅和取消订阅通知,邮件回复, 这些方面都不比第三方留言系统逊色。

换用 GitHub Issue 另一方面原因是最近听说 Disqus 被部分墙了,想必以后墙也会越来越高。之前曾经试过在这个博客换上多说, 然而效果我并不喜欢,多说喜欢侵入页面加很多奇怪的东西 …

PacVis
Demo of PacVis

我为什么要做 PacVis

我喜欢 Arch Linux ,大概是因为唯有 Arch Linux 能给我对整个系统「了如指掌」的感觉。 在 Arch Linux 里我能清楚地知道我安装的每一个包,能知道系统里任何一个文件是来自哪个包, 以及我为什么要装它。或许对 Debian/Fedora/openSUSE 足够熟悉了之后也能做到这两点, 不过他们的细致打包的结果通常是包的数量比 Arch 要多个 3 到 10 倍,并且打包的细节也比 Arch Linux 简单的 PKGBUILD 要复杂一个数量级。

每一个装过 Arch Linux 的人大概都知道,装了 Arch Linux 之后得到的系统非常朴素,按照 ArchWiki 上的流程一路走下来的话,最关键的一条命令就是 pacstrap /​mnt …

在上篇文章 「桌面系统的混成器简史」 中我介绍了其它桌面系统中的混成器的发展史和工作原理, 话题回到我们的正题 Linux 系统上,来说说目前 X 中混成器是如何工作的。 这篇文章将比上一篇深入更多技术细节,不想看太多细节的可以直接跳过看 结论

原始的 X 的绘图模型

首先,没有混成器的时候 X 是这样画图的:

ditaa diagram

X 的应用程序没有统一的绘图 API 。GTK+ 在 3.0 之后统一用 Cairo 绘图, 而 Cairo 则是基于 PDF 1.4 的绘图模型构建的, GTK 的 2.0 和之前的版本中也有很大一部分的绘图是用 Cairo 进行, 其余则通过 xlib 或者 xcb 调用 X 核心协议提供的绘图原语绘图 …

(原本是想写篇关于 Wayland 的文章,后来越写越长感觉能形成一个系列, 于是就先把这篇背景介绍性质的部分发出来了。)

Linux 系统上要迎来 Wayland 了,或许大家能从各种渠道打听到 Wayland 是一个混成器,替代 X 作为显示服务器。 那么 混成器 是个什么东西,桌面系统为什么需要它呢? 要理解为什么桌面系统需要 混成器 (或者它的另一个叫法, 混成窗口管理器(Compositing Window Manager) ),在这篇文章中我想回顾一下历史, 了解一下混成器出现的前因后果。

首先介绍一下混成器出现前主要的一类窗口管理器,也就是 栈式窗口管理器(Stacking Window Manager) 的实现方式。

本文中所有桌面截图来自维基百科,不具有著作权保护。

早期的栈式窗口管理器

栈式窗口管理器的例子,Windows 3.11 的桌面
栈式窗口管理器的例子,Windows 3.11 的桌面

我们知道最初图形界面的应用程序是全屏的,独占整个显示器(现在很多游戏机和手持设备的实现仍旧如此)。 所有程序都全屏并且任何时刻只能看到一个程序的输出,这个限制显然不能满足人们使用计算机的需求, 于是就有了 窗口 …

2015年2月21日更新

上次介绍过 这个博客改换了主题 , 本以为这个话题可以告一段落了,没想到还能继续写呢。

寄宿在 Github Pages 上的静态博客通常有两种方案,其一是使用 Jekyll 方式撰写,这可以利用 Github Pages 原本就有的 Jekyll支持 生成静态网站。另一种是在 本地 也就是自己的电脑上生成好,然后把生成的 HTML 网站 push 到 Github Pages ,这种情况下 Github Pages 就完全只是一个静态页面宿主环境。

我用 Pelican 生成博客,当然就只能选择后一种方式了。这带来一些不便,比如本地配置 pelican 还是有一点点复杂的,所以不能随便找台电脑就开始写博客。有的时候只是想修正一两个错别字, 这时候必须打开某台特定的电脑才能编辑博客就显得不太方便了。再比如 pelican 本身虽然是 python 写的所以跨平台,但是具体到博客的配置方面, Windows …