最近、地上波アニメとか少年誌で普通に百合やるようになったんだなぁ…と。前からあったんかもしれんけど。
ふと、自分の感覚では薔薇に対して嫌悪感あるけど、百合について女性からの嫌悪感はないのか？と言うのが気になって調べてみると、統計的には薔薇に対する男性の嫌悪感はやはり高いが、百合に対する女性の嫌悪感は低いらしい。因みに百合に対しては男性からの嫌悪感も低い。なにそれ百合めっちゃお得やん・・・。
左巻きの人がいうジェンダーフリーについて、性差によって社会的機会が失われることは改善したほうがいいと思うけれど、性差は対称ではないんだから、結果が同じであるべきとか何もかも同じであるべきってのはどうかしてると思った今日この頃…。
「令和の！」って言ってみたかったけど、検索キー汚すだけなんでやめました。確認したのはFreeBSD 14.3&Samba 4.22.6とmacOS 26.2
わっかんないよ！
Web記事で言ってることはひとつもわかんないよ！
Web記事でいいって言ってるもの、何がいいのかわかんないよ！
わかんない！ 私にはわかんないの！
いやまじで。
FreeBSDとLinuxじゃ事情が違うんだよ。みんな安易にFinderから読み書きできて「これでOK」なんて言うけど、特定アプリからアクセスしたら不具合いっぱいとかあるんだよ。macOSをガチで使ってるユーザー少ないから、Sambaのアップデートでfruit周りにエンバグ出ても誰も気づいてくれないんだよ。
マジでもうわっかんないんだよ（ぉ。
まぁそんな感じなんですが、Appleが公式にafp捨てるって言い出したんで、そろそろまじめにSambaでmacOS向けのファイル共有に取り組もうかと。
そんな感じで現状の設定がこちら。なんとなく動いてる気がするけど、あってるかどうかもうよくわかんない。「FreeBSD&ZFS&netatalkのmetadata/resouceを引き継ぐ」って組み合わせのサンプルが少なすぎて…。
[global]
dos filetimes = Yes
dos filemode = Yes
inherit permissions = Yes
inherit acls = Yes
map acl inherit = Yes
acl group control = Yes
ea support = yes #4.9以降はdefault yes
vfs object = zfsacl catia fruit streams_xattr
fruit:encoding = native #default: private
fruit:metadata = netatalk #default
fruit:resource = file #default
fruit:veto_appledouble = no #default: yes
streams_xattr:prefix = user.
streams_xattr:store_stream_type = no
nfs4:mode = simple
nfs4:acedup = merge
nfs4:chown = yes
ZFSACLまわりの設定は、このあたりをよくみてください。基本的にACLはldapとかでユーザー同期してないと意味ないんで「とりあず不都合ないように」程度の設定です。
vfs object = zfsacl catia fruit streams_xattr
fruit:encoding = native #default: private
これのためにvfs_catiaが必要。macOSの特有の文字コードのエスケープ方法の指定で、netatalk互換が不要なら初期値のprivateのままでいい。副作用として、nativeではfruit:metadata=streamやruit:resource=streamと組み合わせた場合に完全に動作しないらしい。
fruit:metadata = netatalk #default
fruit:resource = file #default
“fruit:metadata = netatalk”の場合、vfs_fruitが直接拡張属性へアクセスに行きます。なので、streams_xattr関連の設定は、このfruitの設定なら要らないような気がします。過去の試行錯誤の名残なんですが、検証するのが面倒だったのでそのまま残っています。
“fruit:metadata = stream”にしてvfs_streams_xattr経由で拡張属性に保存することもできますが、netatalkと微妙に保存方法が違い、互換性がありません。
fruit:resourceについては、近頃はfruit:resource=streamの設定例が出回っていますが、個人的には非推奨です。あれは「自分の運用ではリソースフォークを使わない」という確信がある場合の設定です。
macOS向けファイルサーバーの面倒なところは、メインのファイルストリームの他に、属性情報のためのMetadataとmacOS独特のリソースフォークという情報があることです。Sambaのデフォルトでは、metadataはUNIXの拡張属性に、リソースフォークは”._”で始まる隠しファイルに保存されます。
一部のファイルシステムでは拡張属性のサイズに上限がありません（確かNTFSも）。なんで”._”で始まる隠しファイル（通称ゴミファイル）を作るよりも、同じく拡張属性に保存した方がスマートなのはその通り。
一方でFreeBSDをはじめとした多くのOSでは拡張属性にはサイズ制限があって、ぶっちゃけサイズの大きいリソースフォークを保存すると破綻します。というのも、まずUFSだと拡張属性が64kB以上扱えません。Metadataくらいなら問題ありませんが、リソースフォークに64kBを超えるカスタムアイコンかいたりするとぶっ壊れます。
一方でZFSの場合は容量制限は無いのですが、サイズが増える(数十kB以上から)と加速度的にアクセス速度が落ちる（数秒〜数十秒単位で）という特性があります。そういう仕様らしいです。1ファイルあたり秒単位でアクセス時間かかってたらいろんなところでタイムアウト起こして、様々な不具合を引き起こします。SSDとかNVMeにすればいいってもんでもなく、そう言う仕様。
なので、FreeBSDではディレクトリに”._”で始まるリソースフォークファイルがばら撒かれる設定が必須です。一度、streamに設定してみたことあるんですが、ファイルコピーが成功したり失敗したり、よくわからない不安定な振る舞いになりました。
これは、”._”で始まるリソースフォークファイルを、クライアントから直にファイルシステムとして見えるのを隠すかどうかのフラグで、デフォルトはYes。
以前はそれでなんの問題もなかったのですが、冒頭のバージョンの組み合わせだと、”no”に設定しないとクライアントからリソースフォークが見えませんでした。つまりはカスタムアイコンがまったく見えない。
Samba側かmacOS側か、どっちが悪いのかわからないけれどバグっぽいです。いつからそうなったとか検証するの、もう疲れたよ⚪︎トラッシュ・・・。
vfsオブジェクトを追加するとき、globalセクションで追加してオプション設定してても、各共有セクションでvfsのロード指定したら、globalセクションで指定したvfsのためのオプションはクリアされるらしい…という記述を見つける。
つまり、globalセクションであらかたオプション設定して、各共有セクションで追加でオプション変更するような記述するとき、各共有セクションでvfs objectを指定したらあかんらしい…。
時々不可解な振る舞いになってたのは、このせいか…。
macOSからsamba/netatalkファイル共有へのアクセスにおいて、一見動いているように見えて細かな設定で対応しないと、以下のようなトラブルが起きる…という例を最後に示しておきます。
基本的に共有上のファイルを、アプリから直接開きに行く場合ですね。
1と2の原因は、リソースフォークだったりEAまわりだったり、ACL周りだったりします。どちらも保存前のファイルに対して、EAやらACLを書き換えて保存無しでファイルを閉じるときには元通りに戻すと言う事を、ユーザーの見えないところで勝手にやろうとして自爆します。
ちなみにMicrosoft officeでのACL周りのトラブルは、Windowsとsambaでもきちんと設定しないと起きます。
3はあらかた不具合がこなれた感じです。
4はまだまだ油断ならない感じ…。
そろそろ10GbEにしてみようか？と思って諸々調べてみた。
10GBASE-Tについて調べ出すと、RJ45かSFP+か？という課題に直面します。RJ45というのは、所謂いままでのLANケーブル用のコネクタ。ツイストペアのCAT6a以上のケーブル使いましょうねってのはちょっと調べたらどこにでも載ってる。
一方で、インターフェースが普通のRJ45じゃなくて「SFP+」というタイプが存在します。じゃあSFP+とはなんぞや？というと、
こんな感じでコネクタが細長くて深いタイプ。ふつうのツイストペアのLANケーブルは刺さりません。何が刺さるのかというと、
こんな感じの「メディアコンバーター」というモジュールが刺さります。これは普通のツイストペアLANケーブルを繋ぐためのモジュールだけど、他にも光ファイバーを繋ぐことのできるタイプもあります。
で、このメディアコンバーターというのは何をしているかというと、10GBASE-Tの元になる信号に対して「ツイストペアLANケーブルで通信できるような信号の補強」をしたり「光ファイバーとの電気/光変換」をしたりします。
まぁ今までのGbEまでは、メディアコンバーターの機能がすでにチップに内蔵されていて、どうしても光ファイバー使いたいときぐらいにしかメディアコンバーターが使われることはありませんでした。
しかし、10GBASE-Tってわりと技術的にかなり無理していて、要はメディアコンバーターの機能だけで、むっちゃ高価で電力を食う。
例えば、10GBASE-TのHUB、SFP+のポートタイプなら安価に売られてるけど、RJ45のHUBとなると、少し前までは1万円/portなんて言われていました。今でも5千円/portくらいか？
実は、SFP+にはツイストペアでも光でもない、もう一つの接続方法があります。それがDAC（Direct Attach Cable）というもの。
こんな感じでケーブルの両端にSFP+のプラグが直付けされています。ケーブルは、SFP+のプラグ部分から外すことはできません。ケーブルを交換不能にしメディアコンバーターの機能も大幅に削減して「このケーブルでこの長さ」にのみ対応させることによって、大幅にコストダウンされています。
ただし、長さの制限が厳しく5〜7mくらいまで。それ以上のものもありますが、そうなるとメディアコンバーター部分により高い性能が必要になり、通常のメディアコンバーターに対するコストメリットがあまりありません。
とはいえ、5~7mまでの長さでDACケーブルで完結できるならば、RJ45よりSFP+のほうがHUBも含めると、かなり安価に10GbEの環境が構築できるわけです。
今までも、SFP+のようなメディアコンバーターのコネクタは存在していて、速度面では常にツイストペアLANケーブルよりも先行していました。しかし、ツイストペアケーブルの速度が10Mbit>100Mbit>1Gbitと速度があがり、消費電力・価格がこなれていくに従ってコスト面でRJ45/ツイストペアに置き換わっていったのがこれまでの流れ。ただ10GBASE-Tについては、その登場から置き換わるまでかなりの時間がかかっています。
10GBASE-Tの規格制定が2006年に対し、いまだにRJ45のコストと消費電力は下がらず、あまりの普及の遅さに見かねて、より遅い2.5GBASE/5GBASE-Tの規格が2021年になって後から制定されるくらい。もう20年も経つのにいまだに技術的にこなれたとは言えない。
去年になってようやく、ホスト側のPCIeカードとしては低消費電力のRealtek RTL8127が出回り始め、普及が始まりつつある感じです。
ただ、HUB側の方は10GBASE-TのRJ45対応品はまだまだ高価。もうすこし時間がかかりそうです。なので現時点では、RJ45/ツイストペアケーブルで構築するのと、SFP+/DACケーブルで構築するのと、どちらがいいのか判断が難しいところ。
そんな感じで、調べるだけ調べていまんとこはまだ見送りかな。
結局このケースが使いたかったんですよ。前のケースと比較して半分以下のサイズに、すっきりさっぱり。
新旧比較するとこんな感じ。CPUが10年前のSkylakeとか。そしてCPUは中古品…。
| 旧 | 新 | |
|---|---|---|
| CPU | Xeon E3-1220 (Haswell) | Xeon E3-1240L v5 (Skylake) |
| ChipSet | C204 | C232 |
| Memory | DDR3-1333 16GB | DDR4-2133 16GB |
| MotherBoard | Supermicro X9SCM-F | ASUS P10S-I |
| Onboard NIC | i82574L 1Gb | i210AT 1Gb |
色々あって、結果的に14年前のマザーの更新用に用意したのは10年前のマザーボード。バックアップのリチウム電池が、購入時には既に干上がってましたよ（でも新品）。今は後継機種はP13R-Iとかになってるんですが、とても手の出る価格帯じゃありません。そもそも日本向けには出荷ないっぽいし・・・。
こいつの素晴らしいトコは、ITXながら、ちゃんとOnBoardでSATAx6系統使えること。SASx1+SATAx2という変則的なコネクタながら、SASからSATAx4がちゃんと引き出せます。（逆にSASとしては使えない）
流石サーバー用というところは、BMC/IPMI機能が使えて（オプションモジュールが必要）、サーバー向けとしてコンデンサも長寿命の固体コンデンサを使用しているらしい。しかし、BMC/IPMIの利用に必要な別売りのモジュールはすでに廃盤。しかし、たまたま中古品を見つけたのがマザーを買う決め手になったり。
ただ、リモートKVMは例によってJavaアプリ使うやつだけど、古すぎて今時のOSじゃセキュリティリスクが云々と警告が出て全く使えない。使い物になるのはリモート監視とPowerOn/Off制御くらい。
結局、うちにはシリアルtoLAN（telnet）があり、しかもBIOSがちゃんとシリアルポートリダイレクトに対応していてるんで、それ経由してモニタ・キーボードレス運用にしています。シリアルポート経由でブート＞BIOS画面のあたりがチェックできます。
消費電力はさすが低電圧版CPU、HDD sleepに入るとIdle時21Wというのもなかなかいい感じ。巷のN100 PCでもシステム全体だとアイドルで10Wとかなんで、悪くないと思います。
| 旧 | 新 | |
|---|---|---|
| Power consumption | idle: 62W Peak:125W | idle:41W (HDDsleep 21W) Peak:74W |
新旧比較。上側がJonsobo N2、下側が旧ケース。
まぁまぁ良くできてるとは思います。塗装も裏側までしっかり。
スチール製なんで見た目よりも結構ずっしり。ツルツルテカテカな質感を期待してたのですが、届いたのはマット調というよりもざらざら、ちょっと安っぽい感じ。白を選んでみましたが黒の方が良かったかもしれません。
側面の一見ガバガバに見える通気口の裏側には、ちゃんとパンチングメッシュの網が裏から取り付けられています。ただ、色が黒固定なんで、白色だとちょっと目立つ。だけど天面の通気孔には何もついてません。ガバガバです。
ちょっとマズったなーと思ったのが、HDDの固定方法。こんな感じでゴムブッシュをネジで取り付けて、筐体側の溝に差し込むようにして取り付ける仕組み。このゴムブッシュの耐久性、大丈夫か？
ゴムブッシュ取り付けのネジも、奥まで締め込むとゴムブッシュ潰れてしまうんで、ゴムブッシュのゆるゆるの弾力を少し抑えるくらいで締めることに。そのうち緩んでこないか？
そして極め付けは、HDDをロックするような機構がなく、ただブッシュの摩擦でのみ止まっているだけ。まぁそこそこ硬いからすぐ抜けるってもんでも無いんですが、巷のHDDトレイ付きのリムーバブルスロットよりは、だいぶ不安な感じ。
構造的に、上半分にマザーが来るようになっています。エアフローは上側と下側で独立していて、唯一のケースファンは下側のHDDまわりしか換気しません。なので、CPUクーラーをファンレスにすると上半分がほとんど換気されないため、熱的に結構厳しいようです。
低電圧版のXeon E3-1240L v5（TDP25W）に2U用のでかいヒートシンクつけてファンレスにしてみたんですが、高負荷時は周囲20℃で最大コア温度80℃くらい。夏場は無理かもしれぬ・・・。
普通は、大手PCサプライメーカーのNAS完成品とか、それ以上の信頼性求めるならB2BモデルとかQNAP/ASUSTORとかで事足ります。なので、規格マザー（mATX/ITX）が使えるケース単品ってなると、どうしても市場がニッチになってしまう。
CaseEndという中華系？サイトで、容量別に分かれていていい感じに探すことができましたが、悲しいかな、この手の情報は日本語圏ではほとんど見かけなくなり、あってもかなり限定的になってしまいました…。
