ファイルシステム総合スレ その19
いやスナップショットとCoWの関係で 削除できてるんだか出来てないんだか分かりにくいという意味ね。 CoW無効化したファイルでもスナップショットは取れるみたいだし 削除という方向では難しい。 >>233 CoWは前述の理由でファイルを削除したら逆に空き容量が減るパターンがあるから ディスクフルだと危険だよ。 空き容量を増やそうとした操作で更に空き容量を減らしてドツボにはまる。 >>233 > ディスクフルになるとヤバいなどという噂 友人のラズパイ(うちのサブボリュームを暖簾分けしたもの)は diskfullをやらかして起動不能になり涙で枕を濡らしてますた スナップショットをという扱うという決断をした瞬間から Btrfsの空き容量を増やす手順は複雑怪奇になる。 timeshift使うくらいならまだいいけど 色々と欲を出すと悲惨な目に遭いそう なお私はconky出して常にディスク使用量を監視してます そんなこと無いけどなあ スナップショット全部始末して、それでも駄目ならfilesystem defrag -r これで容量が戻らなかった事無いけど スナップショット全部始末って・・・ まあ戻らないことはないだろうけどさぁ・・・ それデータ退避させて再フォーマットに次ぐ最終手段やん 俺の場合スナップショットはシステム改変前の保険や send前の準備くらいにしか使ってないからねえ もっと高度な事やってる人なら億劫だろうけど それ正解。 非常に賢いBtrfsのお手本のような使い方。 スナップショットをバックアップのように使ってるのが間違いなのよ バックアップは別に取ってスナップショットは定期的に整理すべき マウントしたまま完全なdumpが出来る様な感じですからね >>247-248 スナップショットを tar で固めるだけだったら別に取りやすいって事は無いんじゃないの? Btrfs はサブボリュームとかのメタ情報のバックアップができなくてバックアップが困難 と逆に感じたんだが >>249 > スナップショットを tar で固めるだけだったら別に取りやすいって事は無いんじゃないの? send/receive機能使った事無いのかな > Btrfs はサブボリュームとかのメタ情報のバックアップができなくて その様な些細な情報に拘るよりも サブボリュームをリネームしておけば管理しやすいのに そこまで完ぺきな状態保存をしたいならddでも使っときましょうかね >>250 > send/receive機能使った事無いのかな なるほど増分バックアップを取るという意味では dump に近い物があるのか 勉強になりました > その様な些細な情報 メタ情報バックアップできないっておかしくない? 別の誰かが作ったシステムをクローンしたい時に dd しかないのは厳しいわ ビジネスでやったらバックアップできないシステムを採用するのがおかしいって 後でぐじぐじ言われまくる(=言い訳レポートだの再発防止だの工数が爆発的に 増える)のが見えてるんで使えないよ 考えた方が違うんじゃないかな。 サブボリュームをほぼストレージとして見れば問題ないし、完全なコピーが欲しければddなりなんなり旧来の方法が取れないわけでもないし。 単にレイヤーと選択肢が増えただけだよ Btrfsを本番で運用しているFacebookはどうしてるんだろうね Btrfsでdiscard=asyncにしたら起動するたびにドライブの使用ランプがカリカリ始めたんだけど これって他の人も同じ? カーネル5.14でbtrfsが更に改良・高速化されるらしい 開発ラッシュやばい もうBtrfsで良さそうだね ネイティブ暗号化くらいしか弱点ないでしょ RAIDはHBAかLVM使えばええやろ ファイルシステムがやらなければいけないことではない スナップショット使うファイルシステムでHBAやLVMでのRAID-5/6はやめとけ スナップショットはランダムリード/ライト多いから相性が悪い 使っているうちにフラグメンテーションで使い物にならなくなる 回避するためにはHBA使うのやめてRAID-Zだのそれに類似したVirtual系 RAIDの技術が必要なんだが実装ツラい割に効果も薄いんだろ ラックマウントタイプのストレージ製品でもRAID-10でしか使わせない製品も 出始めてるし、業界としてRAID-5/6は切り捨てなんだとおもう ファイルシステムによらず、RAID5はテラバイト級媒体にはそもそも使わない方が良い 障害復旧中に壊れていくのを数回見た RAID6は知らない RAIDZは広く使われてるよ RAIDはストレージの可用性確保の手段なんだから代替方法なんかない RAID関連は実績のあるファイルシステムでないと使う気にはならない ファイルシステムの実績もだけどパーツ冗長(特にコントローラ)も必要だわ HBAが中途半端に故障して壊れてもないHDDを故障扱いしまくってデータ ロストさせた(実際はデータロストしてない)障害が一番厄介なトラブルだった 一般ユーザーがしないような構成を組むと 想像もしていなかったような不具合踏むことが多々あるわな Btrfsはdiscardマウントオプションでまだ壊れた報告がチラホラあるね とりあえず手動trimに切り替えた 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 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. 未使用の状態かそれが無理なら強制削除したいんですがどうしたらいいでしょうか? >>270 解決しました。理由はイニシエータ側で作ったLVMをターゲット側が起動時に 自分のものとしていたため。 exFATがDebian11でサポートされるようになったらしいね Debian newsにそう書いてあった うーん、ZFSはイマイチですね・・・。 Proxmoxで3*HDDをRAIDZ1にして、2*SATA SSDをキャッシュにしてVMを作ったのですが、 前情報通りアクセスが増えるとメモリ消費量が10GBとか跳ね上がる・・・。 1200Mb/s出ていたものがカーネルパニック?で20Mb/sとかに落ち込んでしまう。 2GBのファイルをランダムコピーしたら、一瞬で終わるものと数十秒かかるものが発生。 うーん、ZFSはかなりじゃじゃ馬な印象です。メモリが潤沢にあれば良いのかも。 やはり記憶域スペースですかね・・・・。 確かに自分もデスクトップ用途で多目的に利用しているんだがバター FS の方が適してると考えるようになってきた 今度、Debian11 インストールしようと思うが、Btrfs でいいのか。 コピーオンライトをファイル単位でユーザーが使えるのはバター FS だった OpenZFS2.1で実装されたdRAIDってどうなの 再構築が高速なのは良いことだけど、その後新しいホットスペアを追加したら結局再構成が始まるんでは? RAID-Z2と何が違うんだろ openzfs-2.1.0 kernel-5.13 fedora34 ZFSで例えば2つのプールpool1, pool2 があるとして,ブート時にpool1は自動で インポートしたいけどpool2はしたくない場合,どうすればいいですか? <(_ _)> >>278 いましがた dRAID の説明を初めて読んできた初心者なので参考まで > その後新しいホットスペアを追加したら結局再構成が始まるんでは? 語弊がある書き方をするけど再構築が高速になるトレードオフとしてホットスペア にデータを事前にデータを書き込んでおく(準備しておく)ってだけじゃん リビルド中に2本目と3本目が相次いで壊れてデータロストするリスクを(リビルドを 高速化することで)回避するためのものだから効率が悪い・二度手間な処理を行う のは至極まっとうな話では? > dRAIDってどうなの 全てのディスクを均等に使用してしまうことによって HDD/SSD の故障時期が重な る可能性が高まるという点で逆にリスクを上げてるアホな仕組みだと思った 商用の FS (NetApp や Isilon, Spectrum Scale FS) において同じ仕組みは個人的 には聞いたことが無いので期待できない > RAID-Z2と何が違うんだろ いや、RAID-Z や RAID-Z2 に対してホットスペアをどうするかのオプションだから 違うとかじゃなくて「dRAID 構成の RAID-Z2」とか「dRAID 構成ではない RAID-Z2」 とかそんな感じで別物ではないぞ? >>280 RAID-Z2 と RAID-Z+dRAIDホットスペア1本はほぼ一緒では?と言いたかった。 ホットスペア本数に制限がないので、冗長度を好きなだけ上げられてかつread性能も上がるのが利点なのかな? 商用はIBMが既にやってるらしいけどね。 RAID再構築とdRAIDのホットスペア追加の違いをもう少し考えてみた RAID再構築はパリティ再計算のために、生き残ったドライブの全データを読み込む必要がある?が dRAIDは追加スペア分の空き容量を生き残ったドライブに分配するだけなので、生き残りがn本なら各ドライブ1/(n+1)のデータだけ読めばよい? あとパリティ計算がいらない。 あれ?割と良いのでは? >>282 > RAID再構築とdRAIDのホットスペア追加の違いをもう少し考えてみた 流石に比較が間違ってるだろ、それ RAID-Z + ホットスペアも dRAID 構成の RAID-Z2 も HDD が壊れた直後 にRAID再構築が実施されるのであってホットスペアを補充するタイミング じゃない dRAID の場合はそれに加えてホットスペアを補充した際にも再ストライプ 目的で2回目の再構築が走る=つまり2度手間 dRAID の1回目の再構築の際にはパリティ計算している だから2回目の再構築の時は不要ってだけだ パリティが要らないっておかしいと思えよ 失礼 × パリティが要らないっておかしいと思えよ ○ パリティ計算が要らないっておかしいと思えよ > 商用はIBMが既にやってるらしいけどね。 Erasure Code Edition って新しい別構造の奴か 確かに Spectrum Scale でスペアを仮想化するって事が可能ってあるね >>283 >RAID-Z + ホットスペアも dRAID 構成の RAID-Z2 も HDD が壊れた直後 >にRAID再構築が実施されるのであってホットスペアを補充するタイミング >じゃない いやもちろんそれはわかってるけど dRAIDの場合は再構築もディスク読み書きが分散されるからまあ気にしなくていいかと思った。 けど分散されて早くなるってだけで読み書きする総量は変わらないのか… >>279 pool2のcanmountプロパティにnoautoをセットかな LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 Liam Tung (Special to ZDNet.com) 翻訳校正: 編集部 2021-09-08 14:01 https://japan.zdnet.com/article/35176373/ linuxで作ったntfsドライブがwindows10で読み込めない ディスクをアタッチして起動するとフォーマットするか聞いてくる linux側から見るとデータが書き込まれてるのに 色々試したけど結局フォーマットした ネットだとwindowsからlinuxで読めないトラブルはあるんだけど逆はあんまり出てこないんだよね フォーマットしたディスクはlinuxで一応読み込めたけど気づいた事がある ディスク丸ごとフォーマットしたはずなのに何故か数メガの未使用領域が出来てる これが関係してんのか? >>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 >>292 情報thanks 確かにwindows7の頃はこの手の問題に遭遇したことはないな >>292 それならば、Linuxで作成したVer1.1のNTFSが、より新しいバージョンにも対応しているWindows 10で読めないということはないはずで、 >>289 の言っている問題を説明するものではない。 そのLFSのバージョンが問題になるのは、Windows 10等新しいWindowsからNTFSのディスクを、「安全に取り外す」をしないで取り外し、 Windows 7等古いWindowsに接続した場合。 「安全に取り外す」と、Windowsは当該NTFSのLFSをVer1.1に変換するので、問題は起こらないが、 しないでいきなり外すと、古いWindowsはLFSを解釈できないので、最近の操作が適用されていないように見えるなどの不具合が発生する・・・とのこと。 >>294 蓋然性が高い要因を挙げただけで、他にないとは書いてないが。>>292 で紹介したリンク (NTFS-3G - ArchWiki)の"トラブルシューティング"に、Windows8・10の別の不具合もしっかり 記述してある。人に難癖つける前に、確認すべき。 色々試してわかった ディスク丸ごとだと駄目でパーティションを作ってフォーマットすると読み込む事が出来る >>294 >>295 お騒がせして申し訳ないw けどこれがntfsのバージョン関係してるのかはわからない win7で試したいけど環境ないんでね 初心者スレから誘導されてきました。 HDD4台構成の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'と出るだけでリビルドが走っている様子も見えません この場合、どのようにすればリビルドを開始することができるのでしょうか?教えてください >>298 真の有識者が来るまでの時間稼ぎにしかならないかもだけど取り敢えず losetupでループアタッチしたプールでは当然ながら問題無かった 再同期やscrub等が動いていない事を確認し、不良ディスクをzpool offline tank 数字 してから replaceしてみては如何だろうか 自分だったらだけど、まだDEGRADEDで済んでいるうちにスナップショット取って 余裕のあるディスクへzfs sendで退避した上でプール作り直してしまうけど 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に何を選べば良いかアドバイス貰えると嬉しいです。 よろしくお願いします。 どんなファイルが多いとか、普段の使い方とか、現状どんな時に不足を感じるかとか、性能測定が必要では? btrfsから(比較すると機能の少ない)ext4に変更したいというからには細かいファイルが多いのかな? これまでCentOS使いということはサポート長いほうが良いだろうからDebian系に抵抗なければUbuntuサーバが良いのでは? CentOS で btrfs つかっていたけど RHEL 系が btrfs のサポートやめちゃったから 別のディストリに移って btrfsを使うか、RHEL系のままスナップショットありの別の FS に移行するべきかって話でしょ。 4. でバックアップ体制があるなら多少不安定な奴を選択しても良い状態だから 好きなの選べばいいんじゃないかな。 個人的には opensuse で btrfs ってのが一番理解を得られる線だと思う。 Oracle LinuxにしてUnbreakable Enterprise Kernel使えばbtrfsのサポートを(Oralceが)やってるぞ サポート申し込まなくても機能としては使える Oracleは好き嫌いが分かれるので、あくまで選択肢の1つとして・・・ということでお願いします みなさまありがとうございます。 説明不足がある中で、面倒なこちらの状況を把握して、明快なアドバイスで助けてくださったことに、感謝しています。 SuSEのサーバ利用は私の中で盲点でした。 サーバではOracle含むCentOS代替系が慣れの面で楽だとは思っていましたが、 好きなのを選べば良いと言って貰えると、今回はopensuse+btrfsでやってみます。 SuSEは学生時代に使っていた9.3振りです。大変にありがとうございました。 ddrescue 絡みで以下 $ sudo mount -o subvol=@ /dev/loop0p2 /mnt $ sudo btrfs scrub start /mnt scrub started on /mnt, fsid 98d2193c-b09e-4f8b-b78d-dc9ff9906263 (pid=1929) << scrub が一瞬にして終わり、 $ watch sudo btrfs scrub status /mnt $ Every 2.0s: sudo btrfs scrub status /mnt kyo: Sat Sep 25 13:17:40 2021 scrub status for 98d2193c-b09e-4f8b-b78d-dc9ff9906263 scrub started at Sat Sep 25 13:17:35 2021 and was aborted after 00:00:00 << この行からまったくスクラブしてないことが読み取れる total bytes scrubbed: 0.00B with 0 errors 次はどうすればよいですか? windowsでNTFS圧縮したフォルダってlinuxで使うと問題あるのかな? linuxでNTFSを扱う事にリスクがあるのは知ってるけど圧縮する事でそのリスクがさらに大きくなったりするのかどうか >>308 昔、PC-DOSに標準付属だったFAT16ファイルシステム圧縮ソフトを使ってたが、他のシステムと互換性が無くてファイル交換に困った。 あまり特殊な機能を使うと、Windowsの異なるバージョン間でもファイルの読み書きが出来なくなる可能性が有るから、あまりオススメはしない。 XP時代にあれだけ推していたダイナミックディスクがdepricatedになったみたいにね。 Linuxの事は知らんん。 >>308 ZFS等の他のファイルシステムのファイル圧縮機能を使って、Samba等のCIFS系でネットワーク越しに共有するとかでは駄目なの? そもそもLinuxのNTFSサポート(特にrw)はリバースエンジニアリングの賜物だし、あんまり信用しない方がいいと思うけどなあ。カーネルモジュールのroで使うのが無難だと思うよ。 こないだMSと契約してて仕様見れる企業がLinux用ドライバ書いてくれたとかなかったっけ? でもMSが書いてるわけじゃないからねえ。btrfsとか仕様を自分たちだけで決めて実装してるものだって、完璧ではないわけだし、 ファイルシステムは個人的には枯れてることや、トラブルシュートのノウハウの蓄積が重要かなと思う。 まあAPFSを普段使ってて何言ってるんだって感じだが、ユーザーはめちゃ多いからなあ。 >>314 FAT32実装でも完璧になることはほぼないよ >>315 うん、だからext4とかxfsとかしか使わないよ。 NTFSマウントしたかったらVM経由でCIFSマウントするわ。 クライアントマシンのルートパーティションをBtrfsからext4に戻してみた 扱い簡単だし日々のバックアップなんかdumpで十分じゃねとか思って Fedoraの傾向からすると 今後はバックアップだけじゃなくて高速化でもBtrfsの機能を活用する方向だから 新しいディストリを使うならBtrfsにしておいたほうが良い さすがFSスレ住民 未来を見据えてらっしゃる 再フォーマット&データリストアはワケないんで近いうちに出戻りBtrfsやるかも知れないっす Facebookの全面協力で安定してきたから 最新のカーネルを扱えるならBtrfsでも良いけど DebianやRHELクローンだとカーネルが古いからBtrfsは早いかな Debian11を使用中なんですが、 > DebianやRHELクローンだとカーネルが古いからBtrfsは早いかな との事なのでZFSを仕込んでみました https://i.imgur.com/ND3SXwC.png ZFSはメモリ消費が激しすぎてイマイチでしょ。 最近のBtrtfsのメリットは Btrfsを前提とした周辺機能が充実してきた事。 例えばFedora35からはソフトウェアの更新がBtrfsで高速化される事になった。 ちょっと前まではbtrfsディスっとけばできる男を演出できてたけど 最近はbtrfsを褒めるほうが有能そうな雰囲気出せる時代になってきたん? 俺は一貫してBtrfsの素晴らしさを讃えてきたので……というのはともかく、風向きが変わってきたなとは思う 昔から壊れるという欠点を除けば素晴らしいファイルシステムだった。 最近のカーネルでその欠点が急速に改善されているからメインでOKという流れ。 FedoraがデフォルトをBtrfsにしたのに阿鼻叫喚になっていないし本当に安定してきてるんだと思うね。 最近のカーネルにCentOS 8の4.18はともかく、debian 11の5.10は含まれないの ZFSがメモリ食いなんてまだ言ってる人いるんだくらいの感想 カーネル5.4で安定化したらしいからdebian11なら大丈夫じゃない? それ以降のカーネルでも高速化が入っていたりするから新しいに越したことはないだろうけど あとは透過圧縮で利用するzstdの改善が5.13で入った 安定面ではなくパフォーマンス面で考えるとカーネル5.10だともったいない気がする ZFSはまあまあメモリ食う時もあるけどあまり気にした事ないな 心配ならARC制限すればいいし Btrfsはパフォーマンスが上がるのか 個人レベルでは問題視する様な不具合は見てないし今後がますます楽しみ >>329 知らなかったから調べてみたらBtrfsでzstd圧縮を利用している場合5〜15%パフォーマンスアップとあるね。必須とまでは言わないけど、あれば嬉しい感じ ext4でcrc32c_intelが有効になっているか確認する方法ありますか? カーネルモジュールは組み込まれていて、 dumpe2fs -hで見ると、crc32cとだけ表示されています。 intelの使ってるのでしょうか…? read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる