ファイルシステム総合スレ その18
■ このスレッドは過去ログ倉庫に格納されています
起動時にパラメータを渡すだけのものもあるよ
grubのメニューを作って試してみればいい >>17
ファイルシステム関係は、sysctl.conf に記述するものが多い。ググってね。
実際の設定については、"meminfo vm.dirty_background_ratio" あたりでググると良い。 >>19
なるほど、物理メモリサイズをもう少し確保できるようなチューニングのことでしたか
てっきり、カーネルページまでスワップさせる設定ができるのかと思っていました カーネルのデータは、だいたい slab を使って管理する。ページ単位では管理しないよ。
で、メモリが圧迫されると、shrink するようなコードが動いたりする。そういったパラメータとかはあるよ。 仮想メモリはファイルシステムと直接の関係は無いだろう >>21
slabはページ（メモリ）の管理効率をあげるもので、
結局メモリはページ単位で管理されるという認識なのですが、違うんですかね？ >>23
カーネル空間にページがマップされてはいるが、それだけの話。
キーワードを提示することしか出来なくて悪いが、"dentry inode" でググるとどう使われているか少しは分かるかもね。 >>9
8GB積んだらスナップショット消しても落ちないようになった
しかしbtrfs-transactionが動いてる間は同じボリュームではほとんど何もできないのな Ubuntu, Win, Mac のどれでも書込までできて、しかも2TBの制限もないファイルシステムはexFATですか？
ちなみにOSはどれも最新のものね。 https://ja.wikipedia.org/wiki/ユニバーサルディスクフォーマット
好き好んで使ってるのはそんなにいなさそうだが。名前＆目的としてはこれがなんだがなあ hddとかssdとかusbメモリをudfフォーマットできるの？ ntfs-3gもinodeがなんたらでアクセスできないファイルあったりするし互換性確保しようとすると選択肢ホントないね ファイルシステムってシステムの根幹にある物だしOSへ依存しているものが多いのは仕方ない
exfatでだめならnfsやsmb使ったほうがいい >>32
まあ、必要ないだろ。
今はファイル鯖にクラウドストレージもあるんだから。
他とやり取りするファイルに属性値なんてそれ程重要じゃないし メタ情報はPOSIXで標準化されたとしても独自に拡張するし相互運用はする物じゃない
exfatみたいに単純なファイルのやりとり程度でとどめるべき >>35
そう考えるとexFATは必要最低限という点で適切な選択だと思う
単純さ故にどのOSの実装も問題ないだろう >>37
FAT系のファイルシステムはいくつもあり最大16EiBまで扱える >>37
ファイルサイズを表現するビット幅が32ビットなんだと思う 2の32乗 = 4,294,967,296 で確かに4Gになるけどこれって4Gビットだよね
なんでここから4GBに繋がるの？
>>38 windows関係あるの？ >>39 FAT32の話ね >>42
何で最小単位をビットにしたのか教えてくれ >>45
なんとなく…
でもよく考えたら違うかも
4,294,967,296状態表すことができるってことかな
それがなんで4GBに繋がるのかはわからないけど FAT32のメタデータの中にファイルサイズを表す数字を置く場所があって
その場所の大きさが32bitしかない
そして、2^32で表せる数字が約40億
だから最大4Gまで
※ファイルサイズはバイト単位だから、4Gバイトまで
FATというのは、DOSで使うために作られたファイルシステム
FAT32というのは、FATをWindows95OSR2で使うために拡張されたファイルシステム
だからWindows関係の板で聞く方がいいというのは正しい もしファイルサイズのデータがセクタ数を意味するものであったのなら
2TBまでのファイルが作れたかもしれない(512Bとして)
だけどファイルサイズはバイト数で表すものであって、セクタ数ではない
もちろんビット数でもない
勝手にビット数だと決めつけるのは自由だが
それは自分で作ったFSのフォーマットで使ってくれ >>46
何が何を表してるのかを混同してんじゃないかな
1つの32bitで表せる数値の最大が4,294,967,296ってだけ
その数値がどんな単位で何を表してるのか(bitかbyteかメートルかグラムかとか)はまた別の話 きょうびセクタだのトラックだのなんてもういらないモノになっちゃったよな >>50
セクタを何と勘違いしてる？
今でもセクタは絶対に外せない概念なんだけど
CHSで言うセクタとは、単に「１トラックあたりのセクタ数」のことだけど
そんなことしか知らない人が、ファイルシステムのスレッドで知ったかぶって書き込むかね 1セクタは、512バイトで、
ファイルの最小単位が、セクタ8個分だから、4KB
だから、1バイトのファイルを作っても、4KB のサイズになる 533 名前：login:Penguin[sage] 投稿日：2018/02/01(木) 13:34:25.48 ID:0hMkXx1N
https://i.ytimg.com/vi/_jjwqFhlxi4/maxresdefault.jpg
戌厨のいつものグロ貼り転載ｗ
セクタとクラスタを勘違いしてないか？ >>55
誰が勘違いしてるの？
本当にわかってる？
セクタは物理的なディスクが扱う最小単位
クラスタはOSが扱う最小単位
おまえ、本当にバカでしょ 4KB セクタか。ファイルデータはキャッシュするからページサイズに合わせた 4KB 単位での I/O が普通だったからそこは別に問題がないんだが、ファイルを管理するためのデータ ー メタデータはどうなんだろうかね。
Btree なんかは、キャッシュしたと思うんだが、inode なんかは基本キャッシュしない。読み込んで カーネルのデータ構造に変換してキャッシュとは違う管理をする。
4KB 読み込んで 256B か 512B 書き換えて 書き戻すようなことをするのかね。効率も悪いが、4KB内の関係ないデータが壊れる可能性が出てくる。
関係ないデータが壊れるとお手上げだな、検出できないし、当然復帰できない。
ジャーナルも対応がどうなっているのか。基本は小さなデータを追記しては 書き込み完了を待つ。512B 単位のエミュレーションなんかを使うと、書き込んだはずのものが一部壊れる可能性が出てくる。完全に4KB 単位にして、スカスカで使えば問題は起きないが。
こういうことがあるので、4KBセクタというのは、ファイルシステムの基本設計のバランスを崩してるね。既存のほぼすべてのファイルシステムが向いていないとも言える。 何言ってんだこいつ
4KBセクタへの移行が始まったの何年前だと思ってるんだ >>59 はジャーナリングは信用出来ないとかいってext2使ってそう >>59
バランスを考えるならメタとデータの書き込み比率を考慮しないとね 普通のファイルシステムなら4KB以上でアライメントそろえてるから 4KBセクタだと、急な電源断で Write 中のデータが失われる場合 、4KB のセクタ単位で壊れるわけだな。512B セクタだと思って処理してると、関係ない所が壊れるケースが出てくるという話。
あたり前の話なんだが、一般人に警告されたことはないようだな。 たぶん、いまどきのOSで、セクタ単位で何かを書き込もうとするものは無いと思う
ブロックやクラスタと言われる単位で連続して書き込む
そのためにアラインメントを揃えたりもしてるんだし
もちろん必要な極一部、例えばMBRの書き換えを要するfdisk等はこの限りではないし
「やろうと思えば」(512Bセクタでエミュレーションしているならば)512B単位で書き込む(書き込もうとする)ことは出来るけど
普通に使っている限り、ブロック単位で扱われる
特定のエミュレーションセクタに書き込み中に電源断が起きて「書き込み未完了」のまま代替処理が行われたら
その周囲のエミュレーションセクタ共々ブロック全体が「書き込み未完了」になるので
仮にセクタ代替処理が行われて周囲のデータ共々入れ替わっても問題は起こらない >>65
ハードディスクは、セクタ単位で読めなくなる。その単位でしか ECC がないんだから当然そうなる。
前のデータが一部残っているとかはない。
代替処理というのは、また別の話。リードエラーが起きたセクタに書き込めば、なにもなかったように書き込める機能。
いまどきのOS? ファイルシステムは古いものが多いぞ。NTFS , XFS , JFS, EXT2 などは 1990 年代の設計だ。
EXT は、2,3,4 と進化しているが、ディスクレイアウトの基本は同じ。エクステンションなど取り入れてはいるが、XFS の最小から実装されていたような古いもの。
ブロックやクラスタとか もっと前の話だな。
新しい設計というと、btrfs 、ZFS なんかの COW ファイルシステムだが、現状はいまいちだな。NetApp の WAFL 特許がネック。 >>64
4KBセクタのディスクに512Bセクタだと思って512Bで書き込むとサイレントにデータを破壊することがあるのか・・・ だから、ブロック単位でしか扱わないって
１つのセクタが複数のブロックに分散されるのは
アラインメントを揃えずにフォーマットされた、4Kセクタ以前のOSで何も考えずに使われていたものだけ
それも無思慮に扱われてパフォーマンスが低下しているのに文句言いながら使っている人だけ >>69
パフォーマンス低下って4KBセクタに512Bで書き込む際に発生するRead-modify-Writeでってことかな？ クラスタサイズをNTFSみたいに64KiBにできてもいいのになと思う
メディアファイル格納用にさ >>71
https://ja.wikipedia.org/wiki/XFS
とりあえず、XFS の エクステント、遅延アロケーションの項目読んでみ。この機能は ext4 にも導入されている。
上で書いたの間違い。
X エクステンション
O エクステント 4KBセクタのディスクに512Bじゃデータ書き込めないから >>72
すまね、ext系列の話
管理方法じゃなくてブロックサイズの話な。 いやひとりだけコールドスリーブされて来た奴がいるだけだ > いやひとりだけコールドスリーブされて来た奴がいるだけだ
お前のことだろ SLEEVE Raid1のZFSにscrubかけたら
１系のcheck sumにだけunrecoverable errorみたいなのが5〜6個出たんだけど
もう一回scrubしたら消えた。
こういうもん？何か対処した方が良いのかな？ ファイルシステム的にはＯＫな状態になってるわけだから、見るべきはハードウェア側だね。
各ディスクの S.M.A.R.T 情報みて、ECC 系や Reallocate 系、その他エラー系のカウントが
カウントアップしてないか確認。
一回とって数時間後にもう一回とってみて比較。 ヤバそうだったら HDD 交換。
特に電源ブチ切りしたわけでもなく、ハードウェアエラーも発生していない場合は
memtest とかでメモリをテスト(サーバ製品でECC付きなら省略可)。
予防交換可能なモノ (サーバ製品で保守期間内の場合) ならここでマザボ交換。
その後は再発するか様子見して再発するならファイルシステムのバグを疑う
(OS 保守があるなら OS ベンダーにエスカレーションだが ZFS なんでコミュニ
ティに連絡？)、かな。 >>81
ありです。今度の休みに戻ったら順番にまずはS.M.A.R.Tから見てみます
ハードの交換で済めば良いけどZFSのバグだとほかに良さそうなFS知らないから困るなぁ ☆ 現在、衆議員と参議院の両院で、改憲議員が３分の２を
超えております。総務省の、『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆ 動作確認のために久しぶりにCentOS使ったらデフォがXFSになってた
絶滅してなかったんだな！調べたらBtrfsが非推奨とか書かれてて2度ビックリさせられたっていう
流行り廃りが変わってたのか LVMみたいなのなしでスナップショットが取れて
厄介なライセンス問題がなくて
透過的圧縮が選べて
安定動作する
ベストなファイルシステムbstfs(仮)がXFSを元に誕生してくれるはず >>87
XFS元にとか、raid考えるならブロックレイアウト的に無理ある
btrfsフォークしてテコ入れした方がまだ楽
仕事でbtrfs開発出来たらなあと思う今日この頃 暗号化はあっさり入ったのに圧縮はまだ入らんからファイルサイズ辺りの設計が拡張性なさそう> btrfs
いろいろ詰め込み過ぎたな
ext5はよ OpenSUSEあたりがデフォでBtrfs使ってたりがんばってたな
使い勝手とかどうだったんだろ btrfsって圧縮なかったか？
少し前にzstdが使えるようになったって話題になっていた気が… すまぬbtrfsは圧縮あるな、ext4と勘違いしてたわ btrfsのdeprecatedはRH系だけだしXFSに振り回されないほうがいい
もし将来的にbtrfsが破棄されるようなことがあってもさすがにその頃には>>88の言う通りテコ入れフォークが誕生したり
あるいはZFS on Linuxのライセンス問題も解決してるだろうから満を持してそっちにスルっと移行が正解 XFSはsnapshotが今後もlvm依存で透過圧縮に至っては念頭にもなしが相変わらずならホント関わらないのが吉
仮にBtrfsが派生無く廃止されてZoLライセンスも悪い方に着地したら……いよいよNILFS2の台頭の時 そんなんbtrfsもxfsも使ってるsuse死亡やん ハイパーコンバージド界隈だと重複排除や透過圧縮は専用ハード
(ASIC)で高速にやるって流れになりそうだし、スナップショットや
シンプロビジョニングも昔からハード側(というかミドルウェア？)で
やった方が安定してる模様。
つまりソフトじゃハードに勝てず、市場のパイを急速に失いつつ
ある状況だわな。
クラウド化の流れでエントリーレベルのサーバ製品はビジネスの
メインストリームから外れちゃった(PCサーバ数台買って Linux
入れる時代は終わって、外部のクラウドか大規模な内部クラウド
上の仮想マシンに Linux 入れる時代になった)んで、ファイル
システム上でのスナップショットとか透過圧縮とか前世代の技術
なんかに時間を割きたい技術者なんていないでしょ。 >>96
エンドユーザーが使うディスクやファイルシステムに対する解になってないからなあ
まあ興味の集まる分野でもないから技術者が減りそうなのは同意
HCIみたいな箱売りたいメーカーはハード依りだろうけど、クラウド事業者はお高いハードでってのはない気がする
稼働時間に対する障害発生率はハードの方が高いって研究結果もある
確かGoogleが出してた エンドユーザーレベルに専用ハードも降りて来なくてミドルウェアも複雑化回避で避けられてて
そのうえ技術者まで離れそうとなるとソフト面でも今後ぜんぜん進化しなくなる暗黒時代の到来か
何気にヤバイじゃん！既にその手の機能を自前で確保済みだったファイルシステムは割りと羨ましいが保守されなくなると使うのも危険に それならこのスレの英知を結集して新しいファイルシステム作れば良いじゃないか！ ext系はずいぶん前に開発者リソース分散を避けるためext5を作らずext4強化で実質5相当にするとか言ってたが
その後の方針はどうなったんだろう ntfs-3gは互換性にちょい問題あるから仮想マシンのwinにマウントさせれば大丈夫だろうと思ってたけど、物理マシンのwin10にファイルシステムぶっ壊されて尻込みしてきた… windowsがNTFS壊すことなんて普通ないだろ
壊れる場合は大体ハードか要因 btrfsはまさかのWinBtrfs登場でいま一番すき >>102
Win10は次の起動の高速化のためにシャットダウン時に色々やってるから、油断ならない ntfs-3gのLFS＝Windows7以前のLFSだからWindows8移行のLFSと互換性はない btrfsからext4に逃げたけど透過圧縮ないとNAS用途だと10%くらい容量食って辛い 恐縮ですが、SSDとHDD混在のVLMでアクセス頻度の高いデータをHDDからSSD側に動的に移動してくれる機能はないでしょうか
例えば Windows Server 2016 の 記憶域プールのような SSD と HDD を階層化する機能はないでしょうか。
CentOS7を使っています
ご存知の方がいらっしゃいましたら教えてください。 LVM Cacheが多分一番楽
既にあるLogicalVolumeに対してもSSDをキャッシュに出来る
動いてる状態でにキャッシュの追加と削除が可能
3年くらい使ってるけど、特に問題は起きてない
あくまでキャッシュなのでSSD追加しても全体の容量は増えないけど >>108
LVM？
階層化は聞いたことないなあ
本質的にはSSDキャッシュだし
git探してもマトモなのないね >>108
もう開発止まってるっぽいけど、btierとか。 いろいろ情報ありがとうございます。
LVM Cacheキャッシュでいこうと思います。
できないことがわかっただけでもありがたい。 ext以外で予約領域の概念があるファイルシステムってある？ XFSのパーティションに別のパーティションから
100万個ファイルをコピーしたら、途中でコピーが止まり
XFSのファイルにいっさいアクセスができなくなったよ。
よくある話らしいが、EXT4で構築すればよかった。 連続書き込み3万個くらいで不具合起きるかもしれないんだっけ
RedHatの一件からだと思うがXFSに手を出して痛い目みる事例が増えてるみたいだな
そのうち安定化するといいが… XFSでファイル鯖立ててしもうた。
鬱だ。(´・ω・`) ■ このスレッドは過去ログ倉庫に格納されています
