原來群輝預設沒有開啟快速複製功能
我一樣透過 VPN , 竟然達到接近 1G Bytes 吞吐量
要是在 LOCAL LAN , 應該破 1G Bytes 吞吐量不是夢吧 哈
個人積分：290分
文章編號：66357253
個人積分：5064分
文章編號：66357280
個人積分：290分
文章編號：66357439
個人積分：290分
文章編號：66358387
得到真實 LAN 環境測試數據
若 copy file 屬於同一個共用資料夾，竟然可以高達 27G Bytes/s 的數據
若 copy file 是同一台機器但是跨共用資料夾,可以高達 300M Bytes/s 的數據
而我在家裡 VPN 連回去操作得到的數據
若 copy file 屬於同一個共用資料夾，可以到 900MB Bytes/s 的數據
若 copy file 是同一台機器但是跨共用資料夾,可以高達 150M Bytes/s 的數據
看起來 server side copy 於跨共用資料夾，是採用 server 內自己 read 再 write , 也不會真正吃到我電腦的頻寬
若同屬一個共用資料夾，則採用 btrfs 特有的 clone 模式，也就是沒有真正複製資料，才會有恐怖的 27 Gbytes/s 的吞吐量
那跨機器的傳輸呢 ??? 證實還是走自己電腦頻寬啦 , VPN 下 500Kbps ... 哈哈
個人積分：5064分
文章編號：66359780
個人積分：346分
文章編號：66362968
AristotleC wrote:
呃, 這是 btrfs...(恕刪)
我指的是 btrfs 整體開源的開發, 但是你的範疇卻限定 fs/btrfs 然後有被 commit 到 kernel 了. 然後我只看 2017 今年, 但是你把時間時段拉倒 2016 開始.
依照你的範是 fs/btrfs 在 2017 今年的開發貢獻者 還是 suse 跟 中國富士通貢獻最多, 看 1 & 2 (suse), 3 & 4 ( 中國富士通)
linux kernel 的開發週期真的是季度 (quater) 你拉那麼長的時間, 如果 code 不更新到 新的版本 4.13 (LTS) 或是 最新的 4.14... 不就是停擺.... 這個就是為什麼我只拉 今年 2017 的數據. 我建議不要使用 大混缸模式 反而看不清楚當下現況
Oneplus 8 Pro•
Thinkpad T480s•
PVE6+OMV4+NextCloud
個人積分：346分
文章編號：66363273
寂寞小處男 wrote:
我找到原因了
原來群輝預設沒有開啟快速複製功能
Samba 的 server side copy on BTRFS 的確是不錯.
"它的指令變成 cp --reflink=always /@A/bigfile /@B/bigfile.copy"
Samba 的 wiki 說的很明白, 它是使用 clone 的模式. 實際上檔案並無複寫, 但是這個模式是利用 CoW 的特性. 所以 BTRFS 的 Cow 必須要開啟 (但是更加一步造成效能更慢). Synology DSM 為了效能很早就 disabled 了 cown ( chattr +C ) 所以預設是關閉. 所以這個又是一個有一好沒有兩好的"功能" 開啟了 Serverside Side Copy 會讓外部讀取效能在原本的慢上變得更加慢.
所以要如何應用就要看你的環境跟設定模式. 再來就是這個 server side copy 是無法跨 pool 的喲. 所以想要單台跨 pool 備份這個是無法做到的. 所以應用場景也是有限的.
Oneplus 8 Pro•
Thinkpad T480s•
PVE6+OMV4+NextCloud
個人積分：346分
文章編號：66363884
個人積分：0分
文章編號：66364831
依照你的範是 fs/btrfs 在 2017 今年的開發貢獻者 還是 suse 跟 中國富士通貢獻最多, 看 1 & 2 (suse), 3 & 4 ( 中國富士通)...
這點結論沒錯, btrfs 這幾年都是這幾家公司在主導. 但原文有些結論容易產生誤解, 例如 btrfs 運作的核心不在 btrfs-progs tools, 整體的開發比重其實都落在 linux/fs/btrfs. 我不清楚為什麼會拿非核心 tools project 數據來做結論.
如果單獨只拿非核心的工具來做解讀, 就會得到 "btrfs 80% 都是 david sterba 的貢獻", 似乎是單獨一人的項目, 但事實上 btrfs 是目前 linux kernel 最活躍的檔案系統, 無論從 2016~ 或 2017~ 的數據來看都是這樣.
另外 redhat 在 btrfs 社群幾乎沒有任何影響力, 往回拉到 2016 做數據的解讀是想要表達這件事, 其實再往前幾年, 或單獨只看 2017 也會得到一樣的結論, redhat 從來就沒認真投入資源在 btrfs.
xfs 反而有接近三成的貢獻來自 redhat, 如果 redhat 現在宣佈不支援 xfs 才是真的惡耗.
linux kernel 的開發週期真的是季度 (quater) 你拉那麼長的時間, 如果 code 不更新到 新的版本 4.13 (LTS) 或是 最新的 4.14... 不就是停擺.... 這個就是為什麼我只拉 今年 2017 的數據. 我建議不要使用 大混缸模式 反而看不清楚當下現況
我建議拉長時間看趨勢的變化, 但看任何一個短時間的統計數據相對容易有偏差. 另外選對 project 做解讀更是重要.
FB 有 taiwan linux kernel 開發的社群, 門檻較高, 但不少熟心核心運作細節的高手, 其實你可以考慮在那邊分享你的觀點.
個人積分：241分
文章編號：66385123
關閉廣告