書いて覚えるSwift入門

第18回 APFSとSwift3

この記事を読むのに必要な時間:およそ 3.5 分

APFS―3度目の正直

いよいよSwift 3の解説……の前にOne More Thing。⁠新製品なきWWDC」前回言いましたが,実は正真正銘の新製品が1つありました。APFS。現在のHFS+に代わる新しいファイルシステムです。ファイルシステムというものの重要性を考えれば,これをスルーするわけにはいかないでしょう。

ファイルシステムの歴史

Apple製品のファイルシステムと言えば,1998年以来一貫してHFS+でした。Jobsの復帰は,技術的には買収元であるNeXTが買収先であるAppleを乗っ取っていく歴史でもあり,macOSは(9までの)Mac OSではなくNextStepの子孫なのですが,唯一乗っ取れなかったのがHFS+です。

HFS+が受けた最初の挑戦が,NextStep 由来のUFS(Unix File System)であるのはごく自然とも言えます。OS X登場当時はUFSがHFS+を置き換えると思われていたのですが,HFS+はその挑戦を退けます。HFS+にはユーザごとの所有権やパーミッションといった,OS XというUnixに必要な機能をすべて備えていたからです。UFSにあってHFS+にないのは,スパースファイルやファイル名の大文字小文字の区別ぐらいで,それらは必須ではなかったのです。

次の挑戦はZFSの登場でした。ZFSはこれまでのファイルシステムの常識を覆す画期的なファイルシステムでした。fsckを不要にするトランザクション,パーティションという概念を過去のものにするデータセット,ファイルシステム自体のundoを可能にするスナップショット,エラーを自動検知し,可能であれば自動修復するチェックサム,RAIDホールがないRAID-Z……「Z=最後のファイルシステム」という自信がその名に込められたZFSは,今は亡きSun Microsystemsの最後の遺産でもあります。

ZFSオープン化の理由

画期的だったのは技術にとどまりません。同社はZFSをオープンソースしたのです。おかげでSolaris以外のOSにも移植が進みました。最も熱心だったFreeBSDは,今やZFSが最大の売りの1つにもなっていますし,ライセンスがGPLと非互換ということで公式サポートできないはずのLinuxすら,カーネルモジュールをカーネル本体とは別配布にすることで利用可能になっています。そしてOS Xも,いったんは公式サポートしたのです。OS X v10.5にはリードオンリーとはいえZFSが追加されました。しかしAppleは,v10.6でZFSサポートを打ち切ってしまいます。

例によってAppleはその理由をつまびらかにしていませんが,最も人気がある仮説はSunがOracleに買収されたことで,OracleがAppleへのライセンスを蹴ったというものです。かなりの説得力もあり,筆者自身ほとんど説得されていた一方,ZFSがオープンソースであり,OS Xを含む複数OSのサポートがOpenZFSとして結実していることを考えると鵜呑みにし難くもあります。

HFS+がUFSとZFSを退けた話は,拙著コードなエッセイ注1)⁠も取り上げたのでそちらでも確認していただくとして,APFSの登場で,なぜZFSではダメだったのか,筆者にもやっと納得できる理由が得られたように思います。

HFS+をZFSにライブアップグレードするのは不可能だからです。技術的にはさておき,既存のAppleデバイスのユーザが受け入れられる形では。

ファイルシステムのライブアップグレードは,大きなところでは二度行われています。1つは1998年の,MacにおけるHFSからHFS+へのアップグレード。もう1つはWindowsにおけるFATからNTFSへのアップグレード。どちらも共通しているのは,新ファイルシステムが旧ファイルシステムのすべての機能を上位互換としてサポートしていること,そしてアップグレードするのはメタデータのみで,データはそのままだということ表1)⁠

表1 ファイルシステムの機能比較

機能HFS+ZFSAPFSコメント
Copy-on-write×新世代FSの要
スナップショット×
クローン×
RAID××
データセット×既存FSのパーティション相当
チェックサム×APFSはメタデータのみ
暗号化x
SSD最適化
タイムスタンプ粒度ナノ秒ナノ秒
最長ファイル名UTF-16で255文字255バイトHFS+以上ZFSでは互換性不足
旧FSからのアップグレードNA×ZFSでは困難

たとえば最長ファイル名。ZFSは255バイトなのに対し,HFS+は(実はNTFSも)UTF-16で255文字。バイト長で倍も違います。255バイトでも長過ぎに一見思えますが,Twitterのつぶやきをそのままファイル名にペーストするユーザがいないと誰が断言できるでしょうか。

その一方,ZFSではストレージに書き込む情報すべてにチェックサムを付けていますが,APFSではメタデータのみ。もしZFS同様にAPFSもデータのチェックサムを付けようとするとどうなるか? ファイルシステムのアップグレードの際に,使用ブロックの情報をすべて読む必要があります。それはアップグレードに数分ではなく数時間を要するということであり,古くからのパソコンユーザなら何とか耐えられてもスマフォやタブレットのユーザにそこまでの忍耐力は期待できないでしょう。

注1)
『コードなエッセイ』当社刊行,ISBN:978-4-7741-5664-4

APFSの真意

APFSのことを最初に耳にした時点での筆者の感想は,⁠それってZFSと何が違うの?」でした。とくにその要となっているのが表1で挙げたようにcopy-on-writeがZFSの真髄でもあります。しかしAppleははっきり表明しました。⁠18ヵ月後,すべてのAppleデバイスのデフォルトファイルシステムをAPFSに移行する。既存デバイスはそのままアップグレードする」と。

あらためて見てみると,ZFSとAPFSは要となっている技術は共通していても,ユースケースは180度異なるとも言えます。ZFSが威力を発揮するのは,サーバの大規模ストレージ。APFSはパーソナルデバイスの内部ストレージ。ZFSにとってのSSDの役どころはディスクアレイのキャッシュ,APFSにとってのSSDは唯一のストレージ。ZFSにとって暗号化は「あればうれしい」機能,APFSにとって暗号化は「欠かせない機能」……。

APFSはオープンソース化されない?

1つ気になるのは,⁠APFSはApple製品に最適化」されていることを強調していること。これまでAppleはOSの基礎部分をDarwinとしてオープンソースしてきました。HFS+まわりのコードもその一環として公開されています。ファイルシステムなきOSというのが現状ありえない以上当然とも言えますが,HFS+とAPFSのどちらでもブートできるとしたら,APFSのコードはDarwinに含める必要はなくなります。

残念ながらその可能性は低くないでしょう。残念でないことに,ファイルシステムの違いはネットが当然のように吸収してくれます。フロッピー,CD-ROM,DVD……リムーバブルドライブはMacからも消えてしまいました。そしてUSBメモリすら,iPhoneやiPadにはそのまま刺さらない。そしてそれをほとんど誰も気にしないとあっては,Apple製品に最適化されたファイルシステムをサポートするインセンティブはさほど高くはない。オープンソースなHFS+すら,Appleの外ではほとんどサポートされているとは言えないのに……。

それでも,Apple製品向けにソフトウェアを開発する我々は,APFSの機能を学ばざるを得ないでしょう。とくにクローンやスナップショットのようなHFS+にはない特長を活かすとしたら。1つ確かなのは,APFSのAPIはSwiftでも提供されるであろうということ。どんなふうになるか,今から楽しみです。

著者プロフィール

小飼弾(こがいだん)

1969年生まれ,東京都出身。元ライブドア取締役の肩書きよりも,最近はPokemon GOのガチトレーナーのほうが有名になりつつある……かもしれない永遠のエンジニアオヤジ。

活躍の場はIT業界だけでなく,サブカルからアカデミックまで多方面にわたり,ネットからの情報発信は気の向くまま毎日毎秒! https://twitter.com/dankogai,ニコニコチャンネルは,http://ch.nicovideo.jp/dankogai,blogはhttp://blog.livedoor.jp/dankogai/

当社刊行書籍は『小飼弾のアルファギークに逢ってきた』『小飼弾のコードなエッセイ』など。他にも著書多数。

コメント

コメントの記入