Backblaze 對 SSD 存活率的報告

Backblaze 發了一篇對 SSD 存活率的報告:「The SSD Edition: 2022 Drive Stats Mid-year Review」,報告分成兩大塊,一塊是單講 SSD 的,另外一塊是跟傳統磁頭硬碟 HDD 比較。

首先是這張總表,從 2018 年到現在的 SSD 硬碟的 AFR 資料:

可以看到有特地標出信賴區間,因為對於某些量真的太少的型號,算出來的 AFR 沒有太大意義,所以重點只有在幾個數量比較多的型號。

Seagate 的 ZA250CM10003 最多,AFR 是 0.70% (CI 在 0.3%-1.3%);接下來是 Seagate 的 ZA250CM10002,AFR 是 0.78% (CI 在 0.4%-1.4%)。

第三多的是 Dell 的 DELLBOSS VD,AFR 是 0% (CI 在 0.0%-0.8%),不過要注意這是 M.2 界面,而且是 server 等級:

It is a server-class drive in an M.2 form factor, but it might be out of the price range for many of us as it currently sells from Dell for $468.65.

接下來是比較 SSD 與 HDD。這邊的比較中,兩者都是相同的用途 (開機碟 & 系統碟):

The SSDs and HDDs we are reporting on are all boot drives. They perform the same functions: booting the storage servers, recording log files, acting as temporary storage for SMART stats, and so on.

因為 SSD 目前只有五年的記錄,可以看到如果只比較五年的話,SSD 的 AFR 是比 HDD 好上不少的:

不過這邊還是以機房環境來說明,像是機櫃的振動與使用的 pattern 都是可以想到的因素。一般的情況下,如果沒有一堆 HDD 在 JBOD 裡面振動的話,是不是可以活比較久就不知道了...

但現在開機碟用 HDD 應該也會開到天花地老,好像也沒有什麼特別的理由會換回 HDD...

Backblaze 的 2022 Q2 硬碟報告

Backblaze 發表了 2022 Q2 硬碟使用的報告:「Backblaze Drive Stats for Q2 2022」。

第一張是綜合性的資料,從 2013 年到現在還活著的型號都拉出來:

表格裡面好像有些錯誤的地方,像是 SeagateST12000NM0007 這顆的數字就對不太起來,1288 顆但是有 1989 次的 failure,另外 drive days 累計有 35,823,850 days,平均下來是 27813 天 (76 年?),另外 AFR 只有 2.03% (低 1.90%,高 2.10%)。

就算硬碟數量多一個零變成 12880 顆也還是對不太起來,查 datasheet 看起來這個型號是 2017 年出的,到現在也才五年多,76 年的 1/10 變成 7.6 年也對不起來,這個部份看後續會不會更正好了...

另外作者另外把比較有指標性的型號拉出來,可以看到 HGST 在歷史上的表現很好:

然後就算只過濾 2022 Q2 的故障資料,還是可以看到 HGST 在近期的 AFR 表現很不錯:

另外最後提到他會在 DEFCON 30 上聊聊:

If you will be at DEFCON 30 in Las Vegas, I will be speaking live at the Data Duplication Village (DDV) at 1 p.m. on Friday, August 12th. The all-volunteer DDV is located in the lower level of the executive conference center of the Flamingo hotel. We’ll be talking about Drive Stats, SSDs, drive life expectancy, SMART stats, and more. I hope to see you there.

Cloudflare 推出了讓你買 cache 空間的 Cache Reserve

這幾天 Cloudflare 推出了一大包東西,其中一個是 Cache Reserve:「Introducing Cache Reserve: massively extending Cloudflare’s cache」。

一般的使用情境是依照 LRU 演算法在決定 Cloudflare 的 cache 滿的時候要排除誰:

We do eviction based on an algorithm called “least recently used” or LRU. This means that the least-requested content can be evicted from cache first to make space for more popular content when storage space is full.

Cache Reserve 就是自己買 cache 空間,他的作法是你付 R2 的空間費用:

Cache Reserve is a large, persistent data store that is implemented on top of R2.

這樣就可以完全依照 Cache-Control 這類 HTTP header 內的時間保存了,你就不用擔心會被 purge 掉,首先價錢包括了 R2 的部份:

The Cache Reserve Plan will mimic the low cost of R2. Storage will be $0.015 per GB per month and operations will be $0.36 per million reads, and $4.50 per million writes.

另外還有還沒公告的 Cache Reserve 的部份:

(Cache Reserve pricing page will be out soon)

對於很極致想要拼 hit rate 的使用者來說是個選擇就是了,另外可以想到直播相關的協定 (像是 HLS) 好像可以這樣搞來壓低對 origin server 的壓力?

Backblaze 的 2021 年硬碟死亡報告

Backblaze 放出 2021 年的硬碟統計數據了:「Backblaze Drive Stats for 2021」。

最後一張圖是 Backblaze 機房內還活著的硬碟資訊,大概是整篇裡面最有用的 (而且有 AFR 的信心區間),先拉出來看:

比較好奇的是還沒有導入 18TB 的硬碟...

另外從上面依照廠牌分類的部份也可以看出個感覺,這時候如果再針對各廠牌的歷史記錄拉出圖的話就很殘酷了,要說 Seagate 不愧是 Seagate 嗎 (大家的刻板印象好像也不刻板了,數字都對的上...):

如果就廠牌可以看出來 HGST 不論哪個型號,死亡率 (AFR) 都很低,而 Toshiba 與 Seagate 則是很吃型號,有的型號 AFR 很高,但有的就蠻低的...

另外裡面有提到一個比較有趣的現象,大顆硬碟的 AFR 反而比較低,目前猜測是新硬碟的關係,但時間要拉長才會看的比較明顯,不確定是不是有什麼技術發展出來 (過個幾年再回來看的意思):

話說前陣子才送修一顆 Seagate 的硬碟回來 (還在保固內),SMR 的死亡率果然高不少...

把 YouTube 的 Dislike 數字弄回來

最近 YouTube 也在搞事,把 Dislike 的數字拔掉了,後來在 Greasy Fork 上面找了一下,看到有兩套方法可以把數字補回來。

第一套是「Return YouTube Dislike」這個方法,從程式碼裡面可以看到是透過 API 拉出來的:

function setState() {
  cLog('Fetching votes...');
 
  doXHR({
    method: "GET",
    responseType: "json",
    url:
      "https://return-youtube-dislike-api.azurewebsites.net/votes?videoId=" +
      getVideoId(),
    onload: function (xhr) {
      if (xhr != undefined) {
        const { dislikes, likes } = xhr.response;
        cLog(`Received count: ${dislikes}`);
        setDislikes(numberFormat(dislikes));
        createRateBar(likes, dislikes);
      }
    },
  });
}

這個 API 後面應該是接 Videos: getRating 拉資料出來,但畢竟不是直接打 YouTube API (比較麻煩,需要每個使用者自己申請 API token),這樣就有隱私的疑慮了...

另外一套是「Show Youtube Dislike Count」,看了裡面程式碼發現他是用 averageRating 反推回來:

if (likeCount >= 0) {
    const r = data.playerResponse.videoDetails.averageRating;
    const dislikeCount = Math.round(likeCount * (5 - r) / (r - 1));

    ShowDislikes(likeCount, dislikeCount);
}

不過作者有點偷懶,這邊在等待頁面生成單純用 100ms 等頁面出現,有時候還是會有 race condition (就是後面還是讀不到 XDDD),如果懶的大修的話可以改成 1000ms 混過去,降低一些機率:

while (!isLoaded) {
    await Sleep(100);
}

另外數字很大的時候會稍微不準,但也算夠用了,先暫時用這套來頂著了...

限制流量的方式 (rate limit)

Lobsters Daily 上看到這篇 2017 年的文章,Figma 的工程師講怎麼做 rate limit:「An alternative approach to rate limiting」,只要大一點的站台就會遇到 spammer 之類的攻擊,就會希望實做自動化的機制擋住 spammer。

文章裡面提到了三種方式,第一種 (類) 提到了經典的 Token bucketLeaky bucket,這邊文章提供的演算法是讓每個使用者都會有一筆資料紀錄在 Redis 裡面 (這邊的用法可以抽換換成 Memcached),裡面記錄了最後一次的 access time 以及還剩下多少 token 可以用,接下來就可以照時間計算 token 的補充與消耗:

但這個演算法的缺點是 race condition,需要另外設計一些機制確保操作的 atomic:

不過大多數的實做就算不管 atomic 也還行 OK,只是會比較不精確一點。

第二個方法他叫做 Fixed window counters,這個方法把時間切齊為單位 (像是 60 秒為一個 window),所以可以把起點的時間也放到 key 裡面,然後 value 就是數量:

這個作法的好處就是簡單,而且 Redis 與 Memcached 都有提供 atomic 的 +1 操作。但缺點是可能會發生兩倍以上的 request,像是 5 reqs/min 的限制有可能會有連續的一分鐘內達到 10 reqs/min:

不過我覺得就 antispam 來說算是夠用了,當年 (大概是 2007 或是 2008 年?) 在 PIXNET 時用 C 寫 Apache module 就是把資料丟到 Memcached 裡面就是這樣實做的,然後每次學術網路的實驗室跑來掃站的就會自動被擋 XDDD

第三種方式他們稱作 Sliding window log,就是把每個 request 的 timestamp 都存起來,這個部份用 Redis 的資料結構會比用 Memcached 方便一些:

這個方式在控制上更精確,不過空間成本上就高很多... 這樣算是把常見的實做方式都提到了。

Ubuntu 下的滑鼠滾輪速度

這陣子因為經常切回 WindowsD2R,發現 Windows 下的滾輪速度快多了,回到 Ubuntu 20.04 下發現無法調整滑鼠滾輪的速度,找了一些方案測試,發現居然地雷還是超多 XD

搜尋可以找到「Increase mouse wheel scroll speed」與「How to change my mouse wheel scroll rate?」這兩篇,被推最多的都是 imwheel,但這套軟體的最新版是 2004 年,實際上用就會發現配合現代的系統 bug 很多...

另外用的方案是「Mouse scroll wheel acceleration, implemented in user space」,作者用 Python 去控制加速,測了一下正常多了。範例給的 ./main.py -v --exp 1 其中的 --exp 1 實際用起來有點太快,我改成 0.75 比較習慣。

先照著作者提到的,把 dependency 都裝起來,接下來掛到 Session and Startup 裡面,在登入後跑起來就可以了:

檔案壓縮順序造成壓縮率的差異

Hacker News Daily 上看到「Why are tar.xz files 15x smaller when using Python's tar library compared to macOS tar?」這篇,作者問了為什麼他用 Pythontarfile 壓出來比起用 tar 壓出來小了 15 倍,檔案都是 JSON 檔壓成 XZ 格式:

I'm compressing ~1.3 GB folders each filled with 1440 JSON files and find that there's a 15-fold difference between using the tar command on macOS or Raspbian 10 (Buster) and using Python's built-in tarfile library.

看到 1440 個檔案應該會有直覺是一分鐘一個檔案,跑一天的量...

隔天他把原因找出來了,在裝了 GNU Tar 並且加上 --sort='name' 參數後,壓出來的大小就跟 Python 的 tarfile 差不多了:

Ok, I think I found the issue: BSD tar and GNU tar without any sort options put the files in the archive in an undefined order.

After installing GNU tar on my Mac with:

brew install gnu-tar

And then tarring the same folder, but with the --sort option:

gtar --sort='name' -cJf zsh-archive-sorted.tar.xz /Users/user/Desktop/temp/tar/2021-03-11

I get a .tar.xz archive of 1.5 MB, equal to the archive created by the Python library.

底層的原因是檔名與檔案內容有正相關的相似度 (因為裡面都是 sensor 資料),依照檔名排序壓縮就等於把類似的 JSON 檔案放在一起壓,使得 xz 可以利用這點急遽拉高壓縮率:

My JSON files contain measurements from hundreds of sensors. Every minute I read out all sensors, but only a few of these sensors have a different value from minute to minute.

By sorting the files by name (which has the creation unixtime at the beginning of it), two subsequent files have very little different characters between them. Apparently this is very favourable for the compression efficiency.

遇到類似的情境可以當作 tuning 的一種,測試看看會不會變小很多...

Backblaze 在 2020 年對機械硬碟的回顧

前幾天 Backblaze 放了 2020 年的回顧資料出來:「Backblaze Hard Drive Stats for 2020」。

整體的 AFR (Annualized Failure Rate) 在 0.93% 左右,而如果照品牌拆開,HGST 的數字依然是最漂亮的 (雖然他現在是 WD 的品牌),大約在 0.36% 左右 (111/(1083774+4663049+372000+820272+275779+3968475)),Toshiba 次之,大約低了平均值一些落在 0.89%,而 Seagate 光是看就就知道會超過 1%...

官方有提到,低於 250,000 drive days 以下的數據僅供參考,因為資料量太少,在統計上無法提供結論:

For drives which have less than 250,000 drive days, any conclusions about drive failure rates are not justified. There is not enough data over the year-long period to reach any conclusions. We present the models with less than 250,000 drive days for completeness only.

然後 WD 本家的硬碟回到戰線了,記得之前基本上算是被唾棄 XDDD

另外一張表則是講到這三年的情況,可以看出來 2020 年的 AFR 數字降了不少,裡面也解釋了為什麼 (看起來就是活下來的穩下來了...):

The answer: It was a group effort. To start, the older drives: 4TB, 6TB, 8TB, and 10TB drives as a group were significantly better in 2020, decreasing from a 1.35% AFR in 2019 to a 0.96% AFR in 2020. At the other end of the size spectrum, we added over 30,000 larger drives: 14TB, 16TB, and 18TB, which as a group recorded an AFR of 0.89% for 2020. Finally, the 12TB drives as a group had a 2020 AFR of 0.98%. In other words, whether a drive was old or new, or big or small, they performed well in our environment in 2020.

這幾天 blog 被掃,用 nginx 的 limit_req_zone 擋...

Update:這個方法問題好像還是不少,目前先拿掉了...

這幾天 blog 被掃中單一頁面負載會比較重的頁面,結果 CPU loading 變超高,從後台可以看到常常滿載:

看了一下是都是從 Azure 上面打過來的,有好幾組都在打,IP address 每隔一段時間就會變,所以單純用 firewall 擋 IP address 的方法看起來沒用...

印象中 nginx 本身可以 rate limit,搜了一下文件可以翻到應該就是「Module ngx_http_limit_req_module」這個,就設起來暫時用這個方式擋著,大概是這樣:

limit_conn_status 429;
limit_req_status 429;
limit_req_zone $binary_remote_addr zone=myzone:10m rate=10r/m;

其中預設是傳回 5xx 系列的 service unavailable,但這邊用 429 應該更正確,從維基百科的「List of HTTP status codes」這邊可以看到不錯的說明:

429 Too Many Requests (RFC 6585)
The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.

然後 virtual host 的設定檔內把某個 path 放進這個 zone 保護起來,目前比較困擾的是需要 copy & paste try_filesFastCGI 相關的設定:

    location /path/subpath {
        limit_req zone=myzone;
        try_files $uri $uri/ /index.php?$args;

        include fastcgi.conf;
        fastcgi_intercept_errors on;
        fastcgi_pass php74;
    }

這樣一來就可以自動擋下這些狂抽猛送的 bot,至少在現階段應該還是有用的...

如果之後有遇到其他手法的話,再見招拆招看看要怎麼再加強 :o