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

这里想要讨论的闪存类存储是指 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 …

很抱歉萌狼很早就提过交换问题的事,被我一直咕咕了许久。 拖延症晚期有药么

我的提问和萌狼的回答

可以去萌狼的博客上看呀

Q1:除了博客的「关于」页面以外,还愿意再向咱介绍一下自己嘛?

介绍自己啊。 写了删删了写,不知道该介绍点啥 就说点自己的兴趣?

喜欢自由开源软件,喜欢 Arch Linux 。喜欢这些倒不是出于 RMS 和 FSF 那样道义上的原因, 我觉得商业软件公司要赚钱吃饭也是无可厚非的。

喜欢自由软件是因为,当我需要知道它到底怎么工作的时候,有可能去挖代码,必要的话能去改代码。 当然我一个人肯定不能读所有在用的软件,但是我知道我有读和修改代码的权利的话, 那么我认识的朋友们也同样有这样的权利,我不认识的广大社区有千千万万的人也同样有这样的权利, 从而我相信当我遇到问题的时候不至于卡在某些人某些公司某些集体的决策上而无法解决。

基于这个理由,我对开源社区也同样有公开全部细节的期待。我喜欢 Arch Linux 因为即便它的内部决策只是一小波人,但是导致决策的讨论以及决策的执行方式全是公开的,可以在网上翻阅, 可以追根溯源,这让我有种安心感。就像我不喜欢 Manjaro 的一点是它有太多细节是翻阅不到的, 虽然它也是开源社区,但是打包细节翻阅不到,包列表翻阅不到,决策的制定和执行的过程也翻阅不到 …

最近几个月在这个博客发了不少歌词翻译 似乎有要转型成音乐博主的趋势 ,前段时间买了个新域名 sak.uy ,准备专门用来放这些东方歌曲的歌词翻译,于是分设了单独的博客「 Sakuya的音乐盒 」。主博客这边右侧边栏会有到音乐盒的链接。

曾经在这边的那些歌尽量保持 URL 跳转过去,新的歌词翻译会发到那边去,还想继续听歌的话请继续订阅那边的 RSS 呀。

主博客这边还是像往常一样保持记录生活点滴和技术经验好了。说道介绍技术, 有人问过我那些日语歌词上给汉字标注的假名都是我一个个手输的么? 一开始是手输的,后来发现了不错的自动化方案,于是这里介绍一下。

首先是 python-furigana

这是个 python 写的小程序(严格说是库),可以把一段日文转换成标准的 HTML 形式的 <ruby> 标签的振假名( ()仮名(かな) )。 它本身只是个方便的格式化库,实际工作是用 python-mecab 这个 binding 去查询 mecab 这个著名的日语语料分析库。要用它还得配合一些开源的 mecab 词典,这些在 …

惠狐 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 添加好用户最初做的事情就是安装 …

知乎 转载

和上篇文章一样,这篇也是来自一个知乎上我回答的问题。

原问题:为什么 Linus Torvalds 不愿意将 Linux 变成 GPLv3 授权?

DebConf 14: Q&A with Linus Torvalds

我的回答:

这里有段 Linus Torvalds 在 DebConf 14 上的 Q&A: https://youtu.be/1Mg5_gxNXTo?t=47m20s

其中关于 GPLv3 和协议的那一段在47:20开始到57:00左右。 里面 Linus 对自己的观点澄清得很清楚了。 看u2b或者听英语有困难的请留评论,我抽空可以试着翻译一下。

然后接下来就是我承诺的翻译了 …

知乎 转载

转载几篇知乎上我自己的回答,因为不喜欢知乎的排版,所以在博客里重新排版一遍。

原问题:C语言中“.”与“->”有什么区别?

除了表达形式有些不同,功能可以说完全一样阿。那为何又要构造两个功能一样的运算符? 效率有差异?可是现在编译器优化都那么强了,如果真是这样岂不是有些多此一举


刚刚翻了下书,说早期的C实现无法用结构直接当作参数在函数间传递,只能用指向结构的指针在函数间进行传递!我想这应该也是最直观的原因吧。

我的回答

首先 a->b 的含义是 (*a).b ,所以他们是不同的,不过的确 -> 可以用 * . 实现,不需要单独一个运算符。 嗯,我这是说现代的标准化的 C 语义上来说, -> 可以用 * . 的组合实现。

早期的 C 有一段时间的语义和现代的 C 的语义不太一样。

稍微有点汇编的基础的同学可能知道,在机器码和汇编的角度来看,不存在变量,不存在 struct …

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

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

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