ファイルシステム総合スレ その19
mostly OK: safe for general use, there are some known problems that do not affect majority of users これとか、英語オモシロって読んだけど。 ZFSにLinuxとFreeBSDの独立したデータセットをつくってマルチブートしてるんだが Linux使用後にFreeBSDを使うには一旦FBSDインストールメディアでimportする必要がある この手間さえ無ければZFSになんの不満も無いんだよなあ あとZFSはストレージプールからのデバイスの削除ができない。デバイスを誤って追加した場合でも、削除はできない。 btrfsは一応削除できる。削除しようとしているデバイス上のデータを他のデバイスに移動させる時間がかかるけど。 デバイスの削除ってあまり使われない機能なん? 単純なストライピング(RAID0)の場合なら zfs remove でできるけど 正確には zpool remove ストレージプール ブロックデバイス ZFSで、別のマシンで同じpool名で使ってたディスクを同じマシンに付けた場合、どうやってimportするんでしょうか? ちょっと質問文が紛らわしいので私なりに整理 マシン1にてtankというpool名でimportしていたZFSパーティション or ZFSアレイがあるとする ↓ マシン1をshutdownし、プールtankとして使用しているストレージをマシン2へ接続する ↓ 稼働しているマシン2にてプール名はそのままにtankをimportしたい こういう事なら実施命令は簡単 # zpool import -f tank 説明不足ですみません。 disk1: マシン1で tank として使用中 disk2: マシン2で tank として使用中 の状態で、 disk2 をマシン2から取り外し、マシン1に取り付け、importする方法、の意図でした。 目的はdisk2のtankからのデータのサルベージです。 こちらは仮想ストレージで構成を再現したものです 現在の構成はおおよそこんな感じという事ですかな tps://i.imgur.com/lqqmoNP.png ブロックデバイスの状態・予定サルベージ先ストレージ等不明かつ当方に時間の余裕が無い為 申し訳ございませんが実際のサルベージ手順は他の方のご回答をお待ち下さい あ、違うな マシンが2つあってzpool(非RAID)も2つあり、どちらもpool名がtankという事か tank(disk2)の状態を提示し回答をお待ち下さいませ 状態の信憑性を高める為に、状態提示は端末エミュレータのスクショ貼りがおすすめです ありがとうございます。 調べたところ、zpool import poolname newname でいけそうな感じでした。 仮想環境で試してみようと思います。 物理環境があってサルベージが目的なのに仮想環境で試すとはこれ如何に 物理には同じ名前のプールがあるから物理でやる前に試すってことじゃないかな? BtrfsからZFSに出戻ったわ 特にスナップショット使いが難くてダメだった 子データセット(Btrfsだとサブボリューム)がある時の一括バックアップの使い勝手は ZFSに軍配があがるなー zfsの実際のrecord sizeはいつ決まるのでしょうか? ググった範囲では、record sizeは(dataset指定サイズの範囲で)動的に決まる、決まったあとは変更されない(再作成が必要)、と認識してます。 ファイル書き込みはwrite(2)やfwrite(3)で行われると思うのですが、全てのプログラムが大きなバッファを用意しているとは限らない気がしてます。 zfsにはwriteback用にtxgという領域があるようですが、非同期書き込みのreocrd sizeはtxgがflushされる際に決定されるのでしょうか? (もしそうであれば、同期書き込みはfsync(2)時に決定?) NTFSクラスタサイズを後から変更するにはどのような方法があります? フリーで探し手いるのですが、minitool や aomei無料版は非対応のようで。り Linux 6.2 Aims To Ship Updated Zstd Implementation https://www.phoronix.com/news/Linux-6.2-Newer-Zstd Zstd with Btrfs transparent file-system compression performance the decompression speed was "a small win across the board" and at lower compression levels the compression speed and compression ratio were both better than the prior kernel code. 暗号化鍵ってみなさんどう読み込ませてますか? 手入力だと強さに限界や起動時コンソール前にいる必要があると思うのと、何より面倒。。 かといって同じマシンに置くと平文になると思うので。 システムパーティションは暗号化せずにおいといて、盗まれたら困るデータだけ別のパーティションにおいてそこは暗号化している 起動したらSSH(SSHのサーバー鍵は「盗まれたら困る」には当たらない)して手でパスフレーズ入れて復号化 手入力の場合の強さの限界は、ストレッチングで多少は緩和される。 概念的には昔からあるが今のインターネットじゃいろんな部分の性能保証がないから実用性がね 赤帽エンジニアブログ 2022-12-01 XFSで使った以上に容量が減るナゾ リンク貼れんかったので zstdもアップデートされて高速化されるみたいだし6.2は重要なアップデートになるな 6.1 が重要そうで、Debian のコードフリーズに間に合って喜んでいたんだけど... カーネルだけならアップデートしてもほとんど失敗しないし、別にいいんだけど。 昔はshutdown -rFでfsck走ったけどbtrfsは気にしなくていいの? VMシャットダウンした時とかに気になって。 shutdownコマンドは古くて問題があったので廃止されてる systemctlを使おう 今は大抵shutdownとかもsystemctlへのリンクになってるやろ ホントだ shutdownとして呼ばれると適切に読み替えてくれるんかな? # shutdown -r now # shutdown -h now 普通にpoweroffかrebootが1語で済んで簡単で良い ファイルのダウンロード中にLinuxのext4ファイルシステムが突然クラッシュしてOSが動かなくなった。 保存先のディレクトリのファイルがすべて操作不能、削除不可能状態になった。 物理的な衝撃とかもまったくなく、突如として起こったトラブル。 再起動したらLinuxはうまく立ち上がらず、セーフモードに。 けっきょく再インストールするハメになったが、インストールに失敗する。 いろんなディストリを試したが、どのディストリでもインストール中にエラーが出て止まる。 インストールメディアの破損もなければ、HDDの破損もない。 DVDドライブも普通に焼くことができるのに。 こんなことがあるんだね。安定しているファイルシステムはなんだろうか。 >>621 無制限なのはパス名の長さで、ファイル名はほとんどのファイルシステムで長さに制限があるはず >>623 > こんなことがあるんだね。 ビジネスだと物珍しいレベルではないかな。 最近は出荷前検査の精度が上がってて初期不良減ってるから物珍しいレベルになりつつあるけど。 症状的には CPU/マザボ 故障が疑わしい。 その次はメモリ。 ドライブもファイルシステムも無罪だと思うわ。 つうか、ext4 ってまともなメンテナ居るのか? ドライブ故障のトレンドに追随できてないファイルシステムは使うべきではないよ。 >>623 ZFSならsnapshotからロールバックで戻せるんじゃない? >>622 ext4が255バイトでNTFSが255文字(Unicode16)なんで困るんよ vfsにハードコードされてるぽいんでダメだろうけどダメ元で聞いてみた次第 流石に無知がすぎるだろ ext4なんて現在進行系で開発されまくってるファイルシステムだぞ あと絶対に壊れないファイルシステムは無いから ext4よりbtrfsやzfsのほうが壊れにくくはあるけれど >>629 本当に開発されまくって言えるか? Red Hat 系使う奴は xfs ばかり使うし、その他のディストリも btrfs だったり。 ファイルサーバ製品もハード直結独自FSばかり。 ext4 は使われていない/充分なデータが集まっていないだろ。 ext4が使われてないってどこの世界線なんだ… クラウドではほとんどext4だろう >>632 amazon も ext4 やめて xfs でしょ? ファイル名については昔Linusが255バイト制限緩めても今度は1MBじゃ足りないっていい出すに決まってるから対応しないって言ってなかったっけ 東アジア圏だとutf8で更に厳しくなったけど、今ならファイル名に長々情報持たせるほうが悪いって言われそうだしな OpenShift4 のPVはext4だった気がする。間違ってたらスマン。 linuxの文字数制限が不便でNASを使用しなくなったことがある ファイル名がUTF-16で記録されるexFATだとLinuxでも全角文字255文字フルに使えたからファイルシステムによるんじゃない? >>639 なんと。。圧縮したかったのでbtrfsで圧縮出来ればいいなと思ってた。 RedHatだから無理かな。。 ログを延々と吐き続ける用途にbtrfsは向いてますかね? CoWが邪魔したりしませんか? GpartedでUSBメモリをexFatでフォーマットしている途中で進捗が止まり、そのまま。 USBメモリがどうやら物理的に壊れてしまった。 PCに挿し込んでもそのUSBメモリだけがまったく反応なくなった。 Linuxのインストール途中で失敗しつづけている。 悪いこと続き。Linuxの神様に見放された模様。 邪魔の意味は分からないけど、性能はともかくデータ化けとかの心配は無いのでは? CoWが提供するのは堅牢性や一貫性確保だと思う。 CoWがダメならzfsにはログ保存できないことになってしまうし。。 ZFSはブロックレベルの重複排除だからCOWでも問題無いとかの話? ログファイルってコピーして使うか? 普通しないからCoWが邪魔はしないでしょ。 ランダムアクセスするファイルならRAIDで向き不向きあるけど ファイルシステムで向き不向きはないと思う。 データベースやVMのディスクイメージみたいな1つのファイルを何度も上書きするパターンはCoWと相性が悪いと聞くな 当該ディレクトリのCoWを無効化すればいいけど、してもI/O性能が上がる程度で有効のままでも別に問題なさそう Btrfs の場合、CoW有効のファイルを書き込んだ後に以前書き込んだ部分を上書き するとドライブ上ではそのブロックを上書きせずに別ブロックに書き込む動作をする。 「ファイルコピーしたファイルでのみそれが発生する」と思っていたがそれは俺の 勘違いで、実際は全ファイルでそれをやるってことか。 まあでもログファイルはシーケンシャルアクセスだから(ブロック単位の 上書きは発生しないから)CoWが邪魔しないことに変わりはなさそうね。 ログで質問したものです。 皆さんありがとう! 色んな考察が聞けてためになりますた。 VMはCoW無効にするのが常識とおもってて、 ログとかの追記も関係あるのかと思った次第です。 とりあえず何もチューニングせずに使おうと思います! debianのtestingに降りてくるまで一月ほどかかるなぁ ext4はシステム向け、xfsは倉庫向けと考えてok? どうしてそう思った?xfsデフォのディストリもあるが 大きいファイルなら速いけど壊れやすくメモリ食うのがxfs縮小もできない ext4は逆 >>653 RHEL9 から dump/restore は OS に添付されなくなった。 何かあっても保守/問合せ対象外。 EPEL として残ってるから完全に対象外というわけではないだろうけど。 その観点でいうと ext4 はコンテナ向け、xfsは物理向け、なのかも? じゃあbtrfsはなに向け? てかbtrfsはscrub定期的にしないとダメなの? zfs にコンプレックスを感じる人向け、というのは冗談として ext4 の後継と思っている。 >>659 草 BtrfsでNAS作られると(高機能すぎて売りが無くなるので)困るというのが伝わってくるw Linuxのファイルシステムはどれも一長一短で決め手にかける。「用途とか関係ない、これにしておけばまずOK」ってのがない。 ext4は大容量ドライブでfsckが遅く昨今の大容量なディスクドライブに作成するには向かない、 xfsはfsckは大容量ドライブでも問題ないが縮小ができないしメモリも食う、 btrfsはfsck不要、CoWなど「モダンなファイルシステム」とされるが、比較的新しいファイルシステムでやや心配がある、枯れていない、遅い。最近はまともになってきているが。 ZFSはライセンスの問題・・・ 一方、選択肢が多いのは良いこととも言える。他のOSだって問題はいろいろあるし、OS、FSともに完全無欠のものはないけどね。 >>661 xfsって壊れやすいって本当? なんかレガシな感じがして受け付けないんだよね。 そういやreiserfsはタイーホ後からどうなったのかね? 当時は先進的だったけど。 >>663 reiserfsは非推奨になってて2025年に削除される予定 ファイルサーバーにZFS使ってるけど安定してる RAIDZ2組んでて一度HDDが一つ壊れたけど復旧も簡単だった ZFSはARCが重いんだよな LRUよりは効率的だけど計算量が多いわ >>663 xfsはCOW導入で安定性が落ちたという話は聞いた気がするけど、その続報を聞かないな。話題になってないってことは安定したのか、皆避けてるのか 圧縮ファイルシステムでおすすめを教えて 主にテキストのログをどんどこ吐きたい btrfsかF2FSかな ログ出力用途ならF2FSのほうが向いてそう 金持ってたらgpfs使いたいんだけどな 安定性は元々HPCやエンタプライズ向けだから折り紙付き パスは255"文字"だしPOSIXで圧縮・暗号・ネットワーク共有・スナップショット・SSDキャッシュ等々 たいてい何でもあり、重複排除はあるのか知らんが 完璧ファイルシステムないよな 文房具みたいなもんでやりたいことがいろいろバラバラなんだろうな 当初から設計にも実装にも問題がなければ個人ユースではbtrfsがさいつよだったんだろうけどな 余りにも不具合が多過ぎた過去があって未だに怖くて使う気にはなれない btrfsだから不具合の噂が広まるみたいなところもあったと思う 去年か一昨年あたりにLinuxのext4がぶっ壊れてた時期があったけど別に広まってないし ext4とは頻度も不具合の数も全然違ってた 動画かスライドショーか忘れたけど当時のバージョンのbtrfsを意図的に壊す色々な手順を紹介してた 強引にじゃなくって長年使ってればそういうケースもあるだろうって手順だったからな 全員って訳じゃないが当時を知ってる人の多くは使い始めるのに躊躇するんじゃないかね read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる