Debian GNU/Linux スレッド Ver.103

公式サイト
https://www.debian.org/sitemap

前スレ
Debian GNU/Linux スレッド Ver.102
https://mao.5ch.net/test/read.cgi/linux/1744820527/

ベンチスコア、体感、使用感が著しく悪くて何だこれって思ってたところに全ファイル消失だもん
まじで詐欺だよ

>>110
Redhatはbtrfsには期待はしてるんだよ
Fedoraでテストして採用するかを判断するんだけど
今のところ安定性に問題ありとして不採用が続いてる

Linuxのファイルシステムってそれぞれに何かしら問題抱えてるよな
WindowsはFATは酷かったけどNTFSは安定してるんだよな

個人レベルならext4で十分すぎるだろ

ext4は無難なんだが特に負もなく可もなく
reiserfsのなんだこれ早いみたいなこれといった強みもない

ext4は安定はしてるし細かいファイルの操作とかのOS領域向けではいいけど大きなファイルの操作の速度面とか考慮するとファイル倉庫には向かない印象

昔はext4もこんなバグがあったけど、今は安心
https://wiki.ubuntu.com/KarmicKoala/ReleaseNotes/ja
ext4 ファイルシステムでは巨大なファイルが破損する恐れがあります

ext4 の inodeとか使い切らないで
限界を語っても無意味だよ
あと電源やネットワークとか
複数搭載してないパソコンでしょ？
無理してRAIDの冗長化だけしても
広告記事に勧められるままに
買っているだけだよね

>>111
それいつ頃の話？
導入したばかりなので不安になる

>>113
NTFSはWindowsで使うにはいい具合に枯れた感じだけど…
なんと言うか目新しさは無いというか率直にいうと
Linux系のファイルシステムと比べると進歩がなくて
相対的に少し古臭くなってきてる感じもあるかも

OSなんてガチガチに枯れたもので十分だわ

>>119
まだ壊れてないならさっさと別のファイルシステムに切り替えたほうがいい
というか散々情報出尽くした今なぜbtrfsにしたんだよって感じ

ZFSの実力に反する人気のなさw

ZFSはライセンスが絶望的に終わってる

ZFSがLinuxカーネルに取り込まれないのはその辺の事情だっけか

>>122
pdumpfsの保存先にxfsを使ってたんだけども
xfs_repairするとメモリに全展開する超絶馬鹿仕様なので
そろそろ機が熟したかな? と期待してbtrfsにしました
btrfs（raid1）は今のところ遅いのが不満です
xfsに比べて体感できるほど遅い
ちなみにext4はinodeが足りない
zfsはカーネルに取り込まれていないという理由で却下です
Linuxには良いファイルシステムがないですね
zfsのラインセンスはなぜに変更せんのですかね?
Linuxに取り込まれて使われるために公開したのではないんですかね?

>>115
「可もなく不可もなく」が普通の言い回しだな
すごく変な感じがした

illumosか*BSDで使えば良いやん。
仮想マシンでSAS HBAを丸ごとくれてやれば性能的には問題ないぞ。

え、Linuxで？
リソース有り余ってるならいいんじゃねーかな。
目いっぱいシビアな環境で動かしたらtxgがデッドロックしたから自分は信用してない。
それよりきついマシンでFreeBSDだと普通に動いてたからやっぱりメモリ管理が統合されてないのはきついんだろ。

>>120 >>121
だからReFSなんて別のfs作ってるんじゃないの

>>129
利用されてるのかあれ
NTFSにはある機能がなかったりでやる気なさげだけど

今どきbsdは障害者しか使ってないやろ
そんなにbsd使いたいならmacでいい

ZFSから離れてBSDの話をするな

最近のでびゃーんはインスコが簡単だから馬鹿でも使えるヨ

だから？

BSDの宣伝文句が未だにネトフリで〜PSで〜なの笑うしかない

ZFSは神FSじゃなかったか

Solaris（笑）

>>126
ext4のinodeが足りないって、mkfs.ext4でファイルシステムを作るときに bytes-per-inode 比率を変更すればいいんでは？

ソースコードとはいわず
基本的なドキュメントも
読まない人たちが増えたよね

Appleのせいで
ドキュメントは読まないのが正義という宗教が流行ったから

>>138
inode数を予め見積もれれば可能でしょうけども...

で、最近ムトー神は降臨しないの？

別に他者の使用方法に文句つける気もないけど
単一ファイルシステムでi-node足りないほど大きくする必要あるの
複数ファイルシステムでマウントポイント工夫すれば
解決する話ではないの?

pdumpfsで毎日バックアップしていると
毎日ファイル1つにつき1つハードリンクが増えます
ファイル数によるけども私の環境では
10年以上前からext4では手に負えなくなりxfsにしていました
xfsはxfs_progsのメモリの使い方がアホ過ぎるので
期待を込めてbtrfs（RAID1）にしました

xfs_repairでした

期待て
ぞろぞろ裏切られたあとでそんなこといわれても

>>142
この辺までは見つけた
https://developer.hatenastaff.com/entry/2023/12/30/110000

pdumpfs って保守されているの？
そもそも更新していないファイルは
ハードリンクで対応とか
設計ミスなんじゃ

>>147
昔はもう少しあったぞ
何とは言わんが

＞＞147
＞＞149

ぐはあ 吐血（ｒｙ

ファイルシステムスレでやれ

inodeは植毛できないの?

>>152
ファイルシステム総合スレ その21
https://mao.5ch.io/test/read.cgi/linux/1750553314/

ｿﾝﾅﾆ毛ｷﾞﾗｲｼﾅｸﾃﾓ

Devian的にお勧めで新し目で、
fehみたいにシングルキーショートカット自在に設定出来る、
シングルペインの画像ビューワなにか御存じですか？

fehの後継にとおもったんですがと思ったんですが、
新し目のものは大抵シングルキーショートカット出来なかったりいじれなかったり……
目に見えて速いのあったけどここら辺でダメでした……

今は状況によりけりでfehの代わりにmpv使ったりしてます

シングルキーショートカットってのはctrlなんかを併用せずに単独のアルファベットをショートカットにできるって意味？
Gwenviewならできる。UIはごちゃごちゃしてるけどツールバーやなんかを非表示にしまくればまあ…

ひょっとしてxが死んでfeh使えなくなった？

nomacs ： debianリポジトリから外れたしなんか重くなった気がする
LXImage-QT ： 軽くてさくっとはいるので使い勝手が良い

新しめの画像ビューワ山のようにあるから新しいのほしいなら自分で探したほうがいいし

geeqieじゃダメなの？

ここに載ってるようなものの中でも該当するものはなかったかな
qViewだったかなぁqimgvだったかなぁ、速いけどキーボード操作がおざなりだったような

失礼

アプリケーション一覧/マルチメディア - ArchWiki
https://wiki.archlinux.jp/index.php/%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E4%B8%80%E8%A6%A7/%E3%83%9E%E3%83%AB%E3%83%81%E3%83%A1%E3%83%87%E3%82%A3%E3%82%A2

GpicviewとViewniorは重宝してる
ただXviewerが使えれば迷走することは無かった

>>155
nsxivはどう？

qimgvいいな
画像サイズにウィンドウサイズをリサイズしてくれて同じ機能にショートカットキー複数設定できてQtの画像プラグインが使えて
情報ウィンドウがペインではなく独立ウィンドウで出てくるのも好み
教えてくれてありがとう

>>163
ご指摘受けて再度確認してみました


まずimlib2使ってる時点で古いって印象
5MB以上のファイル連続読み込みで速度はfehと大差なく、そこは同じの使ってるから変わらないよねと思った
コマンドが多いのはfehより優れてる
ただこれman見るとキーカスタマイズはC-x押したあとに続けて～しかできないっぽい？

拡大に限度があるのはちょっと……
あと4kモニターなんだけど、サムネイルモードが小さ過ぎて見えなくて使えない感じ

他にいくらでも良いのある感じ
コマンドの多さ除けばfehでいいよね

qViewがなぁ。fehよりキーカスタマイズは優れてる
けどリポジトリに無いからなぁ
今回はappimage使った

小さいファイル連続表示はqViewの方が速かった
でも新しいものならむしろデカいファイルで速いべきでは？
昨今のスマホの写真解像度もデフォでデカくなってる外出し

ふーん

synapticとかでviewerやsumbnで検索して片っ端から試したほうが早い
似たようなのが山のようにある

つかカウンセリングして好みに合うの１つ１つ確認しながらココでやんなって感じ

ガチの気狂いだろうな

5万枚ぐらいの画像を処理するために作業していたら
PCManFM でフォルダを開いた瞬間に大変なことになったでござる
サムネイルはいらない子にしました

サムネ無しでもダメだろ

５万枚の画像ファイル閲覧くらいどうってことないでしょ
とDolphin使いながら首を傾げた

>>173
この板にはいまでは低性能になるPCを使っている奴が超多い
低性能PCでは並み性能PCで大したことない負荷の処理でも大変なことになるんだよ
>>172
俺も画像扱うのにサムネないのダメと思うが、でも、自分で何とか(高性能PCの導入、ソース弄って高速表示にするとか)できないとなると
いらない子にするのはしょうがない

サムネイルなんて実装の良し悪しがもろに出るからな
マシンスペックではなくてPCManFMが大量のサムネイルを扱うのが苦手という話では？

5万枚の画像ってなに？
動画ばらしたとか

>>174
その程度の枚数なら１５年前使ってたgeodeNX機で処理してたがそんなことなかった
１枚１枚処理がかかるスクリプトまわしても終わるまで時間がかかるだけだった
M黒ソフト製のOSでもあるまいし大変なこととは一体？

画像1MByteとして5万枚で50GByte
画像5MByteとしても250GByte
多いけど同時にメモリ上にある必要性はないわけで

ディレクトリ分けるだけでも捗るかと

>>175
>大量のサムネイルを扱うのが苦手
苦手てな原因がサムネの生成が遅いからなら
俺プログラム等であらかじめPCManFM用サムネを生成しておけばいいんだろうが
(>>177が15年前にやったようなことをやれば良い)
そうすれば気にならない時間でサムネ表示が可能になるんじゃないのかな

なんでそんなになるまでフォルダを分けて置かなかったんだよｗ
まず最初に保存日で月とか年ごとに分けるところから始めた方が良いんじゃね

>>174
そうじやなくて、1つのフォルダに5万ファイル置くのがアウトだろ

lsするだけでくっそ遅いはず

ゴミ屋敷Linux

それこそファイルシステムによる
xfsはbtrfsに比べてファイル数多くてもめちゃはやいよ

1ディレクトリ5万ファイルだと閲覧する人間の能力の限界を超えそうだ

5万ファイル目視ならripgrepの置か世話になる方が効率高め

DBのログなら5万件位直ぐいくよ

てか画像5万て拾ったエロとかそれに準ずるくだらないファイルじゃないの？
溜あんまり想像つかないわ

pcmanfm --desktop-offで解決

>>181
別に普通
なんの実体験？どんな環境だよ
GUIファイラーは見えてる範囲内のサムネイル生成を優先する
範囲外はバックグラウンドで余力使って生成続けるから大変なこととやらは起きない

lsなんて一瞬でしょtimeつけて回してみてよ
findでもlocateでも一瞬でしか無いと思うが

ファイルシステムはリレーショナルDBじゃないんだから数が増えたら速度低下するのは当たり前の事なんだが
DBが無かった頃はファイルにデータ入れてたしな
今ならGoogle検索すりゃAIが教えてくれるで

mkdir 100 ; pushd 100 ; touch {1..100} ; time ls ; popd
> real 0m0.003s

mkdir 50000 ; pushd 50000 ; touch {1..50000} ; time ls ; popd
> real 0m0.398s

商用ファイルサーバはディレクトリはDB構造
もちろんリレーショナルじゃなくてファンクショナル
ハッシュテーブルとか使ってる
一部のLinuxファイルシステムもそう

0.398/500→0.000796

最近なんかxfsとbtrfsって単語をこの板で妙に見る気がして
対立をあおりたい人がいるんじゃないかって思うの

lsはフォルダ見るだけだから容量分しか差が出ないのか
ファイルアクセスだと
1/1なら1回で当たるが、1/50000なら当たり引くのに平均25000回だから単純リストなら25000倍になるんじゃねえの？

>>195
比較だよ
FSは煽られるほどの信者がいるものでもあるまい

>>197
お呼びじゃないから失せろ

100枚なんてすぐだろw

PCManFM はフォルダ内のすべてのイメージのプレビューをロードします。
HDD を酷使しないためには、フォルダ内の画像数を 100 にしてください。

>>184
btrfsの比較も大量ファイルのあるフォルダをnocowにして計測してるようなのは少ないから実際の測定と単純な測定ではまた差が出るだろう

心配しなくてもbtrfsなんか使わないよ
引き合いに出してるxfsもbtrfsと比べるほどオンボロなんだなあというネガキャンになってる

まだ春休みなのか
ファイルシステムの速度差が3倍5倍あっても一方がスイスイでもう一方が我慢できないほど遅いなんて差がつくわけないだろ
それよりも縮小処理の速さ、キャッシュの扱い、表示する範囲だけロードする、使わないものはメモリから追い出す、等を適切にしているかの影響がでかくて
PCManFMが下手くそというだけ

pcmanfmとかゆう化石使ってるジジイが悪い

btrfsは目に見えて遅かったからまあわからないでもない

PCManFMたまたま入ってたから使ってみたら
ディレクトリ一気に読み込もうとしたので確かに古いタイプの作りかも
サムネを1度作るまでは重いタイプ
軽量のrox-filerだとしてもサムネ作るまではという往年のファイラーが大体同様の処理

ハードが非力ってのもあるけども
btrfs（RAID1）ってxfsではなかったIO待ちが頻繁ある
プリエンプション禁止が多いのかな?

遅いうえに他のFSでは考えられない頻度で論理エラーを起こす

プリエンプション禁止とインテラプト禁止と段階がある？同じ？

今のLinuxファイルシステムは速度でext4、機能でbtrfs、ハード寿命でf2fsのどれかを使えって感じなので
btrfsの速度を叩いても意味はなく、ネイティブスナップショットを断念したxfsの生き残る道は速度でext4を超えるしかない

意味がないとかイミフだけど
btrfsはこれ以上犠牲者が出ないように消えて欲しい

犠牲になった方々のおかげで今は問題ないのでBtrfs使わせてもらいまっさ