2020/10/01(木)Sambaでファイルコピーに失敗し 0x80070032 エラーになる

Windows10からファイルをコピーしていると「予期しないエラーのため、ファイルをコピーできません」「エラー 0x80070032: この要求はサポートされていません」と表示される問題。

エラーの状況

  • コピー元: Windows 10
  • コピー先
    • Samba Version 4.9.5 on Linux
    • Filesystem NILFS2

この状況で大量のファイルをコピーしていると、一部のファイルやフォルダでエラーが発生します。

samba_0x80070032.png

ログの調査

  • Windows 7では起きていなかった。
  • Samba側のファイルシステムがext4だと起きない。

「log level=10」に設定して、ログを確認しみました。

set_ea_dos_attribute: Cannot set attribute EA on file AU.txt: Error = サポートされていない操作です
open_file_ntcreate: FILE_OPEN requested for file AU.txt and file doesn't exist.

ファイルの作成に失敗しているような感じです。

原因

Sambaは「store dos attributes = yes」のときに、DOS attributeと呼ばれるファイル属性を維持したままファイルを保存しようとします。

DOS attributeとは、Windows登場前の大昔に存在したファイル属性で、古くは「R,S,H,A」の4種類がありました。Windows時代になって不要となったものだと思っていたのですが、知らない間に拡張され続けていたようです……。

Windows では attrib コマンドによってファイル属性(DOS attribute)を確認または変更できます。*1

samba_attrib.png

このうち、比較的最近拡張された「X, P, U」属性があると、NILFSはこれらの属性値に対応していないためコピーに失敗します。

*1 : エクスプローラーのファイルのプロパティからでも確認できますが、その場合、なぜかX属性は表示されません。

解決策

smb.confに以下を設定します。

	store dos attributes = no

この設定のデフォルトは元々 no だったのですが、Samba 4.9(2018年9月)以降で yes に変更されています。

ext4等のファイルシステムは対応済のようですが、NILFSのようなメジャーではないファイルシステムを使用しているとこの問題に当たるかと思いますので、記録として残しておきます。

雑感

SambaはNTFSのファイルアクセス権限(NT ACL)等、ファイル属性をなるべく維持するように作られていて、ファイルシステム側もそれに対応できるよう拡張されてきた歴史があります。user_xattrでググると色々出てきます。

Linuxのシステム構造の中に、NTのアクセス権限やDOSのファイル属性が残るというのも不思議な感じですが、それが災いしてしまった事件でした。

どれだけ検索しても(海外含め)同じ不具合踏んでる人がいないので苦労しました……。

2020/07/05(日)NILFS使用時にLinux Kernelエラーが起こる問題の解決策

最近の新しいLinux KernelでNILFS(NILFS2)を使用すると、最初の書き込み時に

BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8

となるエラーの解決方法(対処療法)。

NILFSとは

ログ構造化ファイルシステムと言われる、ファイルを変更するたびに常にスナップショットを自動的に保存できるLinux標準サポートのファイルシステムです。

/home 以下などをNILFSにしておくと、間違えてファイルを書き換えたときや、間違えてファイルを削除したときに、1時間前や1週間前の状態に遡ってファイルを復元することができます。

間違ってファイルを削除(上書き)してまうこと、ファイルを直接変更してしまってから元に戻したいことは誰しもあると思いますが、NILFSならいつでも元に戻せるため人為的にミスにとても強く重宝しています。

新しいカーネルで動作不安定に

このNILFSですが、最近の(ここ1年ぐらいの)カーネルで動作不安定になる不具合があります。Debian 10.4をインストールした際にこの問題に当たってしまいました……。

調べるとカーネルのファイルキャッシュに対するちょっとした変更(パッチ)が原因となっているようです。解決策はLinux系のMLにありました(そしておそらく投稿者の記事)。

要約すると「NILFSをマウントする前に、ダミー書き込みをすれば良い」とのことです。

簡単な解決策

/etc/fstab では自動マウントせずに(noautoオプションをつける)、rc.localでマウントするように変更します。

dd if=/dev/sda6 of=/dev/sda6 count=1
mount /home

/dev/sda6 やマウント場所は該当のパーティション等に合わせてください。ddコマンドで512バイトほどダミー書き込みをしてからマウントします。たったこれだけで問題は解決します。

やや複雑な解決策

rc.local でマウントする方法では、NILFSパティーション以下にDBデータ等サービスで使用するデータを置く場合や/varがNILFSパーティションだった場合に問題があります。rc.local のタイミングでマウントするのでは遅すぎるからです。

ですので、理想としてはfstabでマウントする直前にダミー書き込みを実行したいのです。

Debian系のsystemd環境では以下のような設定ファイルを置くことで、fstab実行直前にダミー書き込みを実現できます。

# /etc/systemd/system/nilfs2-dummy-write.service
[Unit]
Description=NILFS2 dummy write
DefaultDependencies=no
After=local-fs-pre.target
Before=local-fs.target

[Service]
ExecStart=/bin/dd if=/dev/sda6 of=/dev/sda6 count=1
Type=oneshot

[Install]
WantedBy=sysinit.target

ファイル作成後、サービスとして認識されたか確認します。

# systemctl list-unit-files --type=service | grep dummy
nilfs2-dummy-write.service             disabled

認識されているようなら、サービスを有効にします。

# systemctl enable nilfs2-dummy-write
# systemctl list-unit-files --type=service | grep dummy
nilfs2-dummy-write.service             enabled

参考文献

まとめ

  • NILFS/NILFS2はとても便利なのに利用者が少ない。
  • パッチが出てるので、近々修正されるとは思う。
  • systemdの勉強になった。

2020/06/29(月)東芝、石窯ドーム スチームオーブンの分解・修理

東芝の石窯ドームオーブン(ER-PD3000)のスチーム機能が故障した時の修理の記録。分解方法メモ。

スチームが出ない

買って1年ぐらいでスチームが出なくなりました。スチーム機能を使おうとしたことが2回ぐらいしかなく、そもそもその時にきちんと動作してたのかすら記憶が曖昧なレベルです。

他社製オーブンだと「水抜き」を忘れると水の中のミネラル分が詰まってスチームが使えなくなるとのことで、掃除ぐらいで直れば良いなと思って分解しました。

結論としては全然違う故障原因だったわけですが。

ER-PD3000_001.jpg

続きを読む

2020/03/16(月)さくらVPS v5と歴代VPSのベンチマーク比較

さくらVPSのv5がリリースされ、さくらVPS v3が機器老朽化メンテナンスで物理層が入れ替わったので、まとめてテストしてみました。

UnixBench Version 5.1.3 index

計測コマンドは「./Run -i 5 -c 2」(2コアで計測)。

項目自宅サーバ512 v11G v31G v3'2G v41G v51G v3X
Dhrystone 24853.84412.13724.83837.24916.66313.46194.3
Whetstone1508.91148.01037.61199.21625.21861.81866.3
Execl Throughput1321.71592.51764.51288.51310.52461.42037.8
File Copy 10242058.61063.41705.62014.11867.02794.92549.9
File Copy 2561391.3747.31255.51183.61214.51779.81605.3
File Copy 40963560.21631.23501.62669.03665.46356.15756.8
Pipe Throughput1070.5--1087.0896.53006.43066.7
Context Switching505.2--692.4128.61727.21693.4
Process Creation1168.9--809.8613.81788.31632.1
Shell Scripts (1)3304.0--1920.82897.03936.23623.5
Shell Scripts (8)3318.1--2472.13343.14357.93994.2
SysCall Overhead653.8--639.2443.92200.62337.6
トータルindex1662.9--1424.41313.92876.32713.3
  • OSは Debian 10。
  • VPS 512/VPS 1G v3(メンテ前)は2013年2月計測。Debian 6。
    • 「Pipe Throughput」以降は、OS Versionによる影響が大きいため除外。*1
  • 自宅サーバ: Core i3 530 / 2.93GHz 2コア4スレッド / RAM 4GB / SSD
  • 1G v3: 石狩リージョン
  • 1G v3': 2020年2月の設備老朽化メンテナンス1回目後
  • 1G v3X: 2020年3月の設備老朽化メンテナンス2回目(物理層入れ替え)後
    • v5と同じ物理層になったと思われる。
  • 2G v4: 東京リージョン。仮想3コア。

*1 : おそらくCPU脆弱性関連の影響だと思われる。

ディスク性能計測

hdparm -t /dev/vda4
dd if=/dev/vda4 of=/dev/null bs=1M count=2048 iflag=nocache
dd if=/dev/zero of=/tmp/test bs=1M count=2048 oflag=direct
単位 MB/s家サーバ1G v32G v41G v51G v3X
haparm260480-600200200200
dd 2G read271200-500210210210
dd 2G write247100210210210
  • 家サーバ: SSD TOSHIBA THNSNJ128GCSU 128GB
  • VPS 1G v3は2020年2月の老朽化メンテ1回目の後。
    • read性能の値変動がとても大きい。*2
  • /tmp のファイルシステムはいずれも ext4
  • v4/v5は計測性能が 1MB/s もずれないので、おそらく帯域制限がかかっていると思われる。
  • VPS 1G v3Xは2020年3月の老朽化メンテ2回目(物理層入れ替え)後。
    • v4/v5と同じディスクになった模様。

*2 : 単時短に大容量を転送すると、一時的に速度を下げているように思われる。

結論

  • v3老朽化メンテナンス後は、v5と同じ物理層になったと思われる。
  • v5はv3/v4よりも性能が良い。
  • v4以降はディスク性能にリミットがかかっている。

乗り換え検討

「v3」と「v5」が同じ物なのに値段が高いのをどうにかしてほしい。「v5」のほうが安いじゃん!

  • さくらVPS 1G v3 (石狩): 10,267円
  • さくらVPS 1G v5 (石狩): 8,800円

長く使うなら面倒でも乗り換えたほうがよさそう。石狩DCはネットワーク遅延から少しだけ不利なんたけども、色々あって石狩継続しようかな。