ファイルシステム総合スレその19

**login:Penguin** · 2020/06/13(土) 14:45:47.76

● 前スレ
ファイルシステム総合スレその18
https://mao.5ch.net/test/read.cgi/linux/1514472651/l50

● 関連スレ
ジャーナリングファイルシステム
https://mevius.5ch.net/test/read.cgi/unix/979408065/l50

OpenSolaris/Illumos (OpenIndiana, etc.) 6
https://mevius.5ch.net/test/read.cgi/unix/1337411922/l50

FS関連スレ
https://medaka.5ch.net/test/read.cgi/os/1137387538/l50
過去スレ, 関連リンクは >>2-10 あたりで.

**login:Penguin** · 2021/04/28(水) 16:03:01.63

Btrfs楽やでホンマ

**login:Penguin** · 2021/04/28(水) 16:04:27.29

reiser4一択
ちょっとバラ肉にしたぐらいで開発者収監しすぎなんだよなあ

**login:Penguin** · 2021/05/05(水) 06:43:36.88

WindowsでもBtrfs様々やで
https://github.com/maharmstone/btrfs

**login:Penguin** · 2021/05/05(水) 13:25:13.38

Winはntfsが結構優秀だから要らんよ

**login:Penguin** · 2021/05/05(水) 13:40:15.01

NTFSはそこそこ優秀かも知れんが
管理するOSがWindowsではちょっとマンセーは無理

**login:Penguin** · 2021/05/05(水) 14:21:43.34

Windowsは互換性に関してはマジで凄い
Linuxで10年前のソフトを最新環境で動かそうとすると苦労するからね

**login:Penguin** · 2021/05/05(水) 17:44:23.14

Linuxはソースあるからね
emacs（1976年）もTeX（1978年）も現役

**login:Penguin** · 2021/05/05(水) 18:01:25.19

ed (1970年代前半) も sed(1973年) も一応現役

**login:Penguin** · 2021/05/05(水) 21:27:14.92

sed は一応でなくて、シェルスクリプトの一部のように使うだろ。

**208** · 2021/05/05(水) 21:39:56.99

そりゃそうか　俺も使うし
それも結構な頻度で愛用している

**login:Penguin** · 2021/05/07(金) 19:15:48.16

sedってコマンドなのかと思ってたわよ

**login:Penguin** · 2021/05/07(金) 19:27:04.20

viも同じようなもんよ

**login:Penguin** · 2021/05/28(金) 06:51:44.05

スレでもたまに名前が上がってたBcachefsって目的はすごい良いな、Btrfsが躓いてるからちょっと期待しちゃう

Bcachefs は、 Btrfs と ZFS の機能をよりクリーンなコードベース、より安定性、より高速、 GPL 互換のライセンスを提供することを目的とした次世代の CoW ファイルシステムです。

**login:Penguin** · 2021/05/28(金) 07:02:11.16

Bcachefs一時期毎月20ドル支援してたんだけど、Btrfsが良い感じになって来たので、支援止めちゃった

**login:Penguin** · 2021/05/30(日) 18:23:59.48

目指すだけならどこも凄い事を主張するからなあ・・・

**login:Penguin** · 2021/05/30(日) 21:33:08.26

openZFSが最新版でかなり高速化するらしい

**login:Penguin** · 2021/05/30(日) 23:07:19.53

速くする方法が分れば、他のファイルシステムも続くから頑張って欲しいな。

**login:Penguin** · 2021/06/08(火) 20:35:14.27

カーネル5.13でzstd関連のコードが刷新されるから
圧縮使ってる人は楽しみな更新になるね

**login:Penguin** · 2021/06/13(日) 12:57:08.28

Bcachefsの公式ページを読んだら
コードが綺麗ばかり主張していて、実際githubを覗いてみたら
確かに綺麗なのかもしれないけどコメントが少なすぎて誰も触れない事には変わりない感じだった。

**login:Penguin** · 2021/06/13(日) 19:11:57.13

$ sudo btrfs sub snap @ /media/user/debian/@
$ sudo btrfs sub snap @home /media/user/debian/@home

このコマンドの参考ページを教えて下さい

**login:Penguin** · 2021/06/13(日) 20:22:25.19

$ man 8 btrfs-subvolume

**login:Penguin** · 2021/06/18(金) 12:55:21.67

debianスレにも書いたんですが、ext5って開発されていないんですか？
ということはいずれどこも（debianも）btrfsかxfsになるんですか？

**login:Penguin** · 2021/06/18(金) 13:28:58.70

開発されない
ext4の改良が続いている

**login:Penguin** · 2021/06/19(土) 11:20:25.99

ちょっとお聞きしたいのですが、新規に買ってきた4TBの東芝製HDD(MN08ADA)をmkfs.ext4でフォーマットしてマウント(USB-HDDケースに入れています）すると、
何もファイル操作をしていないにもかかわらず頻繁にアクセスするのですが、(umountするとアクセスしなくなります）、
-O ^metadata_csumとしてフォーマットするとアクセスしないのですが、一体何が起きているのでしょう？
USB-HDDケースが行けないと思って内蔵SATAにしてみても動作は同じでした。
試しに最初の300MiBだけフォーマットしてマウントしてみたらしばらくアクセスした後、静かになりました。
metadata_csumの有り無しで変わるのですから、ココらへんがおそらく原因だとは思うのですが、4TB分チェックが何かが終わるまで待つしかないのでしょうか？

**login:Penguin** · 2021/06/19(土) 11:25:16.81

自己解決しました。おそらくext4lazyinitだと思います。
もうしばらく放置しておこうと思います。
ntfs、btrfsでは何も起きなかったのでハードウェアの故障はないと思っていたのですがやっぱりext4の機能でした。
どうも失礼しました。

**login:Penguin** · 2021/06/19(土) 15:25:22.43

完全にBtrfsブームが来ているな
FedraチームFacebookの全面バックアップは心強い

**login:Penguin** · 2021/06/20(日) 07:20:53.86

Btrfsのスワップファイルを使おうとしたけど
素で使うとスナップショット出来ない代わりに生データだし
暗号化スワップとして使うと今度はスナップショット可能になるという理不尽
そりゃFedoraも匙投げてスワップ自体を無効化しますわ
BtrfsにLVMを組み合わせてスワップパーティションを作るというダサい方法しかないし

**login:Penguin** · 2021/06/20(日) 08:59:55.55

変なことしないで普通にスワップパーティション切れば良いだけでは？

**login:Penguin** · 2021/06/20(日) 09:41:51.35

うちはデータ用のext4のパテに置いてるわ

**login:Penguin** · 2021/06/20(日) 10:39:15.38

>>229
やっぱりそうなるよね
Btrfsは消去する可能性のあるデータの扱いに絶望的に向いてない。

>>228
サブボリュームが便利だったから
スワップ問題さえなければBtrfsで大半賄えたから惜しかった。

**login:Penguin** · 2021/06/20(日) 10:47:38.20

>>230
> Btrfsは消去する可能性のあるデータの扱いに絶望的に向いてない。
うちは１年近くほぼ24h稼働させててビクともしないけどな
ラズパイでUSBx2+SDのストライピングと言うなんちゃってだけどさ

**login:Penguin** · 2021/06/20(日) 11:44:40.23

俺も4年近くBtrfsファイルサーバ運用してて、btrfs deviceコマンド使って何度もストレージ構成変更もしたけど、何も問題起こらないなぁ。
エンタープライズとかでは無いけどね

**login:Penguin** · 2021/06/20(日) 15:10:27.93

消去する可能性のあるデータはCoW有効だと断片化が進むからな
ここ1年くらい半導体不足だから難しいけどスワップが要るくらいならメモリもっと積むという手もある

最近はbtrfsも徐々に、使えるものになってきているのは確かだろう
職場で使われている「法人向けNAS」として販売されている製品がデータ領域デフォルトでbtrfsになってて当初はオイオイ大丈夫かと思ってたけど
今のところは大丈夫っぽい。ちなみに壊れても対処するのは俺じゃない（重要）

あとは、ディスクフルになるとヤバいなどという噂もあったが改善したのだろうかね。

**login:Penguin** · 2021/06/20(日) 15:12:33.54

いやスナップショットとCoWの関係で
削除できてるんだか出来てないんだか分かりにくいという意味ね。
CoW無効化したファイルでもスナップショットは取れるみたいだし
削除という方向では難しい。

**login:Penguin** · 2021/06/20(日) 15:15:33.95

>>233
CoWは前述の理由でファイルを削除したら逆に空き容量が減るパターンがあるから
ディスクフルだと危険だよ。
空き容量を増やそうとした操作で更に空き容量を減らしてドツボにはまる。

**login:Penguin** · 2021/06/20(日) 15:32:40.87

>>233
> ディスクフルになるとヤバいなどという噂
友人のラズパイ(うちのサブボリュームを暖簾分けしたもの)は
diskfullをやらかして起動不能になり涙で枕を濡らしてますた

**login:Penguin** · 2021/06/20(日) 15:46:21.40

スナップショットをという扱うという決断をした瞬間から
Btrfsの空き容量を増やす手順は複雑怪奇になる。

**login:Penguin** · 2021/06/20(日) 16:03:58.94

timeshift使うくらいならまだいいけど
色々と欲を出すと悲惨な目に遭いそう

なお私はconky出して常にディスク使用量を監視してます

**login:Penguin** · 2021/06/20(日) 17:26:59.08

残容量がそんなに気持ち悪い変動したこと無いなぁ

**login:Penguin** · 2021/06/20(日) 17:49:16.26

まあ一応ね

**login:Penguin** · 2021/06/20(日) 21:11:28.58

空き容量が一方通行なのは難易度高めだよね

**login:Penguin** · 2021/06/20(日) 21:15:36.56

そんなこと無いけどなあ
スナップショット全部始末して、それでも駄目ならfilesystem defrag -r
これで容量が戻らなかった事無いけど

**login:Penguin** · 2021/06/20(日) 21:29:09.11

スナップショット全部始末って・・・
まあ戻らないことはないだろうけどさぁ・・・
それデータ退避させて再フォーマットに次ぐ最終手段やん

**login:Penguin** · 2021/06/20(日) 21:36:52.57

俺の場合スナップショットはシステム改変前の保険や
send前の準備くらいにしか使ってないからねえ
もっと高度な事やってる人なら億劫だろうけど

**login:Penguin** · 2021/06/20(日) 21:42:05.45

それ正解。
非常に賢いBtrfsのお手本のような使い方。

**login:Penguin** · 2021/06/20(日) 21:47:09.44

スナップショットをバックアップのように使ってるのが間違いなのよ
バックアップは別に取ってスナップショットは定期的に整理すべき

**login:Penguin** · 2021/06/20(日) 22:02:17.88

Btrfsはバックアップも取りやすいしね

**login:Penguin** · 2021/06/20(日) 22:22:30.11

マウントしたまま完全なdumpが出来る様な感じですからね

**login:Penguin** · 2021/06/21(月) 01:24:02.85

>>247-248
スナップショットを tar で固めるだけだったら別に取りやすいって事は無いんじゃないの？

Btrfs はサブボリュームとかのメタ情報のバックアップができなくてバックアップが困難
と逆に感じたんだが

**login:Penguin** · 2021/06/21(月) 02:34:03.18

>>249
> スナップショットを tar で固めるだけだったら別に取りやすいって事は無いんじゃないの？
send/receive機能使った事無いのかな

> Btrfs はサブボリュームとかのメタ情報のバックアップができなくて
その様な些細な情報に拘るよりも
サブボリュームをリネームしておけば管理しやすいのに
そこまで完ぺきな状態保存をしたいならddでも使っときましょうかね

**login:Penguin** · 2021/06/21(月) 09:08:05.47

>>250
> send/receive機能使った事無いのかな

なるほど増分バックアップを取るという意味では dump に近い物があるのか
勉強になりました

> その様な些細な情報

メタ情報バックアップできないっておかしくない？
別の誰かが作ったシステムをクローンしたい時に dd しかないのは厳しいわ

ビジネスでやったらバックアップできないシステムを採用するのがおかしいって
後でぐじぐじ言われまくる(=言い訳レポートだの再発防止だの工数が爆発的に
増える)のが見えてるんで使えないよ

**login:Penguin** · 2021/06/21(月) 12:16:09.75

考えた方が違うんじゃないかな。
サブボリュームをほぼストレージとして見れば問題ないし、完全なコピーが欲しければddなりなんなり旧来の方法が取れないわけでもないし。
単にレイヤーと選択肢が増えただけだよ

**login:Penguin** · 2021/06/21(月) 15:53:15.32

Btrfsを本番で運用しているFacebookはどうしてるんだろうね

**login:Penguin** · 2021/06/23(水) 19:00:39.82

Btrfsでdiscard=asyncにしたら起動するたびにドライブの使用ランプがカリカリ始めたんだけど
これって他の人も同じ？

**login:Penguin** · 2021/06/29(火) 21:52:12.01

カーネル5.14でbtrfsが更に改良・高速化されるらしい
開発ラッシュやばい

**login:Penguin** · 2021/06/30(水) 00:02:44.48

もうBtrfsで良さそうだね
ネイティブ暗号化くらいしか弱点ないでしょ

**login:Penguin** · 2021/06/30(水) 04:50:09.03

あとRAIDが非推奨のままずっと放置されてる

**login:Penguin** · 2021/06/30(水) 05:54:37.78

RAIDはHBAかLVM使えばええやろ
ファイルシステムがやらなければいけないことではない

**login:Penguin** · 2021/06/30(水) 06:14:36.60

RAID10あたりは問題ないしね

**login:Penguin** · 2021/06/30(水) 09:02:44.67

スナップショット使うファイルシステムでHBAやLVMでのRAID-5/6はやめとけ
スナップショットはランダムリード/ライト多いから相性が悪い
使っているうちにフラグメンテーションで使い物にならなくなる

回避するためにはHBA使うのやめてRAID-Zだのそれに類似したVirtual系
RAIDの技術が必要なんだが実装ツラい割に効果も薄いんだろ

ラックマウントタイプのストレージ製品でもRAID-10でしか使わせない製品も
出始めてるし、業界としてRAID-5/6は切り捨てなんだとおもう

**login:Penguin** · 2021/06/30(水) 09:38:03.62

ファイルシステムによらず、RAID5はテラバイト級媒体にはそもそも使わない方が良い
障害復旧中に壊れていくのを数回見た
RAID6は知らない

**login:Penguin** · 2021/06/30(水) 11:26:56.84

RAIDZは広く使われてるよ
RAIDはストレージの可用性確保の手段なんだから代替方法なんかない

**login:Penguin** · 2021/06/30(水) 19:44:02.88

機能として存在する以上は安定してほしいよね

**login:Penguin** · 2021/06/30(水) 19:51:08.40

RAID関連は実績のあるファイルシステムでないと使う気にはならない

**login:Penguin** · 2021/06/30(水) 22:09:30.83

ファイルシステムの実績もだけどパーツ冗長(特にコントローラ)も必要だわ

HBAが中途半端に故障して壊れてもないHDDを故障扱いしまくってデータ
ロストさせた(実際はデータロストしてない)障害が一番厄介なトラブルだった

**login:Penguin** · 2021/07/01(木) 01:40:54.64

一般ユーザーがしないような構成を組むと
想像もしていなかったような不具合踏むことが多々あるわな

**login:Penguin** · 2021/07/04(日) 01:22:49.64

Btrfsはdiscardマウントオプションでまだ壊れた報告がチラホラあるね
とりあえず手動trimに切り替えた

**login:Penguin** · 2021/07/07(水) 20:02:33.20

Linux 5.14 Works Around Compatibility With Some Digital Camera exFAT File-Systems
www.phoronix.com/scan.php?page=news_item&px=Linux-5.14-exFAT

**login:Penguin** · 2021/07/23(金) 06:19:56.52

WindowsでBtrfs 【ファイルシステム】
https://mevius.5ch.net/test/read.cgi/win/1612888512/

**login:Penguin** · 2021/08/14(土) 11:15:08.22

Linux上で以前targetcliで作ったZVOL (/dev/zvol/mypool/fc0) が「使用中」状態に
なったままになってます。再起動してもOSを再インストールしても「使用中」状態です。

# zfs destroy mypool/fc0
cannot destroy 'mypool/fc0': dataset is busy
# umount /dev/zvol/mypool/fc0
umount: /dev/zvol/mypool/fc0: not mounted.

未使用の状態かそれが無理なら強制削除したいんですがどうしたらいいでしょうか？

**login:Penguin** · 2021/08/14(土) 12:12:14.38

>>270
解決しました。理由はイニシエータ側で作ったLVMをターゲット側が起動時に
自分のものとしていたため。

**login:Penguin** · 2021/08/15(日) 14:01:19.23

exFATがDebian11でサポートされるようになったらしいね　Debian newsにそう書いてあった

**login:Penguin** · 2021/08/21(土) 08:54:19.08

うーん、ZFSはイマイチですね・・・。
Proxmoxで3*HDDをRAIDZ1にして、2*SATA SSDをキャッシュにしてVMを作ったのですが、
前情報通りアクセスが増えるとメモリ消費量が10GBとか跳ね上がる・・・。
1200Mb/s出ていたものがカーネルパニック？で20Mb/sとかに落ち込んでしまう。
2GBのファイルをランダムコピーしたら、一瞬で終わるものと数十秒かかるものが発生。
うーん、ZFSはかなりじゃじゃ馬な印象です。メモリが潤沢にあれば良いのかも。
やはり記憶域スペースですかね・・・・。

**login:Penguin** · 2021/08/21(土) 11:04:11.49

確かに自分もデスクトップ用途で多目的に利用しているんだがバター FS の方が適してると考えるようになってきた

**login:Penguin** · 2021/08/21(土) 16:49:26.25

>>273
重複排除が有効になってたりしない?

**login:Penguin** · 2021/08/21(土) 17:05:17.20

今度、Debian11 インストールしようと思うが、Btrfs でいいのか。

**login:Penguin** · 2021/08/21(土) 19:31:29.41

コピーオンライトをファイル単位でユーザーが使えるのはバター FS だった

**login:Penguin** · 2021/08/29(日) 04:14:21.43

OpenZFS2.1で実装されたdRAIDってどうなの
再構築が高速なのは良いことだけど、その後新しいホットスペアを追加したら結局再構成が始まるんでは？
RAID-Z2と何が違うんだろ

**login:Penguin** · 2021/08/29(日) 09:40:27.05

openzfs-2.1.0
kernel-5.13
fedora34

ZFSで例えば2つのプールpool1, pool2 があるとして，ブート時にpool1は自動で
インポートしたいけどpool2はしたくない場合，どうすればいいですか？
<(_ _)>

**login:Penguin** · 2021/08/29(日) 15:01:28.74

>>278
いましがた dRAID の説明を初めて読んできた初心者なので参考まで

> その後新しいホットスペアを追加したら結局再構成が始まるんでは？

語弊がある書き方をするけど再構築が高速になるトレードオフとしてホットスペア
にデータを事前にデータを書き込んでおく(準備しておく)ってだけじゃん

リビルド中に２本目と３本目が相次いで壊れてデータロストするリスクを(リビルドを
高速化することで)回避するためのものだから効率が悪い・二度手間な処理を行う
のは至極まっとうな話では？

> dRAIDってどうなの

全てのディスクを均等に使用してしまうことによって HDD/SSD の故障時期が重な
る可能性が高まるという点で逆にリスクを上げてるアホな仕組みだと思った

商用の FS (NetApp や Isilon, Spectrum Scale FS) において同じ仕組みは個人的
には聞いたことが無いので期待できない

> RAID-Z2と何が違うんだろ

いや、RAID-Z や RAID-Z2 に対してホットスペアをどうするかのオプションだから
違うとかじゃなくて「dRAID 構成の RAID-Z2」とか「dRAID 構成ではない RAID-Z2」
とかそんな感じで別物ではないぞ？

**login:Penguin** · 2021/08/29(日) 17:27:42.09

>>280
RAID-Z2 と RAID-Z＋dRAIDホットスペア1本はほぼ一緒では？と言いたかった。

ホットスペア本数に制限がないので、冗長度を好きなだけ上げられてかつread性能も上がるのが利点なのかな？

商用はIBMが既にやってるらしいけどね。

**login:Penguin** · 2021/08/29(日) 18:07:19.22

RAID再構築とdRAIDのホットスペア追加の違いをもう少し考えてみた
RAID再構築はパリティ再計算のために、生き残ったドライブの全データを読み込む必要がある？が
dRAIDは追加スペア分の空き容量を生き残ったドライブに分配するだけなので、生き残りがn本なら各ドライブ1/(n+1)のデータだけ読めばよい？
あとパリティ計算がいらない。

あれ？割と良いのでは？

**login:Penguin** · 2021/08/29(日) 18:18:49.26

>>282
> RAID再構築とdRAIDのホットスペア追加の違いをもう少し考えてみた

流石に比較が間違ってるだろ、それ

RAID-Z + ホットスペアも dRAID 構成の RAID-Z2 も HDD が壊れた直後
にRAID再構築が実施されるのであってホットスペアを補充するタイミング
じゃない

dRAID の場合はそれに加えてホットスペアを補充した際にも再ストライプ
目的で２回目の再構築が走る＝つまり２度手間

dRAID の１回目の再構築の際にはパリティ計算している
だから２回目の再構築の時は不要ってだけだ

パリティが要らないっておかしいと思えよ

**login:Penguin** · 2021/08/29(日) 18:43:20.22

失礼
× パリティが要らないっておかしいと思えよ
○ パリティ計算が要らないっておかしいと思えよ

> 商用はIBMが既にやってるらしいけどね。

Erasure Code Edition って新しい別構造の奴か
確かに Spectrum Scale でスペアを仮想化するって事が可能ってあるね

**login:Penguin** · 2021/08/29(日) 19:01:05.63

>>283
>RAID-Z + ホットスペアも dRAID 構成の RAID-Z2 も HDD が壊れた直後
>にRAID再構築が実施されるのであってホットスペアを補充するタイミング
>じゃない

いやもちろんそれはわかってるけど
dRAIDの場合は再構築もディスク読み書きが分散されるからまあ気にしなくていいかと思った。
けど分散されて早くなるってだけで読み書きする総量は変わらないのか…

**login:Penguin** · 2021/08/29(日) 19:08:49.26

>>279
pool2のcanmountプロパティにnoautoをセットかな

**login:Penguin** · 2021/09/09(木) 15:30:55.07

LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言
Liam Tung （Special to ZDNet.com）翻訳校正：編集部 2021-09-08 14:01
https://japan.zdnet.com/article/35176373/

**login:Penguin** · 2021/09/09(木) 16:08:17.82

ファックファック言わなくなってる…😳

**login:Penguin** · 2021/09/09(木) 17:02:00.90

linuxで作ったntfsドライブがwindows10で読み込めない
ディスクをアタッチして起動するとフォーマットするか聞いてくる
linux側から見るとデータが書き込まれてるのに

**login:Penguin** · 2021/09/10(金) 11:20:22.80

>>289
チャレンジャーだなぁ。

**289** · 2021/09/10(金) 12:20:17.15

色々試したけど結局フォーマットした
ネットだとwindowsからlinuxで読めないトラブルはあるんだけど逆はあんまり出てこないんだよね
フォーマットしたディスクはlinuxで一応読み込めたけど気づいた事がある
ディスク丸ごとフォーマットしたはずなのに何故か数メガの未使用領域が出来てる
これが関係してんのか？

**login:Penguin** · 2021/09/10(金) 14:37:10.89

>>289 >>291
断定できないが蓋然性として高い要因は、NTFSのログ構造(LFS)がWindows7以前がver1.1、
Windows8以後がver2.0と更新している関係で出る不具合。これはWindows同士でも起こり得る
トラブルの一つで、LinuxのNTFS-3Gドライバはver1.1準拠なので、同様の事情(>>287の新・
標準ドライバがこの件を解決しているかは、知らないが)。以下、詳細は↓。

NTFS-3G - ArchWiki
https://wiki.archlinux.jp/index.php/NTFS-3G

**289** · 2021/09/10(金) 15:39:43.90

>>292
情報thanks

確かにwindows7の頃はこの手の問題に遭遇したことはないな

**login:Penguin** · 2021/09/10(金) 16:41:55.52

>>292
それならば、Linuxで作成したVer1.1のNTFSが、より新しいバージョンにも対応しているWindows 10で読めないということはないはずで、
>>289の言っている問題を説明するものではない。

そのLFSのバージョンが問題になるのは、Windows 10等新しいWindowsからNTFSのディスクを、「安全に取り外す」をしないで取り外し、
Windows 7等古いWindowsに接続した場合。
「安全に取り外す」と、Windowsは当該NTFSのLFSをVer1.1に変換するので、問題は起こらないが、
しないでいきなり外すと、古いWindowsはLFSを解釈できないので、最近の操作が適用されていないように見えるなどの不具合が発生する・・・とのこと。

**login:Penguin** · 2021/09/10(金) 17:32:25.87

>>294
蓋然性が高い要因を挙げただけで、他にないとは書いてないが。>>292で紹介したリンク
(NTFS-3G - ArchWiki)の"トラブルシューティング"に、Windows8・10の別の不具合もしっかり
記述してある。人に難癖つける前に、確認すべき。

**289** · 2021/09/10(金) 20:08:27.27

色々試してわかった
ディスク丸ごとだと駄目でパーティションを作ってフォーマットすると読み込む事が出来る

**289** · 2021/09/10(金) 20:19:19.59

>>294
>>295
お騒がせして申し訳ないｗ
けどこれがntfsのバージョン関係してるのかはわからない
win7で試したいけど環境ないんでね

**login:Penguin** · 2021/09/12(日) 19:56:44.85

初心者スレから誘導されてきました。

HDD４台構成のraidz1がデグレードになってしまい慌てて交換用HDDに取り替えたのですがうまくリビルドができないです
交換用のHDDが/dev/sdeで「zpool replace tank 14576820926089804651 /dev/sde」を実施しても
cannot replace 14576820926089804651 with /dev/sde: already in replacing/spare config; wait for completion or use 'zpool detach'と出るだけでリビルドが走っている様子も見えません
この場合、どのようにすればリビルドを開始することができるのでしょうか？教えてください

**login:Penguin** · 2021/09/12(日) 20:49:07.39

>>298
真の有識者が来るまでの時間稼ぎにしかならないかもだけど取り敢えず
losetupでループアタッチしたプールでは当然ながら問題無かった
再同期やscrub等が動いていない事を確認し、不良ディスクをzpool offline tank 数字してから
replaceしてみては如何だろうか

自分だったらだけど、まだDEGRADEDで済んでいるうちにスナップショット取って
余裕のあるディスクへzfs sendで退避した上でプール作り直してしまうけど

**login:Penguin** · 2021/09/22(水) 20:53:27.48

Linux板のくだ質スレから誘導されました。
現在、CentOS+btfs&snapperの自作NASを課内で使っています。
スナップは1時間毎で、直近の2週間と月1を残し続けています。

現行
メイン機（上記のマシン）
サブ機（rsyncで毎晩丸ごとメイン機のデータを取得。メイン機が壊れた場合の保険）

希望
メイン機をサブに回して、新規で高速なNASを作成したいです。
どのようなファイルシステムを選ぶのが良いか、アドバイスを貰えたらと思っています。

新メイン機は下記のハードを用意しています。
0. Ryzen Pro 1700 or 3600, 2x16GB@3200MEM
1. SataSSD128GB（OS）
2. NVMeSSD512GB（R3年度ファイルを保存する作業フォルダ）
3. CMR8TB（過年度のファイルを保存）
4. CMR8TB（rsyncで2,3番を毎晩バックアップ）

質問
1番はどの鳥が良いでしょうか？現行機はCentOSです
2番は現行機と同じルールでスナップを撮りたいです。fsは何が良いでしょうか？
3番はスナップは不要と思っています。現行機は過年度のデータもスナップ対象でした。

3,4番はext4で構わないと思っていますが、1番の鳥と2番のfsに何を選べば良いかアドバイス貰えると嬉しいです。

よろしくお願いします。

ファイルシステム総合スレ その19

ファイルシステム総合スレその19