你覺得,你的系統中大多數文件大概有多大?

這是一個很有意思的問題,你可以試着先猜一下。

基於對系統中保存文件的瞭解,可能有這樣的思考過程:

  • 我收藏了好多照片,每個有 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 …

很抱歉萌狼很早就提過交換問題的事,被我一直咕咕了許久。 拖延症晚期有藥麼

我的提問和萌狼的回答

可以去萌狼的博客上看呀

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 …