ファイルシステム総合スレ その18
■ このスレッドは過去ログ倉庫に格納されています
ファイル名に長文使えるとどんなことに便利なの?
煽りではなく純粋に使いみちが思い浮かばない… >>240
255文字のFSはあるしそっち使っては?
伝統的なext、xfsは多分変わらんと思う
新しいFSが出てくるならNVDIMMとか
普及してDAXが流行るころかな
fuse 製なら1ヶ月あれば俺でも作れるけど
馬の骨製はいらんやろうな >>241
JANコードをファイル名にするよりも
「JANコード + タイトル」の方がわかりやすいやろ? >>243
うーん俺は>>241じゃないけど
例えばタイトルにスラッシュが含まれてたらもう絶対ファイルの名前にできないじゃん。
だったらファイル名は純粋な整理番号にして,それにメタデータという形でタイトルや作者の情報を添付する。
そしてファイルマネージャで閲覧したときは,その設定したメタデータが見えるようにできたらよくね? >>243
なるほど
ただlsで表示するときに長文名すぎると邪魔じゃないの? 保存時にタイトルが長いと
エラー出るからな
例えばWinのファイルをLinuxに移してバックアップしようとしたら
ファイル名が長すぎて一部のファイルがエラーになったりする。
短くするにもどう切るとファイル名の意味が損なわれないか個別に考えるのはかなり面倒。 lsじゃなくて、samba等でwindows上のファイラーで見るから
長いファイル名は、一覧では前半しか表示されないけど
個々の名前も見ることが出来るから問題ない >>244
> 例えばタイトルにスラッシュが含まれてたらもう絶対ファイルの名前にできないじゃん。
スラッシュ省くか全角にすればいいだけでは?
たった一文字のために、コードで管理する必要ない
> そしてファイルマネージャで閲覧したときは,その設定したメタデータが見えるようにできたらよくね?
lsもファイルマネージャw >>248
言い争う気はさらさらないのだが
「ファイルの名前に使用できない」という非常に機械的な理由から,
タイトルの原題文字列を変更してしまうというのは 俺にはどうしても抵抗があるな。
あとlsじゃなくて例えばxlsみたいなコマンド作ってファイルの属性表示させればよくね? お互い折れる気のない人が議論してもなんのためにもならんでしょ
そういう考えの人も居るのか、でスルーすりゃいいのに 例えば
ChMate、旧2chMateは、ファイル名にスレッドのタイトルを利用する
(この仕様と末尾にTABをつける謎仕様のせいで、
外部SDにそのままアーカイブ出来ないという事態が発生したが、それはまた別の話)
スレタイはもちろん文字数制限があるので、全角100文字前後までに普通は収まるが
外部板なども今後も絶対大丈夫などということはなく
仮に全角100文字までとなると、SJISやNTFSのUnicodeならば問題ないが
UTF-8等だと問題が出てくるケースがあるかもしれない
全角150字までとなると、SJISでも255バイトを超えかねない
(5chのサーバー本体はそんなファイルは作らないので、タイトルの最大文字数を増やすこと自体は簡単)
※「全角」は、datが内部的にSJISで記録されていることからも、用語として妥当
NTFSでファイル名の長さが問題になることがあまりないのは
制限があるのが「バイト数」ではなく「文字数」であるため
一方、一部のファイルシステムでの制限は「バイト数」であるため、文字コードによっては
Windows上の制限を大きく下回り、ファイル鯖として使いにくくなってしまう
「自分で使う」ファイルなら、それに合わせたファイル名をつければいいが
Excelで作った文書を保存するねーちゃんが、あとでどれほど見やすさ探しやすさを求めて
どんなファイル名をつけるかなんて、普通は干渉できない
なお、Windows上の制限は、ファイル名についてはそれほど厳しくないが
最大パス長の制限は厳しいので
実際にはそこまで無茶なファイル名が使われることはあまりない ファイルシステムじゃなくてクソアプリが原因の事例出して何いってんだ エリートユーザー様しか使わせないファイルシステム様のスレッドだったか
じゃあ俺は場違いだな
さようなら 更にいうとパーティションの暗号化をすると
ファイル名の制限がキツくなるという謎仕様もある 文字数制限は緩いほうが良いけど文字数の為に使うファイルシステム自体を変えようとは思わないな ディストリの変更とかファイルシステムの変更と比べたら簡単だからな ファイルシステムの変更のほうが簡単では?
データコピーするだけでしょ? ファイル名の長短でファイルのサイズは変わらないから
保存容量を減らさずに文章を書き続けられるってことじゃね?? CP932なWindowsからutf-8なLinuxにファイルを持ってきたらさらに文字制限がきつくなる Windowsは全角チルダと波ダッシュの文字化け問題を引き起こす不完全OS Oracleが起動したままxfsをアンマウントしたら、データファイルが全部綺麗に消えました
lost+foundにもありません…
ufsの頃にはこんなことは何度かありましたが、いまどきのジャーナリングファイルシステムで同じことが起きるとは思ってなかったので驚いてます
よくあることなのでしょうか? 前提で????ってなるけど他のファイルシステムで試してみたんか? 旧時代のファイルシステム「EXOFS」メインラインでのサポート終了へ
Linux Daily Topics 2018年11月14日 階戸アキラ
https://gihyo.jp/admin/clip/01/linux_dt/201811/14 よくよく聞いてみると、どうやらテストの過程で何を間違えたかrmでデータファイルを消したようです
ディレクトリは消えてなかったのでおかしいなぁ、と思ったのですが、まさかそんなオペミスするなんて…
xfsにあらぬ疑いかけてすまんかった 25年前に「魅入られた様に」にrootアカウントで「rm -r /」を実行したっけ… ある客が /root の中身が消えたというので話を聞いてみると、残ってるデータとかからして、
rm -fr /foo/work/*
って実行しようとして、
rm -fr /foo/work/ *
を(多分)実行したってのがあったなぁ。 遠因系トラブルで原因はまだ不明らしい。 リンク先みる限り、SSDやNVMe、HDDでも出てて再現できる人は再現
できてるが、できない人はどうやっても再現できない。 VMで再現できた人はいなさそう。
4.18 では問題でないが 4.19 では出るけど、基本的に ext4 周りの修正は 4.18 にバックポートされているので
ext4 モジュール以外のところがトリガーだけど、それがどこかわからないという状態みたいね。 4.19.5で不具合出なかったけど4.18.20に戻した kernel.orgのchagelog見た感じでは4.18.20と4.19.3でext4のfixだったから
慌てて4.19.2 → 4.18.20コンパイルじゃなく4.19.2 → 4.19.3にすれば良かったというオチだた 4.19.5でも起きてるってコメントもあるんだけどなあ BLK-MQは有効にしてたけど現象でなかったんだよなあ
デバドラレベルのBUSYステータス発生なんて珍しい状態じゃないだろうし FreeBSD ZFS File-System Code To Be Re-Based Over ZFS On Linux
https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-ZFS-On-Linux まるでLinuxのZFSが本家みたいになるな
Solarisとかほぼ死んでるし まじか
最近追いかけてなかったけどそんなことになってたのか 殺人犯が作った「ReiserFS」使ってる人いる? 、i`ヽ ,r‐'ァ
`ヽ:: ::´
ヽ ヽ , -‐--、 / /
ヽ \ I:::::::I_ _ / / ┌────────────
ヽ ヽ i,(;;;ノI、;;;)l ,,/ , ' < レイザーエスエフゥゥゥ!
ヽ ` ー 、.,,ゝ´ヮ`,ノュ_, - ' r' └────────────
` 、_ /::: `山'::::: /
ヽ:::::::::::|::::::::"",r‐'
〉::::::::|::::::::::¨/
/;;;;;;;/;;;;;;;;;;/
/;;;;;;;/:::::::::::《
<;;;;;;;《:::::::::::::ヽ ))
/ ヽI,r''"""^~ヽ
/ ,/ ヽ ヽ ライザーエフエスだよHG
>>920
今は使ってないが
壊れかけのHDDでEXT3よりも頑張ってくれた思い出 https://inmatelocator.cdcr.ca.gov/Details.aspx?ID=G31008
Hans Reiserは2020年5月に仮釈放の申請ができるようになるらしい(仮釈放が認められるとは限らない) ラップトップでスナップショット使おうとするとやっぱりbtrfsしかないんだろうか
LVMも使ってみたけどスナップショット取ると遅すぎて使い物にならなかった
ZoLのほうが良かったりするのかな ZFSってファイルサーバーに使うもんだって勝手に認識してるわ
一般的なデスクトップに使うのってどうなのかね 軽さと安全性はトレードオフ
速さが必要ならext2でも使ってなさいってこった >>297
ワークステーションならまだしもラップトップじゃ力不足だろうね zfs遅い速いって不毛な議論されてるけど、zfsはボリュームの構成で激しくちがうからなんとも言えないだろう
zfsでシングルボリューム、シングルプールだと力なんか必要ないだろう データ壊れるより遅くても耐障害性があるほうがいい、、
ext/xfs/reiser/jsf色々使ったけど懲りた ZFSは使って楽しいけどね。覚えるコマンドも
少ないし。 >>305
何使ってるの?
btrfsに関しては普段はいいけどいざ問題が起きてメンテナンスしたりするとすげーバギーで常用は辛いって感想
とりあえずlvm+ext4に逃げてる
zfsは使ったことない >>307
メインはfreebsd+zfs
linuxならext4,xfs
macはapfs
winはNTFS
使いたいOSが押してるやつだな 使ってるけど自動でデプロイされたから中身よく知らない とりあえずbtrfsが遅い
まあxfsやext4はlvm使うことが多いからそうなるとbtrfsとそんなに違わなくなるのかもしれないが
https://www.phoronix.com/scan.php?page=article&item=linux-50-filesystems&num=1 zfsは構成がどうのとか関係なくメタデータ操作系が全般的に遅いから
homeやspool的なものとかデスクトップマシンとかでは使いたくない 鯖には用途に合わせてxfsとZoL
デスクトップにはbtrfs使ってる
btrfsはもう少し速くなってくれたら言うことないんだけどなあ zfs勢はbtrfsをpoor man's zfsとか揶揄するけどエンタープライズしか考えていないようなのをノートパソコンで使えたもんじゃないよな >>173
zfsは、高価なハードウェアを使わない
より安価なソフトで解決する
プアマンズRAIDだしね。 >>317
今どきはCPUが性能余してるからソフトウェアRAIDの方が速いと思う 停電とかの事を考えるとそう単純な話じゃなくなる
バッテリとか大容量キャパシタ積んだコントローラなら突然の停電でも
書き込んだなら書き込んだ、書き込まれてないなら書き込まれてないの
保証がある程度できるけど、
ソフト側で逐次各記憶装置に書き込み命令とか送り込んでると一貫性がなくなる
win10以降の記憶域プールはその辺の対策はしてるみたいだけどめっちゃ遅い
IsPowerProtectedをTrueにすれば早くなるけどその辺の対策がされなくなるしな
所詮ソフトウェアRAIDだからっつーて、
単純にパリティ分散とかミラーリングとかすればいいっちゅーもんでもない RAIDZで雷の日でも精神ダメージが入らなくなったのは嬉しかったな
バッテリ付きRAID ごめん途中送信した
バッテリ付きRAID高いから手が出せなかったって言いたかった 小規模・個人レベルならどっちでも良いよ
データ保証はアプリとファイルシステムが担うべき
DCクラスでハードRAIDはナンセンス ファイルシステムが物理層の構造に依存するとか非現実的だろう 物理というかブロック層はbarrier/fua/flushに従うだけやろ?データとしての一貫性は上位のソフトウェアにしか分からんから>>322は当たり前の事を言ってるぞ そういえばWindowsはファイルシステムの下位にフィルターが入るとかでWSLがやたらIO遅いとかネタになってたな WSLが遅いのはNTFSの上でfuseみたいなの動かしてるからじゃないか >>324
データの保証ってチェックサムレベルだったら勘違いしてるぞ
停電とかで一部のHDDにだけ書き込みが実行されて他に書き込まれなかった時、
単純に分散するだけじゃハードの恒久的な障害かそうじゃないかがわからなくなる
そのフラグなりジャーナリングなりまでをもファイルシステムがやれって事でしょ?
zfsみたいなチェックサムとは訳が違う >>327
raid5/6のwrite hole問題の話か
あれはストレージノードの冗長構成とっていて頻繁なディスク同期のできない企業向けシステムが気にする問題やろ?停電や強制電源オフを頻繁にする人なら気にしたほうがいいが win10の記憶域プールはファイルシステムより下で
ハード起因なのか停電とかなのかを判別してる
その機能の有効無効のフラグがIsPowerProtected bcachefsが今年中に使えるようになるんじゃないかね
結構期待してる 今年使えるようになったばかりのfsなんて怖くて使えない Linuxのメインラインに取り込まれるのが今年になるだろうってだけで何年も前から使えるけどな Linux上のZFSがLinux 5.0でひっかかる
https://www.phoronix.com/scan.php?page=news_item&px=ZFS-On-Linux-5.0-Problem ■ このスレッドは過去ログ倉庫に格納されています