Home » 2014 » April

RAID 卡的電池維護

實際的世界都是由 workaround 疊 workaround 解決問題的...

MySQL 資料庫一般都用 RAID 10,利用 RAID 1 的特性保護資料,並且利用 RAID 0 的特性提昇 IOPS 能力。

而這些 RAID 卡通常都會提供 cache,預設應該都會開 read cache,可以大幅增加 random read 的速度。而另外也可以打開 write cache (也就是 write-back),寫入時先寫到 cache 裡,RAID 卡馬上就會跟作業系統回報完成,藉以加速 random write 的速度。

但這樣就會有風險,當資料還沒寫入硬碟就斷電時就會遺失資料。所以在設定 write-back 的 RAID 卡上安裝電池就變成解法之一。

而電池會有壽命問題,所以配電池的 RAID 卡會每隔一陣子就放電測試電池可以撐多久,但在放電測試時,如果斷電就有可能造成資料遺失,於是又冒出很多方法解決。

也就是在「Learning to Deal With Learning」這篇提到 RAID 卡電池維護的事情。

每一層都是 workaround 想辦法解決問題,然後再用 workaround 解決前面造成的問題...

Anyway,有幾種解法,其中仍然對上層作業系統與應用程式透明的解法是:

  • 雙電池架構,很明顯的可以一次只測一顆。
  • 改用 NVRAM,就不需要電池了,不過速度以及成本會是另外一個問題。

另外,對上層作業系統與應用程式有影響的方式:

  • 放電測試時將 write cache 關閉,切回 write-through。這點在原文裡也有提到,效能其實會受到蠻大的影響。
  • 不放電測試了,但這樣的缺點就是拿安全性交換,當斷電時不知道能不撐過去。
  • 或是自己控制放電測試的時間,這可以配合上面切回 write-through 的方式,挑負載比較輕的離峰時間做。

看了下來雙電池架構還不錯,增加的成本還算可以接受,而且因為效能不受到影響,也確保資料安全性,整體維護起來比較簡單。而之後在規模更大的時候,應該就會直接考慮跳到自己放電測試的方式來處理電池問題...

Facebook 的主程式碼放在 Git?

在一月時,Facebook 官方的 Engineering Blog 上提到 Facebook 使用 Mercurial 遇到的問題,以及所作的努力「Scaling Mercurial at Facebook」:

Facebook's main source repository is enormous--many times larger than even the Linux kernel, which checked in at 17 million lines of code and 44,000 files in 2013.

...

Instead, we chose to improve Mercurial. Mercurial is a distributed source control system similar to Git, with many equivalent features.

當時的解讀是 Facebook 把 main source repository 放到 Mercurial 上。

以 Facebook 的規模以及遇到的問題,是有能力直接改變世界的,用 Mercurial 或是 Git 都算是合理的選擇。

不過這幾天在 Twitter 上看到:

這讓人錯亂了啊 XDDD

Go 的 self-boot 計畫

Go 的 self-boot 計畫,也就是用 Go compiler 編 Go compiler:「Russ Cox – porting the Go compiler from C to Go」。

其中提到:

The goal is to convert *their* C code (not all C code). They want generated code to be human-readable and maintainable. They want automatic conversion to handle 99+% of code.

第一波想要用機器轉換過去,而且要轉出可維護的程式碼。可以馬上想到的事情是,如果這件事情成功,代表現有軟體的 C code 也有機會轉移?

接下來了幾個版本會開始發展整套機制,有得瞧了 :p

Google 以 Google+ 為中心的思想

兩則新聞,第一則是 Vic Gundotra (Google+ 的頭) 離開 Google:「Vic Gundotra, the head of Google+, leaves Google」。

第二則則是本來集中在 Google+ 的團隊將會放到其他團隊:「Report: Google to end forced G+ integration, drastically cut division resources」。

Twitter 上馬上就有人想到 Google Reader 這個犧牲品... (而且大家都對 Feedly 做的很爛但沒什麼可用的替代品感到無奈)

嗯哼...

ChaCha20-Poly1305 在 Android 上帶來的效能

Google 主推的 ChaCha20-Poly1305Android 上的 Chrome 可以看出顯著的效能差異:「Speeding up and strengthening HTTPS connections for Chrome on Android」。

在加密速度上與 AES-GCM 的差異:

AES-GCM 畢竟是標靶,被打爆本來就是預期中的事情,在 Google 大力推動下,應該是還蠻有機會成為主流...

不過隔壁棚好像還是沒什麼進展,不知道要等到何時:「Bug 917571 - Support ChaCha20+Poly1305 cipher suites」。

ARIN 進入 IPv4 Countdown Plan 的第四階段

ARIN 只剩下最後一個 /8 的 IPv4 位置時,將會啟動第四階段的發放機制,而昨天進入這個機制了:「ARIN Enters Phase Four of the IPv4 Countdown Plan」。


出自「ARIN IPv4 Countdown Plan」這頁。

目前的進度是:

  • Phase One began in February 2011 when ARIN received its last /8 from IANA.
  • Phase Two began in September 2012 when ARIN reached three remaining /8 equivalents.
  • Phase Three began in August 2013 when ARIN reached two remaining /8 equivalents.
  • Phase Four began in April 2014 when ARIN reached one remaining /8 equivalent.

不過 IPv6 的進展還是苦哈哈啊...

圖片上的文字辨識:Project Naptha

把圖片上的文字辨識直接做成 Google Chrome 的延伸套件,預設就辨識好後讓你可以直接選取:「Project Naptha」。

這是官方提供的範例:

一張含有文字的圖片可以直接 OCR 出來變成文字選擇。

官方網站上有說,這是 client-side javascript:

One of the more impressive things about this project is the fact that it's almost entirely written in client side javascript. That means that it's pretty much totally functional without access to a remote server.

不過預設會傳回去,但可以關掉:

By default, when you begin selecting text, it sends a secure HTTPS request which lacks any kind of identifiable information to the Project Naptha cached remote OCR and Translation service. This allows you to recognize text from an image with much more accuracy than otherwise possible. However, this can be disabled simply by checking the "Disable Lookup" item under the Options menu.

也就是這個選項:

這功能好讚...

PHP 的 crc32、crc32b 以及 hash_file

PHP 上 CRC32 的資料時,查到讓人噴飯的 comment

For those who are wondering, there appears to be no fundamental difference between hash_file('md5')/hash_file('sha1') and md5_file()/sha1_file(). They produce identical output and have comparable performance.

There is, however, a difference between hash_file('crc32') and something silly like crc32(file_get_contents()).

crc32(file_get_contents())'s results are most similar to those of hash_file('crc32b'), just with the octets reversed:

<?php
$fname = "something.png";

$hash = hash_file( 'crc32', $fname );
echo "crc32  = $hash\n";

$hash = hash_file( 'crc32b', $fname );
echo "crc32b = $hash\n";

$hash = sprintf("%x",crc32(file_get_contents($fname)));
echo "manual = $hash\n";
?>

crc32  = f41d7f4e
crc32b = 7dafbba4
manual = a4bbaf7d

不只是 hash_file() 抓出來不一樣,連 algorithm 都來亂...

Archives