https://turgenev.hatenablog.com/entry/2024/11/11/163623

USBメモリにLinuxをインストールする

今回の記事ではUSBメモリにインストールしたLinuxを扱います。LiveUSBのようにインストール時に一時的に使うのではなく、個人設定や追加パッケージのインストールができる（再起動後も維持される）ような形でUSBメモリにインストールするということです。

インストールした環境をまるごと持ち運べるので出先でも同じように作業できるというメリットがありますが、実際には出先のPCのBIOS設定を変えられる場面は少ないので、お遊びかレスキュー（不具合対応）用途が多いと思います。

インストール自体は簡単で、ハードディスク（SSD含む）にインストールするときと同様にUSBメモリにパーティションを切るだけです。自分はいつものごとくLinux Mint 22にして、32GBのUSBメモリに入れました。インストール直後の使用量は30%くらいでしたが、ChromeとかVS CodeとかDiscordとかVirtualBoxを突っ込んだらあっという間に60%くらいになったので、お遊び・レスキュー用途ならちょうどいいですが、本格的に使うにはちょっと不足気味です。

ちなみにレスキュー分野だとKNOPPIXというディストリビューションがとても有名ですが最近はあまり更新されていないようです。軽量という意味だとPuppy Linuxとかもあるんですが軽量すぎると逆にやりがいがない（？）ので結局Linux Mintにしています。

USBメモリの特性

携帯性に優れるUSBメモリの大きな欠点が、読み書き速度です。CrystalDiskでの測定結果がいろいろなところ（例えば外付けドライブも転送速度にこだわる！SSD・HDD・USBストレージの転送速度を比較 – WebDream Official-Siteとか自分で購入したUSBメモリのベンチマークテストのまとめ | ExfieldとかUSB3.0メモリの速度比較とか）にあります。HDDと比べたときのUSBメモリの特徴として、「ランダム読み込みは結構速いがランダム書き込みがものすごく遅い」というのがあります。ランダムでない（シーケンシャルな）アクセスは読み書きともにそこそこで、HDDとあまり違いはありません。

例えば自分が使っているELECOMのMF-HSU3A32G（USB3.0対応のなかではごく安価なもの）では、（自分では測っていませんがのAmazonレビューによると）ランダム書き込み0.1-0.2M/s程度です。これがどれくらい遅いかというと、インターネットが遅くて動画を見るにはちょっと不安かなあという10Mbpsの回線速度をバイト換算（1/8倍）すると1.2MB/sですから、その1/10くらいということになります。

もう一つの欠点は、書き換え可能回数に上限があることです。安い製品に使われる記憶素子だと1000回くらいしかなく、イメージ的には同じファイルを1000回書き換えたら壊れるような感じです。ちなみにSSDも構造がUSBメモリと似ていて同様の上限があります。HDDにはありません（そのかわり駆動部が劣化してそのうち壊れます）。

これらの特性にうまく対処するのがUSBメモリ上Linux運用のカギになります。

また、当然ながらスペックは商品によりけりで、高価格帯の商品ではHDDと比べても遜色のない書き込み速度をアピールしているものもあります。（本格的に使うなら）購入時は容量やUSB3.0対応だけでなく読み書き速度の実測値や耐久性もよく検討しましょう。

ある程度お金をかけるならSSDにする手もあります。近年はUSBメモリ型などといった小型のものもあり、256G程度なら数千円で買えます。もちろんHDDもアリです。

tmpfs

低速書き込みと書き換え回数上限の問題への対処法として有効なのが、ディスクではなくメモリ（RAM）をかわりに使用することです。いわゆるRAMディスクというやつです。Linuxではtmpfsという名前で呼ばれています。実はramfsというそのものズバリな名前のものも従来からあるのですが、容量をあらかじめ決めなければならないなど使い勝手がよくないので、（initramfsのような特殊な場合を除き）現在はtmpfsが使われます。

RAMディスクはメインメモリを使用するため、読み書きが最速であるかわりに容量をそれほど大きく取れず、また電源を切ると中身は全部消えてしまいます。従って頻繁に読み書きが行われ、サイズが大きくなく、かつ内容を保存しなくていいフォルダに使うのが最適です。

その典型例が/tmpで、（Linux自体の）デフォルトでtmpfsが使用されるようになっているようです。ただし、Ubuntuの/tmpをtmpfsにする方法 - チラシの表の反対側の通りUbuntu（Linux Mint）ではそうではないので、sudo systemctl enable /usr/share/systemd/tmp.mountをする必要があります。というわけでUSBでUbuntuを使うならまずはこれをやりましょう。ちなみに/tmp以外だと、/runの一部フォルダなどもデフォルトでtmpfs化されています。

その他にtmpfs化しておきたいのはキャッシュフォルダ（~/.cache）です。もちろんキャッシュは再起動後も残ってほしいものですが、前述の通りUSBの場合は書き込むよりもインターネットからもう一回ダウンロードする方が10倍速いくらいなので保存しておくデメリットのほうが大きくなります。ここのtmpfs化の設定は後でまとめて述べます。

tmpfsの永続化

また、読み書きが頻繁だが永続化したい（再起動時に内容が消えてほしくない）フォルダもあります。RAMディスクの内容が消えること自体は防げませんが、シャットダウン時にUSBに書き込み、起動時にRAMディスクにコピーするという方法があります。もちろんシャットダウン時に書き込みが必要で、量が多ければシャットダウンにその分時間がかかることにもなりますが、1回の起動中に数回〜数十回読み書きされるようなファイルが多ければやる価値はあります。

ファイルのアクセス状況はfatraceというコマンドで調べられます。-cをつけるとカレントディレクトリがあるデバイス限定、-f wをつけると書き込み限定で表示してくれます。全く同じ行が連続するのはuniqを通せば減らせます。

フォルダのサイズはduコマンドで調べられます。

他サイトを見たり自分でfatraceした結果として、永続化ありでtmpfs化したほうが良い可能性があるフォルダとしては、/var/tmp、/var/cache、/var/log、/var/spool、~/.config、などがあります。それぞれ以下で詳しく説明します。

/var/tmp…/tmpと/var/tmpの仁義無き戦い #Ruby - Qiitaなどに詳しく書いてありますが、/tmpとは違って再起動時にファイルが消えないものと定められています。systemd-tmpfilesのようなスクリプトによって一定期間（/lib/tmpfiles.d/tmp.confで設定されていて、一般には30日程度）アクセスのないファイルが勝手に削除されるようになっています。ただ実際には普通に（永続化無しで）tmpfs運用している人も多くいて、そのせいで特定ソフトウェアで問題が発生したという報告はあまり見ません。サイズは手元で200MBくらいにはなっているので、メインメモリ/USBメモリに余裕がなければ普通のtmpfs運用でもいいかもしれません。また、永続化した上で自動削除期間を7日とかに縮めるという方法もありだと思います（長時間連続稼働させるなら、この方法は/tmpにも有効です）。
/var/cache…aptなど各種ソフトウェアのキャッシュが保存されています。こちらは各ソフトウェアによって管理されるもので、/var/tmpのような自動削除機構もありません。/var/cache 下のファイルは消して良いのか #Linux - Qiitaによるとキャッシュどころか設定ファイルをここに保存するソフトウェアもあるようなので、/var/cache全体を普通にtmpfs運用するのは不適切です（している人も見かけません）。またサイズが大きいフォルダが多いです。しかしsoftware center - TMPFS for /var/cache - Ask Ubuntuやtmpfs - /var/cache on temporary filesystem - Unix & Linux Stack Exchangeやssd - On modern Linux, is it safe, or is it a bad idea to move all active writes of the OS to other disks? - Server Faultを見ると、永続化前提なら、読み書きが特に多くてそれほどサイズが大きくないいくつかのフォルダをtmpfs化するのは悪くなさそうです。筆者は/var/cache/manを永続化tmpfsにしてみました。
/var/log…言わずと知れた、ログ保存用のフォルダです。書き込みが多いので是非ともtmpfs化したいところですが、空っぽになるとエラーが出るソフトウェアもあるらしく、そもそもレスキュー用ならログは生命線なので、永続化は必須です。筆者は永続化tmpfsにしました。journalフォルダは巨大化しやすいので/etc/systemd/journald.confでSystemMaxUse=50Mなどと制限しておいたほうがいいと思います。
/var/spool…tmpfs化すべきフォルダとしてよく挙げられていますが自分の使い方・環境ではそれほどアクセスがないようなのでとりあえず放置しています。いくつかのサブフォルダ限定でtmpfs化するのも良さそうです。
~/.config…各種ソフトウェアの個人設定が入っています。当然、永続化は必須です。特にブラウザのプロファイルディレクトリ（~/.config/google-chromeなど）の読み書きが多いです。

これら以外にも/var/libあたりに結構読み書きされているところがありますが、概してサイズが大きいのでちょっと迷いどころです。

アクセスが多いもののtmpfs化が難しいファイル・フォルダもあります。例えば/etc/passwdはpipewire-pulseというのが1秒ごとにアクセスしていて気になったのですが、シンボリックリンクにしたら（案の定というべきか）useraddなどが失敗するようになりました（参考: cannot useradd/adduser when /etc/{passwd,shadow,group} are symlink (debian squeeze) - Server Fault）。また/usr/lib/x86_64-linux-gnuなんかも頻繁に読まれていますが、これもシステムの中核部分なので厳しそうです。あと、tmpfsではハードリンクなどファイルシステム独自の一部機能が使えず、これが原因でエラーが出る場合もあります。

例外にしたいフォルダ

上記のようにtmpfs化したいフォルダが色々ありますが、その中でこのファイル・フォルダだけ除外したいという場合もあります。例えば、foo/というフォルダは永続化tmpfsにしたいが、その中のfoo/cache/は残っていなくてもいいので永続化なしのtmpfsでよくて、foo/bar/はサイズが大きい割に書き込みは少ないのでそもそもtmpfsから除外したい、といったことです。

実際、手元でも、~/.cache/（永続化無しのtmpfsにしたい）のappstream/が700MBくらいあって書き込みが少ないとか、~/.config/discord/（永続化tmpfsにしたい）のCache/はtmpfsにはしたいけど永続化しなくていいとか、そういった例がありました。

これらはシンボリックリンクをうまく使って除外できるようにします。

具体的な設定

ではここまでの内容の具体的な設定方法を紹介します。

まず、わかりやすいように/myというフォルダをルートディレクトリに作成し、その中に/my/tmpという空フォルダを作って、以下のように/etc/fstabに追記してtmpfsをマウントしてみましょう。

tmpfs /my/tmp tmpfs strictatime,nodev,nosuid,mode=755 0 0

マウントオプションはtmp.mountを参考にしました。

さらに、/myと/my/tmpの中にそれぞれpとnpというフォルダを作成しました。これらはpersistentとnon-persistentの意図で、pのほうは起動時にUSB→tmpfs、終了時にtmpfs→USBと永続化が行われ、npのほうは起動時のUSB→tmpfsの一方向のコピーのみが行われることとします。パーミッションも維持します。自動化スクリプトは後で載せます。

あとは、普通のtmpfsにしたいフォルダを/my/tmp/npへのシンボリックリンク、永続化tmpfsにしたいフォルダを/my/tmp/p以下へのシンボリックリンクにすればいいです。フォルダ階層は元と揃えたほうが明快でしょう。また、フォルダだけを例にあげて説明していますが、ファイル単体でも全く同様にtmpfs化が可能です。

永続化する場合（例:/var/log）は、内容を移動した上で/var/logを/my/tmp/p/var/logへのシンボリックリンクにする、で十分です。永続化しない場合（例:~/.cache）は、~/.cacheを/my/tmp/np/home/myname/.cacheへのシンボリックリンクにして（中身を移動するかは任意）、/my/np/home/myname/.cacheに空フォルダを作成しておく必要があります。

なお、tmpfsに置く以上、設定をミスるとデータが全滅します。/var/logの構造とかを復元するのは結構面倒です。一時的にテスト用のフォルダを作って実際に再起動してパーミッション含めて元通りになっているか確認してから他のフォルダに適用することを強く推奨します。

USBのLinuxをマルチユーザーで使う人はいないと思いますが、/my/tmp/p/homeや/my/tmp/np/home以下に自動で個人フォルダを作るような運用も可能そうです。

例外を設けたいときはシンボリックリンクを使います。さっきの例なら、/my/np/home/myname/.cacheに"appstream"という名前で~/fooへのシンボリックリンクを作っておくとか、~/.config/discord/Cacheを/my/tmp/np/home/myname/discord-cacheへのシンボリックリンクにした上で/my/np/home/myname/discord-cacheを作成しておくとか、そんな感じでいけます。

スクリプトと自動化

スクリプトはrsyncを使っています。更新日時とかに従っていい感じにコピーしてくれるのでcp -rよりCPUを使うかわりにディスク負荷が少ないらしいです。以下のような/my/bak.shを作成します。

#!/bin/sh
SOURCE_DIR="/my"
TMP_DIR="/my/tmp"
if [ "$1" = "start" ]; then
    cd $SOURCE_DIR/p
    rsync -a --relative --delete --group --owner * "$TMP_DIR/p/"
    cd $SOURCE_DIR/np
    rsync -a --relative --group --owner * "$TMP_DIR/np/"
fi
if [ "$1" = "stop" ]; then
    cd $TMP_DIR/p
    rsync -a --relative --delete --group --owner * "$SOURCE_DIR/p/"
fi

このように、スクリプトの引数にstartが渡されたら起動時の処理、stopが渡されたら終了時の処理を行います（serviceファイル風）。

あとはこれをsystemdに登録します。以下のような/etc/systemd/system/manage-tmpfs.serviceを作成します。

[Unit]
Description=Restore and backup tmpfs files
DefaultDependencies=no
After=local-fs.target
Conflicts=shutdown.target
Before=systemd-resolved.service systemd-timesyncd.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/my/bak.sh start
ExecStop=/my/bak.sh stop
TimeoutStopSec=600

[Install]
WantedBy=sysinit.target

内容について説明します。

systemdにはDefaultDependenciesという設定があり、これがyes（デフォルト）だとAfter=basic.targetとかが書いてある扱いになって、システムが完全に通常起動したタイミングでサービスが起動されます。しかし、/var/logとかはできるだけ早く使いたいですし、実際存在しないとネットワーク関連サービスとかでエラーになりました。そこで、DefaultDependencies=noを指定します。そして、After=local-fs.targetでローカルファイルシステムのマウント後に実行するようにした上で、ネットワーク関連サービスのうちかなり初期に起動していたsystemd-resolved.service systemd-timesyncd.serviceをBefore=に追加したら、エラーは出なくなりました。また、systemdのよくある罠として、AfterやBeforeは起動する場合の順番を指定するだけであり、そもそも起動しない場合は無視される、という仕様があります。だから多くのsystemdサービスを見ると[Install]のところにWantedBy=multi-user.targetなどと書いてあるわけです。しかし今回はリカバリモードとかでも/var/logが欲しいのでWantedBy=sysinit.targetと指定します。

終了時に関してもいくつか注意点があります。systemdは終了時には起動時と逆順で処理を行う（依存されている方のソフトウェアを後に止めるとか）ので上記のBefore/Afterに従ってうまくやってくれそうなのですが、これに関しても似たような罠でそもそもちゃんと終了されない場合があります。通常のサービスであればDefaultDependencies=yesで、これにConflicts=shutdown.targetが実質含まれているためシャットダウン時（再起動含む）に停止されるのですが、今回はDefaultDependencies=noにしたので、Conflicts=shutdown.targetを明示的に書いておく必要があります（ここで結構ハマりました）。

また、ExecStopコマンドの実行時間にはデフォルトで90秒の上限が設けられていて、超えたら強制終了されてしまいます。そこでTimeoutStopSecを10分に指定しています。

RemainAfterExit=trueはoneshotタイプのサービスでよく使われるもので、これによってExecStartのコマンドが終了したあとも「サービスが起動したままになっている」扱いにしてくれます（＝終了処理がちゃんと行われる）。

バックアップ時の圧縮

rsyncはフォルダ構造をそのまま同期しますが、圧縮してバックアップすることもできます。最近ならzstdあたりでやるのが良さそうです。一見すると圧縮したほうが書き込み負荷が少なく済みそうですが、圧縮する場合はrsyncのように「変更無しならコピーしない」ができないので、変更が少ない場合にはむしろrsyncより書き込みが増えてしまうことも考えられます。このへんを賢くやってくれるソフトウェアがあったら教えてください。あるいは書き換えが多いフォルダ・細かいファイルが多いフォルダだけ圧縮するといった方法もあるかもしれません。

以下にzstdバージョンのbak.shを載せておきます。

#!/bin/sh

SOURCE_DIR="/my"
TMP_DIR="/my/tmp"

if [ "$1" = "start" ]; then
    mkdir -p "$TMP_DIR/p/"
    tar -Izstd -pxvf $SOURCE_DIR/bak.tar.zst -C "$TMP_DIR/"
    cd $SOURCE_DIR/np
    rsync -a --relative --group --owner * "$TMP_DIR/np/"
fi

if [ "$1" = "stop" ]; then
    cd "$TMP_DIR"
    touch bak.tar.zst
    chmod 600 bak.tar.zst
    tar -Izstd -pcvf bak.tar.zst "p"  > /dev/null
    mv bak.tar.zst $SOURCE_DIR/
fi

tarにpオプションをつけてパーミッションを保持するようにしています（圧縮時は不要らしいけど一応）。bak.tar.zstのパーミッションは600にしましょう。永続化無しのほう（np）に関しては圧縮のメリットがないのと空フォルダを追加するのがやりづらくなって不便なのでそのままです。

時間としては、ChromeとかDiscordとかそこそこ（30分くらい）使ったなーというときに適当にシャットダウンしてみてかかった時間がzstdで2分半、rsyncで4分とかだったのでzstdのほうがいいかもしれません（そもそも計測時間=ディスク負荷なのかどうかも微妙ですが）。USBに直接tarで書き込むとなぜか（実質的に書き込みは完了しているのに）終了に長い時間がかかってしまうようなので、一旦tmpfsに圧縮ファイルを作成してからmvすることで対応しています。これだと10秒以内に終わります（rsyncのほうも同様に対策したいのですが方法がわかっていません）。（再度訂正）コマンドは10秒以内に終わっているのですが、（記憶が定かではありませんが確かこの設定をしたあたりから）Reached poweroff.targetになってから電源断まで1分以上かかるようになりました。つまりコマンドがさっさと終了したように見えても結局どっかで書き込みが続いているのでかかる時間は短くなっていないようです。まあ一旦メモリに書き出してからコピーするだけで2分早くなっても困りますよね。

起動時に関してはtmpfsは空っぽなので差分も何もないのとzstdの解凍がかなり速いのでzstdに軍配が上がります。zstdで5秒くらい、rsyncで15秒くらいのイメージです。

既存ソフトウェア

独自のスクリプトを書いてしまいましたが、log向けを中心にいくつか既存ツールもあるようです（Linux ramlog系ツール比較 - 記憶は人なり）。

ただ、これらと比べても本記事のやり方は結構イケてる気がしています。

定期的なバックアップ

本記事の方法では正常終了時のみバックアップを行うので、電源トラブルで異常終了した場合は内容が失われてしまいます。既存ソフトウェアや他記事では、定期的にバックアップをとるようなものもあるようです。ただレスキュー用途ではあまり必要性がなく、稀なトラブルのために余分な書き込み負荷をかけることになるため、積極的におすすめはしません。

スワップ・zram

tmpfsは高速なかわりにメモリを消費します。Linuxではメモリが足りなくなるとスワップといってメモリのうちあまり使われていない領域をディスクに置くようになります。ディスクが遅いからといってtmpfsを使いまくって結局メモリ不足でディスクに書き込まれるようでは本末転倒なので、メモリに余裕をもってtmpfsを使いましょう。

また、zramという技術もあって、これは圧縮が有効なtmpfsみたいなものです。これをtmpfsのかわりに使うことで、CPUを消費するかわりにメモリを節約できます。またswapと組み合わせることもでき（というかそのほうが普通）、この場合は単にメモリ領域の一部に圧縮がかかるような感覚になります。tmpfs的に使った場合はどうかわかりませんがスワップ用途だと一般に1/2-1/3くらいに圧縮できるようです。ただ、tmpfsと違って予めファイルサイズを決める必要がありそうです。

strictatime/relatime/noatimeとlazytime

これは書き込み速度とはあまり関係なく、主に書き換え上限への対処法になります。

Linuxのファイルシステムでは作成日時（ctime）・更新日時（mtime）のほかにアクセス日時（atime）も記録されます。つまり、読み取りのみ行う場合でもファイルにアクセスがあればディスクに書き込みが行われてしまいます。これを調整するためのオプションがstrictatime/relatime/noatimeで、この順にアクセス日時の書き込みをだんだん行わなくなります。strictatimeが毎回必ず記録、noatimeは全く記録せず、中間のrelatimeはなんかよくわからないんですが割と必要最低限にやってくれるやつで最近はこれがデフォルトになっています。

USBメモリ的にはnoatimeがベストですがアクセス時刻が記録されなすぎて誤作動するソフトウェアが増えるらしいので、ほとんどのケースではrelatimeで良さそうです。というわけで最近のLinuxでは特に変更の必要はありません。なお、tmpfsはRAMなので書き換えを気にする必要はなく、むしろ不要ファイルの削除のために厳密なatimeがほしいのでstrictatimeが良さそうです（tmp.mountもそうなっています）。

さらにこれら3つとは独立に（つまり併用可能）lazytimeというものもあり（Linux4.0で導入らしいので比較的最近）、これはctime・mtime・atime全てに関して書き込みを遅延させ、まとめて効率よく書き込んでくれるようです。響きが良さそうなのでこれは/のマウントオプションに付けてみました。

Chromeの設定

ブラウザはGoogle Chromeを使っているのですが、~/.config/google-chromeはかなりのサイズになります。Default/File Systemはキャッシュ的なものらしいので永続化していない方にシンボリックリンクを張りました。Default/Service Workerについては【Chrome】ServiceWorkerを今度こそ決定的かつ完全に消去する #JavaScript - Qiitaの通りService Workerを無効化しました。またoptimization_guide_model_storeとextensions_crx_cacheはサイズが大きく、書き込みは少なそうだったのでUSBに移動しました。他にもサイズの大きい拡張機能（Default/Extensions/以下にある）とかはUSBメモリに移動してもいいかもしれません。

他に使えそうな（キャッシュ的な）技術

更新: RAMをキャッシュにしてbcacheを使ってみる - turgenev’s blog を書いたのであわせてお読みください。

tmpfsだと全部メモリに置かなきゃいけなくてコストが高いので、頻繁にアクセスするやつだけ勝手にメモリにキャッシュしてくれる方法がないかなと思って探したのですが、すんなり使えそうなものは無いようです。

まずdm-cacheやbcache（およびその発展形？後継？のbcachefs）といった複数のブロックデバイス（典型的にはHDDとSSD）を組み合わせて高速なほうをキャッシュとして使いつつ見た目としては単一のブロックデバイスに見せるという技術があります。ただブロックデバイスとして動作する（改めてフォーマットとかが必要）のでちょっと扱いが面倒なのと、メモリのような揮発性のものは普通には使えません（参考: What is the "proper" way to use a ramdisk as a bcache device?）。

また、OverlayFSやUnionFSのように、読み取り専用のファイルシステム（lower）の上に読み書き可能なファイルシステム（upper）を重ね合わせる技術もあり、これは（ブロックデバイスとしてではなく）ファイル・フォルダ単位で動作するところは扱いやすそうですが、キャッシュ的な機能（upperに書き込んだ内容をlowerに書き戻してくれるとか）があるわけではありません。

これら2つの中間的なもの、つまり「upper側をRAM由来（tmpfs？）（最初は空であるとする）にしてlower側（遅いほう）に重ねあわせ、よく使うやつをupperにキャッシュしていって、使わなくなったらorメモリ足りなくなったらlowerに戻して、終了時にlower側に全部コミットする」ようなファイルシステムがあるといいんですが、無さそうです。

まあ考えてみれば、普通はファイルを変更したら不揮発性のところにちゃんと書き込む（あるいは逆にOverlayFSのように全く書き込まない）という動作のほうが望ましいというか明快なのでそんなに需要はないということなんでしょうか。

あとは以下のような微妙に使えない方法がありました。

nfsのキャッシュ（FS-Cache）…書き込みにはキャッシュが効かない？nfs - Cache writes with cachefilesd (non-shared mode) on Linux - Server Fault
ここで（作者自身によって）紹介されているcatfs…メンテされてるかどうか不安
ページキャッシュを調整する…ここに非常に詳しい回答が載っているが、IO要求をどれくらい遅延させるかという話でしかなく、書き込みをディスクにコミットせずオンメモリのキャッシュから直接読み出すとかはできなさそう

まとめ

色々設定しましたが、パッケージのインストールなどはUSB本体をゴリゴリに使うのでかなり時間がかかります。そういうときには他のIO操作も全体的に遅くなります。逆にいえばインストール等していないときにChromeを使う分にはSSDで使うのと遜色ない速度です（RAMを使っているので当然ですが）。

USBメモリでLinuxを使う機会は多くないかもしれませんが、リソースの配分を細かく考えてみるのはなかなか面白いです。各自の使い方に適したやり方があると思うのでぜひ研究してみてください。