『Infra Study 2nd #2「クラウドネイティブを支えるインフラ技術」』でお話してきました
5.11 で追加された OverlayFS の非特権マウント（2）
前回は、OverlayFS の非特権マウントの基本的な部分について説明しました。
ところで OverlayFS はシンプルながらも、より進んだ使い方ができる機能やオプションが存在します。基本的な機能以上の機能を使う場合、OverlayFS は拡張ファイル属性を使います。
例えば連載第18回で説明した「opaque（不透明）ディレクトリ」機能や、以前のブログエントリーで説明したredirect_dir機能などです。
しかし拡張ファイル属性で、この trusted で始まる属性（trusted名前空間）を使う場合は特権が必要であり、当然 User Namespace 内の root ではこの属性を使用できません。このような場合、代わりに自由に定義して使える属性（名前空間）として user が存在します1。
OverlayFS でも、この機能を使うように実装されており、trusted の代わりに user を使う場合は、マウントオプションとして userxattr を指定してマウントします。この場合、trusted.overlay.* ではなく user.overlay.* を使うようになります。
非特権の場合の拡張ファイル属性
この拡張ファイル属性の動きを連載で説明した「opaque（不透明）ディレクトリ」を使って説明しましょう。この機能を使うと lowerdir に指定した下層側のディレクトリの内容が見えなくなります。
opaqueディレクトリを使いたい場合、拡張ファイル属性 trusted.overlay.opaque に y という値を入れます。非特権 OverlayFS の場合は、この代わりに user.overlay.opaque を使うわけです。
この機能の動きを見るための環境を作成しましょう。
$ mkdir lower upper work overlay $ mkdir {lower,upper}/opaquetest $ touch lower/opaquetest/testfile_lower upper/opaquetest/testfile_upper
これまでの実行例と同様に lower、upper、work、overlay というディレクトリを作成し、lower と upper の両方のディレクトリに opaquetest というディレクトリを作成します（連載の例と同じです）。そして lower、upper 配下の opaquetest ディレクトリ内にそれぞれ testfile_lower、testfile_upper というファイルを置きます。
この環境で普通に OverlayFS マウントを行うと、次のように見えるはずです。
# tree overlay/ overlay/ └── opaquetest ├── testfile_lower └── testfile_upper 1 directory, 2 files
userxattr オプションを使わない場合
まずは userxattr オプションを指定せずに OverlayFS マウントを行い、動きを見てみましょう。当然、期待する動きはしないはずです。
# setfattr -n "user.overlay.opaque" -v "y" upper/opaquetest/ （拡張ファイル属性を設定する） # getfattr -n "user.overlay.opaque" upper/opaquetest/ （拡張ファイル属性が設定されたのを確認） # file: upper/opaquetest/ user.overlay.opaque="y" # mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work overlay overlay # tree overlay/ （拡張ファイル属性を設定したものの、特にOverlayFSの動きに変化はない） overlay/ └── opaquetest ├── testfile_lower └── testfile_upper 1 directory, 2 files # umount overlay
上記の例のように user.overlay.opaque 属性を設定しても、特に先ほどの普通に OverlayFS マウントを行ったときと動きに変化はありません。
userxattr オプションを追加してマウントした場合
それでは OverlayFS マウントを行う際に userxattr オプションを追加してみましょう。
# getfattr -n "user.overlay.opaque" upper/opaquetest/ （拡張属性が設定されているのを確認） # file: upper/opaquetest/ user.overlay.opaque="y" # mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work,userxattr overlay overlay （userxattrオプションを指定してマウント） # tree lower upper （lower, upper以下のopaquetestディレクトリにはそれぞれファイルが存在する） lower └── opaquetest └── testfile_lower upper └── opaquetest └── testfile_upper 2 directories, 2 files # tree overlay/ （overlayディレクトリを見ると上層側に置いたファイルしか見えない） overlay/ └── opaquetest └── testfile_upper 1 directory, 1 file
このように上層側のファイルしか見えません。opaque ディレクトリの機能が働いていることがわかります。
非特権マウントの場合に使えない機能
以上のように、非特権マウントの場合は trusted.overlay の代わりに user.overlay を使って OverlayFS 独自の機能を実現します。
しかし非特権の場合、特権を持っているケースと同じように機能を使うと危険なケースがあります（特権の取得につながるとか）。このような機能については非特権の場合には使えないようになっています。
この機能のひとつが、以前ブログで紹介したredirect_dir機能 です。
次のように、この機能を使うためにオプションを指定してマウントしようとするとエラーになります。
$ unshare --user --map-root-user --mount # mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work,userxattr,redirect_dir=on overlay overlay mount: /home/karma/tmp/overlay: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error.
当然ですが、redirect_dir=off とするとマウントできます。
# mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work,userxattr,redirect_dir=off overlay overlay # grep overlay /proc/self/mountinfo 119 109 0:62 / /home/karma/tmp/overlay rw,relatime - overlay overlay rw,lowerdir=lower,upperdir=upper,workdir=work,redirect_dir=off,index=off,metacopy=off
他にも非特権の場合、metacopy 機能が使えないようです（こちらの機能は私はまだ調べていないので詳細はまたの機会に）。
5.11 で追加された OverlayFS の非特権マウント（1）
5.11 カーネルで overlayfs に大きな変更があったようで、久々にカーネルの新しい機能を試してみました。
とは言っても、結果だけ言うとすぐに終わってしまうので、すごいことをやったように見せかけるために、復習したりして順に説明していきましょう。時間のない方は最後の方だけ見れば良いです。
OverlayFS とは
Union Filesystem の実装の1つで、ディレクトリを重ね合わせて1つのディレクトリツリーを構成できます。Docker なんかではおなじみの機能ですね。おなじみの機能とはいえ、実際に直接マウントして動きを見たことがない方も多いかと思います。そこでまずは動きを簡単に見てみましょう。
重ね合わせるということで、下層側ディレクトリ、上層側ディレクトリを重ね合わせて、マウントポイント以下に見せます。他にワーク用の workdir として指定するディレクトリが必要です。
次の例では
というディレクトリを準備しています。lower と upper の中にはディレクトリとファイルを作成しておき、マウント後に overlay 以下にそれらのファイル・ディレクトリが見えることが確認できます。
$ mkdir lower upper work overlay # overlayfs用のディレクトリの作成 $ mkdir lower/lowerdir upper/upperdir # 下層、上層それぞれにディレクトリ作成 $ touch lower/lowerdir/lowfile upper/upperdir/upfile # ディレクトリ内にファイル作成 $ sudo mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work overlay overlay $ find overlay/ overlay/ overlay/lowerdir overlay/lowerdir/lowfile overlay/upperdir overlay/upperdir/upfile $ grep overlay /proc/$$/mountinfo 68 33 0:67 / /home/karma/tmp/overlay rw,relatime - overlay overlay rw,lowerdir=lower,upperdir=upper,workdir=work
詳しくは連載記事 gihyo.jp や、カーネル付属文書 www.kernel.org をご覧ください。
他に関連記事としてこんな記事も書いています。
5.11 カーネルで行われた非特権マウントのための変更と FS_USERNS_MOUNT
User Namespace内は、Namespace内では特権ユーザー、Namespace外では一般ユーザーという UID/GID のマッピングができる機能です。Namespace 内では特権を持つユーザーであっても、実際は特権を持たないユーザーでの処理がされているため、当然ながら一般的には User Namespace 内ではマウント操作はできません。
User Namespace について詳しくは連載の次の記事をご覧ください。
しかし、一部のファイルシステムについては、従来から User Namespace 内でマウントできました。例えば、コンテナ内で /proc や tmpfs などをマウントする操作は普通に行われている操作ではないかと思います。
このような User Namespace 内でファイルシステムをマウントできる機能は、非常に簡単な定義を行うだけで使えます。このためのファイルシステムに定義する定数が include/linux/fs.h に定義されています。
struct file_system_type { const char *name; int fs_flags; #define FS_REQUIRES_DEV 1 #define FS_BINARY_MOUNTDATA 2 #define FS_HAS_SUBTYPE 4 #define FS_USERNS_MOUNT 8 /* Can be mounted by userns root */ #define FS_DISALLOW_NOTIFY_PERM 16 /* Disable fanotify permission events */ : (snip)
この FS_USERNS_MOUNT というのがそれで、ファイルシステムを実装する際にこの値を fs_flags に設定すると、コメントにあるように User Namespace 内の root が、そのファイルシステムをマウントできるわけです。
実は LXC 方面で使っていたため、Ubuntu のカーネルにはこれまでも User Namespace 内で overlayfs をマウントするパッチが適用されていました（筆者がメンテナをつとめる Plamo Linux でも一時期適用されていたはずです）。
今回（5.11 カーネル）の OverlayFS の非特権マウントのパッチも非常に単純で、次のようなパッチです。これまで Ubuntu カーネルに適用されていたパッチも同じものです。
--- a/fs/overlayfs/super.c +++ b/fs/overlayfs/super.c @@ -2096,6 +2096,7 @@ static struct dentry *ovl_mount(struct file_system_type *fs_type, int flags, static struct file_system_type ovl_fs_type = { .owner = THIS_MODULE, .name = "overlay", + .fs_flags = FS_USERNS_MOUNT, .mount = ovl_mount, .kill_sb = kill_anon_super, };
今回の OverlayFS に対するパッチは 10 個ほどのパッチとなっていますが、「非特権マウント」のために必要な変更は上記の変更だけです。他はより安全に処理を行うための修正のようで、今回だけでなく 5.8 でも変更が行われていたようです。
5.11 カーネルでの非特権 OverlayFS マウント
それでは先の例と同じディレクトリ、ファイルを使って非特権 OverlayFS を試してみましょう。使用するカーネルは 5.11.5 です。
$ uname -r 5.11.5-plamo64
「非特権」と言っても、先に説明したとおり「User Namespace 内の root がマウントできる」ということですので、unshare コマンドで User Namespace を作成して試します。（いずれにせよ mount コマンドは root でないと実行が失敗するようになってます）
ただ、ここで User Namespace だけを作ってもマウントは失敗します。
$ unshare --user --map-root-user # mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work overlay overlay mount: /home/karma/tmp/overlay: permission denied. （失敗した）
これは Mount Namespace も元の Namespace とも独立している必要があるためです。
そこで次の例では unshare コマンドに --mount も指定して User/Mount Namespace を作成してみましょう。--map-root-user は unshare を実行するユーザーと User Namespace 内の root をマッピングするオプションです。次の例だと元の Namespace の UID: 1000 のユーザーと作成する Namespace 内の UID:0 をマッピングするということです。
$ id -u （現在のユーザーは UID:1000） 1000 $ unshare --user --map-root-user --mount （User Namespace と Mount Namespace を作成する） # mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work overlay overlay # grep overlay /proc/self/mountinfo （マウント情報を確認する） 119 109 0:62 / /home/karma/tmp/overlay rw,relatime - overlay overlay rw,lowerdir=lower,upperdir=upper,workdir=work,index=off,metacopy=off # find overlay/ （重ね合わせた状態でマウントできている） overlay/ overlay/lowerdir overlay/lowerdir/lowfile overlay/upperdir overlay/upperdir/upfile
マウントが成功しましたね。所有権も見ておきましょう。
# ls -l overlay/ 合計 0 drwxr-xr-x 1 root root 14 3月 14日 21:07 lowerdir/ drwxr-xr-x 1 root root 12 3月 14日 21:07 upperdir/ # ls -l overlay/* overlay/lowerdir: 合計 0 -rw-r--r-- 1 root root 0 3月 14日 21:07 lowfile overlay/upperdir: 合計 0 -rw-r--r-- 1 root root 0 3月 14日 21:07 upfile
これらのファイルは元の Namespace のユーザー（UID: 1000）権限で作成しましたので、ちゃんと User Namespace 内でマウントしてもマッピング先のユーザー（UID: 0=root）の所有権になっています。
5.11 より前のカーネルでの実行例
一応、比較のために 5.11 より前のバージョンのカーネルで非特権マウントができないことも確認しておきましょう。ちょっと古いのですが、手元にあった 5.2 カーネルの環境で試してみました。
$ uname -r 5.2.1-plamo64 $ id -u 1000 $ unshare --mount --user --map-root-user # mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work overlay overlay mount: /home/karma/tmp/overlay: permission denied.
同様に実行してみました。失敗しましたね。
（つづく）
マウントプロパゲーション（8）〜 Namespaceとプロパゲーション（2）〜
これまでの続きです。まだまだ続きます。
- マウントプロパゲーション（1）〜 shared mount 〜 - TenForward
- マウントプロパゲーション（2）〜 private mount 〜 - TenForward
- マウントプロパゲーション（3）〜 slave mount 〜 - TenForward
- マウントプロパゲーション（4）〜 unbindable mount 〜 - TenForward
- マウントプロパゲーション（5）〜 mountinfoファイル 〜 - TenForward
- マウントプロパゲーション（6）〜 mountinfoファイル（2）〜 - TenForward
- マウントプロパゲーション（7）〜 Namespaceとプロパゲーション（1）〜 - TenForward
これまでと同様に完全に私個人が理解するための資料です（man 7 mount_namespaceみれば書いてますし）。間違いの指摘は大歓迎です。
前回と同様に引き続きマウントプロパゲーションとMount Namespaceの関係も見ていきます。今回はslaveです。
shell_1# mount -t tmpfs tmpfs /mnt_shrd/ shell_1# mount -t tmpfs tmpfs /mnt_mstr/ shell_1# mount --make-shared /mnt_shrd/ （sharedに設定） shell_1# mount --make-shared /mnt_mstr/ （sharedに設定） shell_1# grep /mnt /proc/self/mountinfo （sharedになっていることを確認） 590 31 0:52 / /mnt_shrd rw,relatime shared:324 - tmpfs tmpfs rw 604 31 0:55 / /mnt_mstr rw,relatime shared:331 - tmpfs tmpfs rw
tmpfsをふたつマウントし、両方ともsharedに設定しました。mountinfoファイルを確認するとsharedとなっているのがわかります。
ここで別のシェル（shell_2）を起動し、新しくMount Namespaceを作成してみましょう。
shell_2# unshare --mount --propagation unchanged /bin/bash （Mount Namespaceを作成） shell_2# grep /mnt /proc/self/mountinfo （sharedであることを確認） 677 636 0:52 / /mnt_shrd rw,relatime shared:324 - tmpfs tmpfs rw 678 636 0:55 / /mnt_mstr rw,relatime shared:331 - tmpfs tmpfs rw
--propagation unchangedを指定していますので、さきほど行ったマウントはいずれもsharedで元のNamespaceと変わりません。ここでこのうちのひとつのマウントをslaveに設定してみましょう。
shell_2# mount --make-slave /mnt_mstr/ （slaveに設定） shell_2# grep /mnt /proc/self/mountinfo （設定した方のマウントがslaveになったことを確認） 677 636 0:52 / /mnt_shrd rw,relatime shared:324 - tmpfs tmpfs rw 678 636 0:55 / /mnt_mstr rw,relatime master:331 - tmpfs tmpfs rw
ここでは/mnt_mstrの方をslaveに設定しましたので、オプショナルフィールドはmaster:331となっており、もとのMount Namespaceでshared:331となっていたマウントのslaveになっていることがわかります。
この新しいMount Namespace内で、このふたつのマウントのサブマウントを作成し、mountinfoファイルを確認してみましょう。
shell_2# mkdir /mnt_shrd/a shell_2# mkdir /mnt_mstr/b shell_2# mount -t tmpfs tmpfs /mnt_shrd/a shell_2# mount -t tmpfs tmpfs /mnt_mstr/b shell_2# grep /mnt /proc/self/mountinfo （mountinfoを確認） 677 636 0:52 / /mnt_shrd rw,relatime shared:324 - tmpfs tmpfs rw 678 636 0:55 / /mnt_mstr rw,relatime master:331 - tmpfs tmpfs rw 679 677 0:56 / /mnt_shrd/a rw,relatime shared:338 - tmpfs tmpfs rw 694 678 0:57 / /mnt_mstr/b rw,relatime - tmpfs tmpfs rw
もともとマウントされていた/mnt_shrd、/mnt_mstrは変わりません。そして新たに行ったサブマウントは、
/mnt_shrd/aは新たなsharedマウントでIDが338（親のマウントからsharedを継承）/mnt_mstr/bはprivateマウント
となっていることがわかります。
最初のシェル（shell_1）に戻ってmountinfoファイルを確認してみると、
shell_1# grep /mnt /proc/self/mountinfo 590 31 0:52 / /mnt_shrd rw,relatime shared:324 - tmpfs tmpfs rw 604 31 0:55 / /mnt_mstr rw,relatime shared:331 - tmpfs tmpfs rw 680 590 0:56 / /mnt_shrd/a rw,relatime shared:338 - tmpfs tmpfs rw
別のシェル（shell_2）で作成したMount Namespace内で行ったsharedマウントは、もとのMount Namespaceにも伝播しています。いっぽうでslaveに設定したほうのマウントは伝播していません。
ここで最初のシェル（shell_1）の方で新たにマウントを行ってみましょう。
shell_1# mkdir /mnt_shrd/c shell_1# mkdir /mnt_mstr/d shell_1# mount -t tmpfs tmpfs /mnt_shrd/c shell_1# mount -t tmpfs tmpfs /mnt_mstr/d shell_1# grep /mnt /proc/self/mountinfo 590 31 0:52 / /mnt_shrd rw,relatime shared:324 - tmpfs tmpfs rw 604 31 0:55 / /mnt_mstr rw,relatime shared:331 - tmpfs tmpfs rw 680 590 0:56 / /mnt_shrd/a rw,relatime shared:338 - tmpfs tmpfs rw 695 590 0:58 / /mnt_shrd/c rw,relatime shared:345 - tmpfs tmpfs rw （←新たに行われたマウント） 747 604 0:59 / /mnt_mstr/d rw,relatime shared:352 - tmpfs tmpfs rw （←新たに行われたマウント）
あらたにIDが345と352のsharedマウントが行われています。これを別のシェル（shell_2）のMount Namespace内で確認してみましょう。
shell_2# grep /mnt /proc/self/mountinfo 677 636 0:52 / /mnt_shrd rw,relatime shared:324 - tmpfs tmpfs rw 678 636 0:55 / /mnt_mstr rw,relatime master:331 - tmpfs tmpfs rw 679 677 0:56 / /mnt_shrd/a rw,relatime shared:338 - tmpfs tmpfs rw 694 678 0:57 / /mnt_mstr/b rw,relatime - tmpfs tmpfs rw 696 677 0:58 / /mnt_shrd/c rw,relatime shared:345 - tmpfs tmpfs rw 748 678 0:59 / /mnt_mstr/d rw,relatime master:352 - tmpfs tmpfs rw
最初のシェル（shell_1）で行われたID 345と352のマウントは両方とも伝播しており、slaveマウントのサブマウントのほうはmasterとなっていますので、ID 352に対するslaveマウントであることがわかります。
Huawei Watch GT 2e
5 月末に Huawei Watch GT 2e を買いました。Huawei Watch 2（GT2じゃないよ）からの買い替えです。ソレ以来毎日使っているのでレビューでも。
使い方を間違っていて的外れな感想が書いてあるかもしれません。その場合は教えて！ 気づいた所は追記していきます。
WearOS から独自 OS 搭載へ変わりましたが、おおむね満足しています。とりあえず満足している点、不満な点なんかを紹介できれば。
選択した理由
スマホとの一体感を得るのなら WearOS か Apple Watch なのでしょうが、時計、ワークアウトの記録、文字盤のカスタマイズという所に主眼を置いている私には、
というわけで、WearOS 搭載製品と迷ったのですが、バッテリーの持ちがすごいとか、ワークアウト記録も良さそうでしたので、これにしてみました。Apple Watch は新しくなって色々高機能になっているようですが、スマートウォッチ単体の性能としてはそれぞれ長所短所がありそうですね。
セットアップ
スマートウォッチとしての評価が良くても、ケチが付きそうなのがココ。スマホが iPhone だったら Apple Store からスマートウォッチを使用する際に必要なアプリを取得できるのですが、Android の場合、GT2e をスマホとペアリングして使う場合は
が必要です。しかし、現時点（2020-05末時点）では、Google Play Store からダウンロードできるバージョンは若干古いバージョンで、Android 10 には対応していないようです。ただし、Huawei 製のスマホであれば別です（調べたわけではないので知らんけど）。
となると、"Huawei App gallery" アプリを Web サイトから直接野良アプリとしてインストールして、前述のふたつを App Gallery 経由でインストールする必要があります。
ちょっと誰にでも勧められる感じではないですよね。
（参考）
バッテリーの持ち
バッテリーが 2 週間持つという売り込みと前評判でした。まあ実際使うとそれなりにヘヴィーな使い方なのでそこまではいかないものの、おおむね満足しています。
とりあえずこの前評判がどんなもんか？ということで届いてから 100% に充電したあと、あえて充電せずに使ってみました。
- 入浴時以外は 24 時間装着
- （このご時世なので）1 日在宅勤務でデスクワーク
- 平日は毎日 30 分ほど、「屋外ランニング」モードでランニング
- 休日は 2 時間ほど「屋外ウォーキング」でウォーキング
- 待ち受け時文字盤は「なし」で、腕を持ち上げたときのみ ON する設定
これで 1 週間ほど使ってみて、大体 20% 程度の残量でした。2 週間はいかないものの、これだけ持てば十分です。"Huawei Watch 2" はワークアウトモードなしで大体 2 日で同じくらいの残量でしたので比べ物にならないくらいスタミナがあります。毎日 GPS オンにしないと本当に 2 週間充電なしでいけるかも？という予感はあります。
その後は大体入浴時だけ充電していますが、前述と同じ感じの運用で、平日 1 日装着したままで大体 10% 程度バッテリーが減る感じでしょうか（待ち受け文字盤を表示しない設定の時）。
最近は常時文字盤点灯で使っています。すると 1 日装着したまま、30分程度運動すると 85% 程度残量がある感じです。途中でGPS有効にして2.5時間ほど散歩した際は 1 日使った後は 100% → 80% 程度の電池の消費でした。若干、文字盤を消した運用よりは消費が増えますが、それでも十分満足の出来ですね。
画面
日が照ってる明るい状況でも見やすいです。
自分の持ってる画像をバックグラウンドに設定した文字盤が使えるので満足ですね。実はこれがスマートウォッチを使う理由のひとつでもあります。ウォッチフェイスを推しの画像にすることw
待ち受け文字盤
デフォルトでは通常は消灯で、腕を上げると画面が点灯するというスマートウォッチでは良くある設定です（「待受の文字盤」が「なし」という設定）。
でもこの腕を上げると点灯するって設定、実際は不便ではないですか?
私は通常は PC 前で作業を行うエンジニアですが、この場合、常時時計の文字盤が上を向いた状態で作業をしています（キーボード打ってるので）。 この設定のまま、文字盤を点灯させようとすると、
- 一度腕を下ろして再度腕を持ち上げる
- ボタンを押す
のどちらかが必要なようです。ここで画面をタップしたら点灯してくれれば、待ち受け文字盤を表示しない設定のままでも良いのですが…
というわけでここは待ち受け文字盤を表示させる設定です。待ち受け文字盤を表示させていれば、画面タップで通常の文字盤が表示されますので、推しの顔も確認できるというものです＼(^o^)／
ワークアウト
WearOS 時の Google Fit のほうが良かったかな。
有酸素運動系
おおむね満足です。
最近 30 分程度（5km）ランニングすることが多いのですが、脈拍数の上限を設定しておくと、上限に達したときに通知が来るので、そのときはペースを落としたりして調整できます。
有酸素系の運動をするときは色々な指標を記録してくれますし、リアルのランニング、ウォーキングは特に色々な記録をしてくれるので後で見返す際も自分のやった運動が振り返られて良いです。
ただし、運動の自動検出をするという機能はちょっと使えない感じです。家から駅まで歩くのに20分くらい歩きますが、ほとんど駅に着く直前に「ワークアウトをオンにするか？」というような質問が表示されて、そこでオンにすればそこから計測が始まる感じです。到着寸前なのでオンにしたことないのでわかりませんが。
WearOS で Google Fit の場合は、スマホ本体も含めて常時 GPS で移動をウォッチしていて、自分で Google Fit アプリを起動して「屋外ウォーキング」や「屋外ランニング」を選択しなくても、精度は落ちるものの Google Fit に運動として記録されていました。
しかし Huawei Watch + Health だと自分で「これからワークアウトするよ」と教えないと記録の対象にならない感じです。
例えばランニングに行く時に「屋外ランニング」をオンにし忘れて（あるあるですよね？）途中でオンにした場合でも Google Fit であれば合算して通算で記録してくれますが、Huawei Health だと途中でオンにしたところからの記録になるので、やっぱりこの辺りを自動で検出して通算してくれるのでないと使えない感じです。そういう機能を期待してたのに、問い合わせしてくる機能とは（検出してバイブレーションで通知が来ても気づかないこともあるし）。ランニングの場合はもう少し早く運動を検知してくれるのかもしれませんが。
スマホも持ってランニングに行ってますので、相変わらず Google Fit では精度が悪い記録だけはされていっています。
筋力系
逆にジムでマシンを使った筋トレをする場合は圧倒的に Wear OS の Google Fit が良かったです。
まず、マシンを使う前に筋トレを始めることをスマートウォッチに教えると、腕の動きから「どのマシンをやってるか？」を自動判別して、候補を表示してくれます。（腕が動かないマシンだと検出出来ず自分で選択する必要ありましたがw）
GT2e は「筋トレ」というメニューがひとつあるだけなのでどういうメニューをやったかを後で振り返ることはできません。
そして Google Fit では運動を開始、終了したことを教えると、前述のようにメニューは自動認識して、そのメニューを何回やったかを記録してくれます（修正も可能）。そしてメニューを一旦終えると「インターバル」となって、あらかじめ設定した休憩時間をカウントしてくれます。
つまり、例えば「チェストプレス」と「ショルダープレス」をやるとすると、
- チェストプレス15回 → インターバル 30 秒 → ショルダープレス15回 → インターバル 30 秒 → チェストプレス 15 回
みたいにインターバルを入れた筋トレが行えます。
GT2e では単に時間がカウントされてるだけで「インターバル」の考え方がないので、自分で時計とにらめっこしながら 30 秒休憩を行わないとダメです。
記録も WearOS + Google Fit だとこんな感じに細かくメニューまで記録されます。
WearOSだと筋力トレーニング何分何カロリーという記録しかされません。
バンド
バンドは「グリーン＆ブラックTPUストラップ」を選択しました。色は気に入ってますが、実は購入直後 1 週間経たない間で黄色く変色した部分が現れました。
これはあかんやろ、と思ってサポートに連絡すると
- 送付もしくはリアルのサポートセンターに持ち込んでくれたら交換する
- バンドは交換部品としてはないし、バンドのみの販売はないので本体ごと交換となる
- 交換してまた変色したらまた相談してほしい
- バンドのみの交換はできないし、別の色のバンドに交換はできない
ということでした。サポートセンターに持ち込んで交換してもらったので対応には不満はありません。しかし、
- 常時装着している時計のバンドなので何もしなくても汚れる
- 汚れたら交換したいと思うのはユーザーとしては普通の考え方だと思う
- でも交換部品としてバンドを準備していないし、オプションとしてバンドのみの販売はない
これは消耗品としてのバンドを持ってるスマートウォッチではどうなんでしょ? ここは不満ですねえ。
交換して 1 ヶ月ほど使ってますが、今の所変色はありません。色が移りそうなところにはこすらないように気をつけたりしているのが関係しているのかしてないのかはわかりませんが…
通知
通知はスマホ本体の通知をそのまま GT2e に通知として送っているだけです。なので特に不足はないのですが、余計な通知まで送られるので邪魔な部分もあります。例えば
- Twitter クライアントからツイートすると送信が済むまで「ツイートしています」というような通知が現れます。これがそのまま通知として腕に通知が来るので「知ってるわ！」となります（自分でツイートしてるのでw）
- 音楽プレーヤーの曲が変わったり再生を停止したりするとその通知が来ます。これも不要ですね
通知のバイブレーションの強さは Huawei Watch 2 に比べると少し弱いかなあと思いますが、特に不満はありません。何かに集中してたり、その時の腕の角度なんかにもよるのかもしれませんが、たまに気づかないことがあります。
音楽プレーヤー
こんな感じ。あまりスマートウォッチでプレーヤーは操作しないので特に不満はないのですが、たまに再生中の曲の検出に失敗するのか何も再生していないことになります。曲名を確認したいことはあるのでそこだけが不満ですが、これはスマートウォッチでなくスマホ側のアプリ（HMS CoreとHealth）の問題じゃないですかね。
Huawei Health と Google Fit との同期
Health アプリは Google Fit との同期機能があります。
前述のようにスマホを常に持っていれば、精度は悪いにしても「ワークアウトする」と教えなくても Google Fit は記録を行ってくれます。
つまりは Health が Fit にデータ同期を行ってくれれば、Fit 自身の記録とマージしてくれて、ちゃんとした記録ができるのでは？と期待したのですが、今の所期待はずれです。
同期機能が何を同期するのか？についての説明を見たことがないのでわからないのですが、手元で見る限りは「睡眠時間」だけが同期されているように見えます。運動の記録とかも同期してくれよ。
関係ないのですが、この Huawei Health アプリ、Health 関係だけでなくデバイス（スマートウォッチ）の管理（文字盤の変更やOSアップデートなど）も請け負っていて、全然 Health アプリじゃないですw（Health 管理機能も持ってるので間違ってはないけど）
まとめ
色々満足な点、不満な点を書きましたが、とりあえず毎日装着して馴染んできていますので、毎日そこに装着されているものとして使えています。取り替えるほどの不満もないので、このまま不満な所はそのままスルーしながらしばらく使っていくんだと思います（前のやつは 2.5 年程度使った）。
