AristotleC wrote:
往回拉到 2016 做數據的解讀是想要表達這件事
新一版的 kernel lts 是 4.13... 這根本不是 2016的, 而是 今年 2017, 你拉數據範圍本來就要依據 kernel 開發週期去看跟規劃. kernel 開發.
<blockqute> major kernel release happening every two or three months
開源開發看歷史數據有何用?
新一版的 kernel lts 是 4.13...
4.13 沒有 LTS, 有在接觸 linux 開發的人應該會知道最新的 LTS 的是 Greg K.H 接手的 4.14, 上一個則是 4.9
這根本不是 2016的, 而是 今年 2017, 你拉數據範圍本來就要依據 kernel 開發週期去看跟規劃. kernel 開發. 開源開發看歷史數據有何用?
前面有說過是看趨勢變化, btrfs 的開發不受 redhat 事件的任何影響. 只看任何單一時間點的數字, 沒有相對的比較, 也沒有趨勢的資料, 不容易下結論.
但若要單看這次最新的 linux-4.14, 不考慮 merge-point, btrfs 也是最活躍的檔案系統.
Linux-4.14
btrfs 130 commits, 29 authors
xfs 76 commits, 23 authors
f2fs 68 commits, 12 authors
ext4 27 commits, 16 authors
數字不會騙人, 但解讀的方式會導致有不同的結論, 挑錯 project 就更不用說了.
AristotleC wrote:
4.13 沒有 LTS...(恕刪)
我講的是 btrfs 的開發, 你卻限定 btrfs kernel 的部分. 所以你一直在雞同鴨講, 你覺得沒有 user-prog 那塊 btrfs 還是 btrfs 嗎?
再來就是你說 redhat 離開 btrfs 無影響, 至少你這種說法跟 The Register 英國 IT 媒體的看法不同. 再來就是在玩 btrfs 的公司只有 SUSE 跟 Fujitsu 這個也無法否認. 但是如果要你要看 2017年 Suse commit 給 ceph 的 code 跟 btrfs 的 code, 這個可是差了10倍喲
Oneplus 8 Pro•
Thinkpad T480s•
PVE6+OMV4+NextCloud
我講的是 btrfs 的開發, 你卻限定 btrfs kernel 的部分. 所以你一直在雞同鴨講, 你覺得沒有 user-prog 那塊 btrfs 還是 btrfs 嗎?
btrfs 本體在 kernel 沒錯, 檔案系統運作的邏輯都在這裡, 你分得出 user space 和 kernel space 的差異了嘛? 要嘛一起看沒問題, 單單只看輔助用的 user space tools, 還做出 80% 都來自一個人個貢獻的結論就好玩了.
再來就是在玩 btrfs 的公司只有 SUSE 跟 Fujitsu 這個也無法否認.
其實台面上最大的使用者是 facebook, linux-4.14 重要的 zstd 功能一引入也是優先實作在 btrfs 上, 而且還在 fb 內部的正式工作環境穩定運作好一陣子了.
但是如果要你要看 2017年 Suse commit 給 ceph 的 code 跟 btrfs 的 code, 這個可是差了10倍喲
不知道為什麼要跑題到 ceph, 而且還是拿 distributed filesystem 和 local filesystem 做比較, 應用的場景完全不同.
AristotleC wrote:
btrfs 本體在 kernel 沒錯, 檔案系統運作的邏輯都在這裡, 你分得出 user space 和 kernel space 的差異了嘛? 要嘛一起看沒問題, 單單只看輔助用的 user space tools, 還做出 80% 都來自一個人個貢獻的結論就好玩了.
你一定要認為 btrfs 的開發限定 kernel 然後認為數據一定要拉 2016 才算數. 試問沒有 user prog 的 btrfs send/receive, 這整個還算是完整嗎? 你抓取數據的範圍也只是假象感覺好像很多 "公司" 投入. 但是實際上不是啊. 同時我貼出來的數據也是真實的, 只是你不願意接受這個數據的觀點.
AristotleC wrote:
其實台面上最大的使用者是 facebook, linux-4.14 重要的 zstd 功能一引入也是優先實作在 btrfs 上, 而且還在 fb 內部的正式工作環境穩定運作好一陣子了.
Chris Mason 2016年底接受訪問說明過, Facebook 只是使用 btrfs 一些 management task 的部分而已. 並無使用它作為 db 或是其它 file storage 喲 (核心儲存的地方直接跳過不回答). Facebook 使用 btrfs 只有在 OS 碟部分, 方便一些 patch deployment 而且聽起來的感覺幾乎都是 single drive 模式. 然後 Facebook 也是使用很多的 glusterfs + xfs 達成一樣的目的, facebook 也沒有把寶全部壓在 btrfs.
AristotleC wrote:
不知道為什麼要跑題到 ceph, 而且還是拿 distributed filesystem 和 local filesystem 做比較, 應用的場景完全不同.
Suse 雖然聲明它會一直支持 btrfs 下去. 但是它實際投入多少資源? 很多還是只是一兩位呢? 會提到 ceph 的原因是, 每一家公司的開發資源都是有限的, 以 Suse 來說, Ceph 是它的第一優先, 投資最多資源的開源套件, 不管其管理界面 open attic (user space) 或是其 kernel space 的 coding. (怎麼會有人看 一個 development project 去這樣子去把系統拆分), 從很簡單的數字去看, Suse 投資在 Ceph 的人力, line of codes 以及資金去拼購相關套件都是超出 btrfs 10倍以上或是更多.
Oneplus 8 Pro•
Thinkpad T480s•
PVE6+OMV4+NextCloud
近期 RedHat 的決定跟這個開發速度的影響並沒有那麼大.
拿 User space tool 來說開發不活躍本來就是很奇怪的事. 以 Kernel space code 來說會比較正確.
畢竟介面沒改 (不管是舊功能還是新功能), user space 都可以不用改.
其實用 commit 數量來算也很奇怪... 這樣算跟之前聽到的 "笑話" (還是事實?) 很像...
某工程師因為 commit 數量過少, 公司算 KPI 給分數很低... 從此... 改個字就 commit 一次來達成公司的 KPI,....
你一定要認為 btrfs 的開發限定 kernel 然後認為數據一定要拉 2016 才算數. 試問沒有 user prog 的 btrfs send/receive, 這整個還算是完整嗎?
看你你還是分不出 kernel/user space 的差異. btrfs send/recvie 本體在 kernel 內, 包括最核心的差異量傳輸, userspace tools 只是透過 ioctl/syscall 做操作而已.
你抓取數據的範圍也只是假象感覺好像很多 "公司" 投入. 但是實際上不是啊. 同時我貼出來的數據也是真實的, 只是你不願意接受這個數據的觀點.
所以才要 kernel 內部主要 filesystem 拿出來比較, 才能知道活躍程度. 沒有相對的資訊, 單看你的解釋會覺得開發人員很少, 但實際上它已經是 linux 參與度最高的檔案系統了.
只看週邊的 tools project 得出 80% 來自同一個人的貢獻, 這種結論的解讀方式真的很有討論的空間.
Facebook 使用 btrfs 只有在 OS 碟部分, 方便一些 patch deployment 而且聽起來的感覺幾乎都是 single drive 模式...
https://www.linux.com/news/learn/intro-to-linux/how-facebook-uses-linux-and-btrfs-interview-chris-mason
原文在這裡, "We also have a number of machines running Gluster, using both XFS and Btrfs. The target there is primary data storage.", btrfs/xfs 都有用在主要的儲存設備上 (不然幹麻幫他加 zstd).
Suse 雖然聲明它會一直支持 btrfs 下去. 但是它實際投入多少資源? 很多還是只是一兩位呢? 會提到 ceph 的原因是, 每一家公司的開發資源都是有限的 ...
呃, 我以為你會用 git ... , 查一下就知道了, 兩邊人員都在 10 人以上, 20 人以下, 而且沒有重疊.
Suse 投資在 Ceph 的人力, line of codes 以及資金去拼購相關套件都是超出 btrfs 10倍以上或是更多.
有沒有 10 倍資料的出處, 或計算方法? 單看 git repo 上的資訊, 兩者差距不大, 連兩倍都很困難, 有些指標甚至是落後的.
提 ceph 的目的是要暗示會擠壓到 btrfs 開發嗎? 不仔細查證還真的會滑坡滑過去...
內文搜尋
從 APP 打開
X