ファイルシステム総合スレ その18at LINUX
ファイルシステム総合スレ その18 - 暇つぶし2ch565:login:Penguin
19/07/20 03:51:57.90 WfYnTXWF.net
ext4に続いてF2FSも大文字小文字を区別しないようにするオプションが作られているらしい

566:login:Penguin
19/07/20 06:23:21.98 Mi7o95f1.net
どこ読んでるかわかんないけど、コメントちゃんとあるように見えるけど

567:login:Penguin
19/07/20 08:08:29.10 bPfJoXMV.net
寄付なんて殆どが直接募集した奴が何割吸い取るかもわからない詐欺みたいなもんだぞ

568:login:Penguin
19/07/20 08:44:45.83 /RW5DImO.net
本人が集金してるんですがそれは

569:login:Penguin
19/07/20 09:05:30.53 DSGhLxxU.net
Linux上のZFSはLinux 5.0以降でSIMDサポートを復元する方法を考え出しました
URLリンク(www.phoronix.com)
近いうちに、新しいZFS On Linuxベンチマークを出すようにします。

570:login:Penguin
19/07/20 22:18:28.70 zeHgvHr/.net
なにその機械翻訳みたいな文章

571:login:Penguin
19/07/21 07:22:04.94 ROhY0MNF.net
>>561
chromeで自動翻訳してくれるからそのまま貼った。

572:login:Penguin
19/07/23 03:28:06.87 SCZ5bl9v.net
>>454
Ext2Fsdをインストールしてるとリムーバブルメディアを取り外せなくなるからアンインストールした
>>459
ファイルを更新した直後に青画面や停電などでクラッシュすると
次回起動時に該当ファイルが0で埋められる挙動があってデータを失ったことがある
ソフトはバックアップを作ってから更新するタイプだったがご丁寧にもバックアップまで0で埋められた

573:login:Penguin
19/07/23 03:45:44.40 SCZ5bl9v.net
>>440 >>445
bcachefsは知らんが
bcacheは安定性に難あり
条件を満たすとカーネルがメモリやスタックの汚染を報告して十数分後から数時間後にシステムが確実にクラッシュする
多数ある条件を回避していって最近になってようやく安定稼働に持ち込めた

574:login:Penguin
19/07/23 03:47:57.79 eYVlzNHh.net
それファイルシステムのせいじゃないだろ

575:login:Penguin
19/07/23 07:13:59.96 y0KQNHxf.net
xfsも一時期酷かったけど今は高評価だし、直ってれば何でもええよ

576:login:Penguin
19/07/23 08:55:55.62 gjJlsP0Z.net
何かを利用するって事は、その下側の使ってる部分の品質を上回れない事でもあるからなぁ
安定したばっかのを使うってのは(ry

577:login:Penguin
19/07/23 10:34:20.54 y0KQNHxf.net
そういうのを使ってあーでもないこーでもないと情報を交換したりバグを報告するのがOSSユーザーの嗜みであり楽しみでは?

578:login:Penguin
19/07/26 00:00:48.02 jkGHHOAL.net
今まで何もわからずUFA使ってたけど新NAS作ろうとして調べれば調べるほどファイルシステムが選べないわ
どれも一長一短あるしまるでリーマン予想を解いているみたいだ

579:login:Penguin
19/07/26 00:23:48.04 kTNN9g4P.net
いやxfs一択でしょ

580:login:Penguin
19/07/26 11:10:43.69 g7Og2WUg.net
XFS一択なの?

581:login:Penguin
19/07/26 18:49:37.46 /zAUPOSD.net
windowsから読み書きできない時点で、
XFSのせいではないが、候補から外したくなる

582:login:Penguin
19/07/26 19:45:54.44 x3ulgDdb.net
NASだぞ?

583:login:Penguin
19/07/26 20:48:37.30 /zAUPOSD.net
緊急時、データだけでも確保したいときのことを考えちゃうんだよ
XFSって、プラットフォームによってはLinuxからでも読めないことあるしなぁ
市販のNASで一度懲りたわ

584:login:Penguin
19/07/26 21:09:09.29 McqAipQp.net
そんなこと言い出したらNTFS最強って話になってくるし

585:login:Penguin
19/07/26 21:12:57.73 rbHyg+XJ.net
読めるファイルシステムでバックアップ取りなよ

586:login:Penguin
19/07/27 01:35:01.82 Ut6QMCX/.net
windows関係ないけど、xfsの何がという話をしないから
信心深いのかな?くらいにしか思わない
自分ならext4で無難かな

587:login:Penguin
19/07/27 10:50:20.98 95325KkT.net
>>577
RHEL7 のファイルシステムサイズの上限が ext4 は 50TB、xfs が 500TB。
2U サイズのラックマウントサーバだと 3.5インチHDDが12本は載るからext4
だと1パーティションに収まらないのよね。
上限は RHEL6 の時は 16TB だったからその頃から xfs を選択せざるを
得なくなった人が多い。
RHEL7 以降デフォルトが xfs になってるから不具合も一番潰されてるだろう
から、一番安心して使える。
何を以て安心っていうかというと、どれだけ多くのディスク/RAID装置で、
どれだけ多くの故障パターンを経験して来たかだと思ってる。
なので普及率はバカにできない。
>>574
カーネルを新しくするか逆に古くする、マウントオプション色々試す、はやった?

588:login:Penguin
19/07/27 11:50:18.10 c6O4WNXP.net
>>565
仮想マシンのゲストのWindows(10とXP)がクラッシュしたときも再現したのでNTFS実装の挙動で間違いない
俺はそれを見たとき対策を諦めた

589:login:Penguin
19/07/27 11:52:02.12 c6O4WNXP.net
同じNTFSでも2000ではファイルを閉じるときに必ず物理書き込みする挙動があって
クラッシュしたときにファイルが壊れる経験は皆無だった

590:login:Penguin
19/07/27 11:53:55.94 c6O4WNXP.net
XFSの噂はよく聞くが、どのベンチマークでもメタデータ更新系の成績がかなり悪い点は気になっている
細かいファイルをよく扱うLinuxとは相性悪いんじゃないだろうか?

591:login:Penguin
19/07/27 12:09:30.28 RKarvGRO.net
複数のファイルの遅延書き込みを溜め込みつつ、特定のファイルのフラッシュが必要になったら
確実にそのファイルへの変更結果をファイルシステムに矛盾が発生しない順序で
即座に物理層に反映・・・って、実は思ってる以上に複雑
その辺りは資本の力で開発されたファイルシステムに軍配が上がる

592:login:Penguin
19/07/27 13:47:26.05 6zG70b0r.net
遅くてもいいから壊れないものを

593:login:Penguin
19/07/27 13:47:41.85 Ut6QMCX/.net
>その辺りは資本の力で開発されたファイルシステムに軍配が上がる
んなこたーない、ntfs厨はもうこないでほしい

594:login:Penguin
19/07/27 14:09:34.66 RKarvGRO.net
何故NTFSに限定したのだろうか・・・

595:login:Penguin
19/07/27 14:17:25.71 Ut6QMCX/.net
限定したよ、だから何
帰れ

596:login:Penguin
19/07/27 14:34:02.96 SmtkTd2f.net
上にもあるが現在は正解がないというのが真実な気がする
正解がないので各派閥が宗教のように自分が使っているFSだけを信じ続けている
デジタルなのにやってることは人類が太古から続けているアナログ的な宗教に行き着くというのが感慨深い

597:login:Penguin
19/07/27 14:47:59.82 RKarvGRO.net
商用のファイルシステム以外はzfsとextの中間に位置する様なシロモノがないからな
その辺りにbtrfsが位置する予定だったんだろうけど、蓋を開けてみたらアレだったしな

598:login:Penguin
19/07/27 15:44:12.94 ynbj8IZE.net
>>578
ARMアーキテクチャのNASで使われているXFSは、
x86アーキテクチャのマシンからは、
エンディアンの違いで読めないことがあったんだよ。
(知ってたらゴメンね)
読む方法はある(シェアウェア)らしいし、
最近はバグらしきもの(FSかドライバか)が取れたらしいけど。

>>580
Linux物理マシンをext3で使ってたとき、
sync コマンドと、ALT+SysRq+s はなんか習慣的に押してたなw
まぁ、気休め程度にしかならんだろうけど。

599:login:Penguin
19/07/27 16:33:24.47 vPZ9hNH2.net
zfsさいっょ

600:login:Penguin
19/07/27 19:23:55.42 mQu6FNvv.net
クラッシュ耐性上げるにはCoWしか無いんだよな
bfrfs不安定と言われているけど突然の停止にはxfsやext4より壊れにくい

601:login:Penguin
19/07/28 02:04:51.78 OAxz9Pyz.net
xfsにもフォーマット時のオプションで
CoWが可能になったの知らないのか

602:login:Penguin
19/07/28 09:43:26.39 8zKDGL71.net
>>591
メタデータについてはジャーナリング機能の実装段階でそれ相応の物が
入ってて、CoWでは耐性上がりようがないって認識だわ。
そもそもシステムコールで明示的に呼び出さない限り CoW にならないわけで、
CoW ではなくスナップショットファイルシステムというべきじゃないかな。

603:login:Penguin
19/07/28 21:18:10.31 CB5E+oZy.net
今までファイルが壊れた経験があるファイルシステム
・btrfs
・ntfs

604:login:Penguin
19/07/29 10:42:58.53 AMCKbOHw.net
ファイルシステムの頑健性っていうのはソフトウェアのレイヤーで全てが語れるわけじゃない
あるファイルシステムのある機能が、あるディスクアレイでは頑健性を上げることもあれば逆もありえる
仮想マシンだってそう、むしろレイヤーが重なる上にハードウェアチートまであるから
クラッシュ時の挙動がファイルシステム側由来なのかなんてfs設計者でも簡単には分からん

605:login:Penguin
19/07/29 19:08:03.66 4QwhTaJH.net
スナップショットとシンプロビジョニングはオープンソースだとテストのやり込みが足りない・
テスト量がシステムの修正に追いついていないせいで安定しないイメージだわ。
これら+RAID-Z/VRAID系は長期利用時のフラグメンテーション対策がお留守な感じなんで
スナップショット等が必要な業務環境でオープンソース系ファイルシステム使うのは怖い。

606:login:Penguin
19/07/29 19:58:02.26 zJDJcz0l.net
RAID-ZってZFS以外使ってるんだっけ?
今のSolarisとFreeBSDとZoL,どれが一番安定してるんだか

607:login:Penguin
19/07/29 22:46:46.27 4QwhTaJH.net
>>597
Linux 外だが Isilon の OneFS がストライプ長可変なのでほぼ同じもの。
こちらは RAID-Z4 相当まで実装してる。

608:login:Penguin
19/07/30 03:59:06.50 qLodTkR5.net
>>597
Solaris

609:login:Penguin
19/07/30 05:28:26.62 HF8yxYK2.net
>>597
意味がわからないけどRAID-Z=ZFSだろ?

610:login:Penguin
19/07/30 15:41:25.39 0CM/a0KN.net
>>600
それは>>596に言ってくれ

611:login:Penguin
19/07/31 16:24:21.03 esTiVmHP.net
JFSやXFSで満足しないならもうLinuxを棄てるしかないんや

612:login:Penguin
19/07/31 16:49:32.80 Wv68Jyik.net
>>602
バイバイsoralis
君のことはもう忘れたよ

613:login:Penguin
19/08/01 04:08:51.36 BMyzMKl4.net
次元、五右衛門 久しぶりだなー
カール 今日はご主人様と一緒じゃないのか?
(カールという名前はわしの他はもう Soralis様しか知らないはずだ。)
Soralis? そうか、お前のご主人は Soralisってえのか..。
.....
.....
銭形: Oracleはとんでもないものを盗んでいきました。
   それは貴方のファイルシステムです。

614:login:Penguin
19/08/01 05:02:38.99 rA7aLj1x.net
もしかして:Solaris

615:login:Penguin
19/08/01 07:08:56.64 /5jO1LjD.net
soralis?solaris?
誰でぇ、それは

616:login:Penguin
19/08/01 12:27:48.03 FPgX7+/Y.net
ソラージ

617:login:Penguin
19/08/03 04:46:19.02 okf0cS5M.net
結局色々やってext4に行き着いた

618:login:Penguin
19/08/03 07:21:09.50 67ZtkjFh.net
アップデートもないしほとんど使っている人はいないと思うけどメインのNoteの/homeをnilfs2で運用初めてそろそろ10年。
それ以降PC自体が3代目でPC替えたらDDではなくてcpで移したので10年連続で同じパーティションを10年運用したわけではないけど、FSが飛ぶような深刻な自体は使い始めに操作を間違ったときくらい。
Nilfs2の仕様上FSフルにしてしまうと面倒なことが起こるけど、それも10年で2回程度。
概ね24時間分ぐらいは遡れるようにしているので間違って書き換えたり消したりしてもすぐ取り返せる安心感が嬉しくて使っている。
といってもその作業も10年で3回程度だけど。。。

619:login:Penguin
19/08/07 15:48:47.13 tHruglCb.net
CoW版のXFS使ってみたけどめっちゃ安定してるわ
完全に常用も可能な漢字

620:login:Penguin
19/08/07 16:06:32.13 D6dfz/XB.net
そんなゴミみたいな煽り文句は他所でやれ

621:login:Penguin
19/08/07 16:13:26.51 VOvKzyRf.net
最低限どういう手法でテストしたのか位は書いてもらわんと何も意味ないわな

622:login:Penguin
19/08/07 19:19:11.92 eVw1mf5N.net
そのくらいゆるふわ意見だと我が家のbtrfsも一度もデータ飛んだこと無いし、動画圧縮で凄く容量削減してるし、山ほどスナップショット撮れてるし、ものすごくtrimできるし、死ぬほど安定してる

623:login:Penguin
19/08/08 16:07:29.83 BnM28ZaO.net
100台月ぐらいメタデータ・シーケンシャル・ランダムアクセスの混在負荷テストすりゃいいかなと思っている

624:login:Penguin
19/08/09 12:25:30.55 2xxnQ7nf.net
Ubuntu 19.10からZFSのサポート強化 2019/08/09 08:33 後藤大地
URLリンク(news.mynavi.jp)
Canonicalは8月7日(米国時間)、「Enhancing our ZFS support on Ubuntu 19.10 - an
introduction - Ubuntu Blog|Ubuntu Blog」において、この秋にリリースが予定されて
いる「Ubuntu 19.10」のデスクトップ版からZFSのサポート機能を強化する予定だと伝えた。
このまま順調に開発が進めば、Ubuntu 19.10 Dekstopでは実験的という位置づけながらも、
ルートファイルシステムをZFSで構築することが可能になると見られる。
Canonicalは今後、ZFSの採用範囲を広げるとしており、順次新しいUbuntuでZFSの利用を
拡大することが予想される。また、デスクトップ版は最初の取り組みとしており、今後
サーバ版にもZFSの適用が拡大する見込み。ZFSは人気の高いファイルシステムであり、
多くのユーザーに歓迎されると思われる。
LinuxにおけるZFSの利用に関してはライセンスにおいて長い間疑念が存在している。
Canonicalは数年前にライセンスに関して調査を行い、LinuxにおけるZFSの利用はライセン
ス違反にはならないという結論を出しており、それ以降、UbuntuでZFSを利用するための
取り組みを続けている。
ZFSはモダンなファイルシステムの1つ。ストレージ・アプライアンスやストレージ・シス
テム、NASで広く採用されている。提供されている機能が豊富で、さまざまな稼働実績が
あり、ユーザーから高い支持を得ている。Linuxディストリビューションの中でも高い人気
があるUbuntuでZFSが利用しやすい状況になることで、ZFSの利用範囲が広がると見られる。

625:login:Penguin
19/08/09 16:56:19.31 9F/SVKov.net
文字数の割には情報量の薄っすい記事だな。
具体的にどう拡大するのか何も書かれていない。

626:uin
19/08/09 19:21:58.09 rfEV2Og4.net
Ubuntu は技術的という意味以外で危ない橋を渡ってくれていいな。
Debian派なので、使ってないが。

627:login:Penguin
19/08/10 06:20:36.38 ZWJAdRCH.net
LinuxにはXFSやJFSという素晴らしいFSがあるというのに
btrfs(笑)

628:login:Penguin
19/08/10 23:06:34.79 2XkczDqc.net
そろそろOSやデバイスによらない究極のファイルシステムを誰か作って欲しいわ

629:login:Penguin
19/08/11 00:16:24.96 oUkRG+KV.net
求められてるものが違うから無理でしょ

630:login:Penguin
19/08/11 00:55:00.87 Uf+U5nYS.net
そもそもファイルシステム自体がOSの一部だからな

631:login:Penguin
19/08/11 01:10:53.54 QM4D0Z+6.net
?

632:login:Penguin
19/08/11 04:25:14.47 ha8y5VIz.net
FAT32というほとんど全ての環境でサポートされている素晴らしいファイルシステムがあるぞ

633:login:Penguin
19/08/11 08:25:51.10 fbfbhXo0.net
ていうか「普通に」使う分にはFAT32でも十分な気がする。
そんな馬鹿デカい容量を扱わんし

634:login:Penguin
19/08/11 09:45:05.49 iIn5DM/X.net
OSの一部というよりOS設計に密結合しとるから、ファイルシステムだけ分離してもあまり意味が無いというか

635:login:Penguin
19/08/11 13:26:31.69 cuLqexzl.net
理想のファイルシステムって何よ?

636:login:Penguin
19/08/11 13:48:18.92 maGT1VI+.net
軽量なZFS

637:login:Penguin
19/08/11 15:23:31.80 zxPpiGnO.net
OSから独立していても、特定のOSや企業が関わると党派性の餌食になって正当な評価が得られなくなってしまうので
具体的にはAppleとMicrosoft
アップルに関わると不当に高評価しようとする勢力によって歪められ
マイクロソフト由来のものは不当に低評価される傾向にある
前者はMac/BSD採用前後のZFSを巡る扱いにおいて顕著であり
後者はNTFSの長年にわたる(低)評価について異論を待たない
まあ平たく言えばゲハ脳のリンゴ信者の声ばかりでかくて実態を反映してない
ノイジーマイノリティうぜえって話で終わる

638:login:Penguin
19/08/11 20:51:04.63 b1ksZLfY.net
>>626
バグが無くて、使い方によらず高速で、
いかなる時もデータが失われず、
物理的な制限もないとか。
現状の物理的な容量を超えて、
無制限に記録できたりしたら、
喜ぶ人ば多いんんじなかろうか。

639:login:Penguin
19/08/11 21:29:32.28 3JMjmUyB.net
>>624
FAT32じゃだめ理由は容量じゃなくて、
セキュリティとUnicode対応だよ
セキュリティは、システムドライブとして使うなら必須だが、
いろんなマシンに接続する外部ストレージだと意味ないので無くても良い
でもUnicode対応は必須

640:login:Penguin
19/08/12 01:09:10.91 d4sdreTy.net
FAT32はUTF16LEに対応している

641:login:Penguin
19/08/12 02:29:50.29 NZmR/0AL.net
>>626
完成したReiser4

642:login:Penguin
19/08/12 02:40:46.93 NokuNn6B.net
>>630
>>631でも書かれてるとおりUnicode対応してると思うけど?

643:login:Penguin
19/08/12 06:28:53.82 NokuNn6B.net
と思ってざっと検索してこのページを見付けてそして絶望した。
URLリンク(stackoverflow.com)

644:login:Penguin
19/08/13 02:42:34.19 aG+MUqdm.net
exFATが4G超えもUNICODEも対応した理想の外部ストレージ用ファイルシステムになるはずだったんだけどな
ライセンスの問題なのかlinuxではネイティブ対応せず使い勝手が悪い
FAT32がWindows/Linux/MacどころかBIOSが認識してフラッシュの書き換えに使えるのと比べると汎用性が低い

645:login:Penguin
19/08/13 04:50:56.59 hjIX5LBa.net
>>635
MSの規格を使うと、惑わされてろくなことがない。

646:login:Penguin
19/08/14 06:07:09.42 j+CrCYgD.net
LinuxでのexFATはもうすぐネイティブサポートされるかもしれない
サムスンがクローズドで開発していたんだけど間違えてgithubに公開したらGPL違反だとバレてオープンソース化した
それをLinuxのメインラインに取り込んでしまおうと言う議論がされている
特許についてはMSが去年OINに参加したから問題ないと思われる

647:login:Penguin
19/08/14 06:16:42.69 446s3CFR.net
こマ?

648:login:Penguin
19/08/14 08:15:42.47 wXe1OdwF.net
そういえばOIN入ってたなmicrosoft
昔はOINの敵だったのにかわったもんだ

649:login:Penguin
19/08/14 12:22:52.78 mQ9mwTdn.net
Githubで公開しちゃった奴は、こうなる流れを見越していたんか。

650:login:Penguin
19/08/14 14:26:38.36 wc+Iy5bm.net
公開と言うよりも正義の告発だろう
GPL違反に加担する行為に良心の呵責が耐えられなかったのさ

651:login:Penguin
19/08/14 21:45:17.18 AVLJRAxc.net
なんか、彼の国らしい話だな

652:login:Penguin
19/08/15 05:46:12.96 W1sEpxJ4.net
>>637
MSが加盟した時点で、特許問題クリアされてるし、MS側からカーネルドライバーのリファレンス実装や、ユーティリティが出てくるの時間の問題なように思うけど。

653:login:Penguin
19/08/15 11:23:41.51 wrlhxu7n.net
DropboxはLinux上のZFS、XFS、Btrfs、eCryptFSのサポートを復活させています
URLリンク(itsfoss.com)
Dropboxベータビルドにより、ZFS、XFS、Btrfs、eCryptFSファイルシステムのサポートが追加されます

654:login:Penguin
19/08/15 20:20:35.65 la00X25b.net
>>644
あ!
去年の今頃ファイルの上にext4のファイルシステムつくってループバックマウントしたんだけど
またXFSでdropbox使えるようになった!

655:login:Penguin
19/08/15 21:41:24.78 BwZ8qz5R.net
>>644
どもです

656:login:Penguin
19/08/15 23:57:45.40 q1J1ZnUl.net
>>644
homeをnfsマウントしてたらやっぱりDropboxつかえないんだよね?

657:login:Penguin
19/08/21 22:13:21.76 1QPw9kaw.net
FAT32がUnicodeに(一応)対応していたとは知らなんだ。

658:login:Penguin
19/08/21 22:36:35.26 1QPw9kaw.net
ついでに言うと日本産業規格で定義されているとも知らなんだ(俺が無知すぎるだけw)

659:login:Penguin
19/08/21 23:41:34.91 M7Fu+WRI.net
FAT32どころかFAT16もFAT12も同様

660:login:Penguin
19/08/21 23:51:24.49 0CXkpgBN.net
「どころか」の使い方おかしいだろ

661:login:Penguin
19/08/22 01:16:51.67 dj60c2S0.net
「AどころかBもX」
と言った時は
「Aは前提として(時として当たり前に)XだがAよりXっぽくないBもまたXである(驚きの感情)」
という含意があるんだから,使い方としては全うな部類だろう。
FAT32はU


662:nicodeに対応してるけど,それより他の機能で劣るFAT16・FAT12にさえUnicode対応である(驚きの感情)



663:login:Penguin
19/08/22 05:33:27.83 1Yr3egmY.net
流れから、FAT32はJIS規格だけど古いFAT16,FAT12もJIS規格だ(まぁ順当にそうだろう)、という解釈も

664:login:Penguin
19/08/22 06:15:16.86 dj60c2S0.net
たしかに。

665:login:Penguin
19/08/22 11:06:57.22 NSVYAGiU.net
ファイルシステムはサイズがPBを超えてからが勝負

666:login:Penguin
19/08/22 12:20:02.77 m9kjglry.net
Unicode対応はFAT12でもVFATなら対応可能って奴じゃないの?
MS-DOSで見ると謎の文字列になるやつ
FreeDOSでもそうじゃなかったっけ?
UEFIはどうだったか覚えてない
>>655
個人で勝負に挑むには、月間の消費電力どれくらいになるんだろう

667:login:Penguin
19/08/22 12:21:32.17 jWTG6YZX.net
FAT64を作れば最強じゃね?

668:login:Penguin
19/08/22 12:36:54.87 m9kjglry.net
新たに作らなくてもexFATでいいんじゃね?

669:login:Penguin
19/08/22 16:22:24.42 pq9swZ6w.net
誰かVirtual Data Optimizerを試した
人はいませんか?RHEL 7.5から使える
重複排除の機能拡張っぽいのだが。
URLリンク(github.com)

670:login:Penguin
19/08/22 16:40:08.64 c/3upDZj.net
>>550
実装できたみたいね

671:login:Penguin
19/08/25 20:40:25.94 hTk0r0Sf.net
exFATはほぼFATじゃないでしょ。少なくともFAT32やらとはかなり互換性を失なってる…筈。

672:login:Penguin
19/08/26 14:38:35.90 ebuP7us/.net
ディスクの扱える最大容量が違うのに
互換性なんて持たせられるはずがないべ

673:login:Penguin
19/08/26 18:10:15.54 Q2M/7GD/.net
bcachefsの登場で
中身のファイル名が長すぎて解答できないRARファイルが
いよいよ解凍可能になるぜ

674:login:Penguin
19/08/27 23:26:23.88 cl90n3Lm.net
40年前に100EBのファイルシステムを想定したFS作ってればよかったのに

675:login:Penguin
19/08/28 00:51:29.92 roj4LxzO.net
そんなの作ってもメモリ不足で使えねえよ

676:login:Penguin
19/08/28 02:44:43.76 K9W23MUl.net
大容量でもメモリ不足にならないよう作れるだろうに。。

677:login:Penguin
19/08/28 03:13:56.82 XY99YJWD.net
仮にメインメモリが不足しなくっても上位bitが無駄になりまくって記憶媒体の無駄遣いになってたろう
当時のKB単価知らんのけ?

678:login:Penguin
19/08/28 03:24:40.69 jakMXSf+.net
俺がコンピュータを使い始めた頃は1MBうん十万なんて時代だったしな

679:login:Penguin
19/08/28 07:49:31.84 j5W+ovEv.net
ビット単位で惜しんで実装する時代だったな
そんなもん設計しても実装して運用出来るメモリ容量がない

680:login:Penguin
19/08/28 07:59:58.47 db/ocE9c.net
>>664
64KBあれば個人には使い切れない(笑)
と云われていた時代に何を云うとるか(笑)

681:login:Penguin
19/08/28 08:09:15.90 jUTn4eZr.net
ビルゲイツ「640KBのメモリがあれば十分」はデマだった [無断転載禁止]c2ch.net
スレリンク(prog板)
ビルゲイツが言ったとされる「640KBのメモリがあれば十分なはずだ」は実はデマでした
本人自ら行っていないと明言しており、第三者の調査でもそのような発言は見つかっていません
URLリンク(pc.watch.impress.co.jp)
> 「640KBのメモリがあれば十分なはずだ」なんてことを言った覚えはないんだけど。
> 2005年のWinHECは、ビル・ゲイツ会長のこんなジョークともボヤキとも受け取れる言葉で始まった。
その発言の動画    
URLリンク(www.youtube.com)


682:watch?v=ElDgsQAzrLo > Bll Gates at WinHEC. Claimed to have never said that computer would never need more than 640K memory インタビューで、そのようなことは言っていないと明言しています。 https://web.archive.org/web/20110202030010/http://www.usnews.com/usnews/biztech/gatesivu.htm Q. Did you ever say, as has been widely circulated on  the Internet, "640K [of RAM] ought to be enough for anybody?" No! That makes me so mad I can't believe it! Do you realize the pain the industry went through while the IBM PC was limited to 640K? The machine was going to be 512K at one point, and we kept pushing it up. I never said that statement?I said the opposite of that. The '640K' quote won't go away -- but did Gates really say it? (ビルゲイツは本当にそういったのか?) http://www.computerworld.com/article/2534312/operating-systems/the--640k--quote-won-t-go-away----but-did-gates-really-say-it-.html 第三者の調査でも、根拠なしの主張を根拠に主張しているだけ(ループしてる)で 最初の出典が存在しないことを突き止めています。 http://quoteinvestigator.com/2011/09/08/640k-enough/ つまりビルゲイツは「640KBのメモリがあれば十分なはずだ」なんて 一言も言っていません。 これは英語サイトでは当時検証済みの話です。 情弱日本人が知らないだけです。



683:login:Penguin
19/08/28 08:09:50.50 jUTn4eZr.net
いつの間にか「ビルゲイツ 640KB」で検索したら↑のスレが
一番目に来るようになってるなw

684:login:Penguin
19/08/28 08:20:42.08 U92vyvJf.net
>>667
お前が設計したら無駄になりまくるからといって
それがもっとも効率が良い設計だと思わないで

685:login:Penguin
19/08/28 08:38:43.64 XY99YJWD.net
>>673
100EBを表現しなければならない可能性のあるとこには必ずそれだけのbitが必要になる筈なんだが
可変長符号化だってコスト0(bit)って訳じゃないんだぞ

686:login:Penguin
19/08/28 08:47:45.84 /ip8C1e4.net
考え方次第で最初に全サイズを読み込んでそれに基づいたbit割り振るようにすればいいだけなのでは?

687:login:Penguin
19/08/28 09:27:43.57 XY99YJWD.net
そのサイズは何bitでわかる?w

688:login:Penguin
19/08/28 10:29:36.59 U92vyvJf.net
>>674
100EBを表現しなければならない状況でそれに必要なbitを使うのは無駄ではない
問題は100EBを表現しなくてもいい状況で無駄に使わないことだろ

689:login:Penguin
19/08/28 10:33:24.68 XY99YJWD.net
>>677
だから1byteなのか2byteなのか3byteなのかの可変長符号にもコスト掛かるっつってんだよw

690:login:Penguin
19/08/28 11:26:30.77 U92vyvJf.net
>>678
コストが掛かるのは当然だ
コストゼロでなければ「無駄になりまくって」るというならお前の頭がおかしい

691:login:Penguin
19/08/28 12:33:20.72 XjV2vzUW.net
そもそも容量増加スピードなんてのは予測できるわけでそれに合わせてFSもロードマップ作って拡張すりゃよかったんだよ

692:login:Penguin
19/08/28 21:30:25.06 XY99YJWD.net
当時のKB単価もビット判定やら何やらに掛かるステートも知らずに、後出しで難癖付けるだけなんて簡単でいいよな
てかそう思ったんならおまえが普及させりゃ良かっただろ�


693:チていう



694:login:Penguin
19/08/28 21:35:39.43 +xLGKmxQ.net
今だと瓦HDDに最適化したファイルシステム開発したら歓迎されそう
(もうどこかやってるかな?)

695:login:Penguin
19/08/29 01:12:11.08 VQiAWJJ4.net
瓦HDDの中でホスト側で制御するものは、その手のファイルシステムを前提にしている

696:login:Penguin
19/08/29 01:16:27.76 VQiAWJJ4.net
瓦は読み込みと書き込みの最小単位が異なる点でSSDと同じなので
SSD向けのファイルシステムが効果的な可能性が高い
例えばCoWやバケット単位の管理を採用したやつ

697:login:Penguin
19/08/29 06:53:52.44 yqJY2zQ1.net
>>637
URLリンク(www.phoronix.com)
> Microsoft Publishes exFAT Specification, Encourages Linux Support
キタ━━(゚∀゚)━━!!

698:login:Penguin
19/08/29 08:24:17.14 ayv/fTUM.net
>>685
やっぱりMicrosoftは正義やな

699:login:Penguin
19/08/29 09:17:06.65 57E44Kd+.net
最近は反MSの連中よりMSのほうがOSSに貢献してる

700:login:Penguin
19/08/29 09:31:29.66 oTY9cNJu.net
ntfsも公開してくれよん

701:login:Penguin
19/08/29 10:37:08.37 IgCGENYH.net
>>685
キタ━━(゚∀゚)━━!!

702:login:Penguin
19/08/29 11:53:24.06 ayv/fTUM.net
>>688
NTFSは公開してもファイルシステムの高度なセキュリティ能力を
Linuxにマッピングできないのであまり意味がないな

703:login:Penguin
19/08/29 12:26:30.72 5xSjyKa3.net
>>682
瓦最適化はWDの中の人がbtrfsにパッチ投稿中。

704:login:Penguin
19/08/29 18:23:14.00 17OYqypV.net
Microsoft、Linuxカーネルで公式に「exFAT」サポート
URLリンク(www.itmedia.co.jp)

705:login:Penguin
19/08/29 18:31:46.62 3gIOV6hV.net
>>691
はえー。俺の鯖ちょうど瓦でbtrfsだわ、ありがてえ

706:login:Penguin
19/08/29 20:54:27.48 7ODgbVNJ.net
>>687
反MSって具体的になに?Oracleとか?

707:login:Penguin
19/08/29 21:12:57.84 V76BsNE3.net
Windows Storage Server 2016の重複排除機能、優秀すぎてワロタ

708:login:Penguin
19/08/29 21:56:07.88 71eCL6Dr.net
>>689
どちらかというと、ユーティリティ側の出来がよくなってほしいな(´・ω・`)
今、fsck.exfatがチェック出来るだけ状態だからね。
マウントするだけならfuse経由でできるし。

709:login:Penguin
19/08/29 22:30:20.18 /Ysvkkai.net
>>695
今のところ重複排除がまともに運用できるのWindows Serverだけだな
ZFSも一応使えるけど使う人居ないだろって感じの実装

710:login:Penguin
19/08/30 01:10:38.60 49Usa2R4.net
>>690
同じ理由でextXもWindows上では使い勝手が非常に悪い
NTFSもextXもシステムに特化しすぎて細かい仕様がなじまない
低機能なFATがいまもデータ交換用に普及してる理由でもある

711:login:Penguin
19/08/30 01:11:23.89 49Usa2R4.net
exFATの構造
URLリンク(homepage3.nifty.com)

712:login:Penguin
19/08/30 01:18:35.79 49Usa2R4.net
exFATは他の近代ファイルシステムに合わせてメタデータをファイル化したのはいいけど
FATが固定テーブルのままだから空き領域ビットマップも固定テーブルで良かったと思う
あとFATエントリが32bitのままだから16TB超えると影響出始める
リムーバブルで16TBは当分先とは言え将来はわからないぞ

713:login:Penguin
19/08/30 01:41:03.03 49Usa2R4.net
MSがさっそく公式に公開してたじゃないか
URLリンク(docs.microsoft.com)

714:login:Penguin
19/08/30 04:24:29.13 itEjT5Wb.net
>>700
> あとFATエントリが32bitのままだから16TB超えると影響出始める
exFATの理論上の最大ボリ�


715:�ームサイズは128PB(ペタバイト)だよ 128 * 1024TB = 131,072 TB。実装上の問題で 512TBが推奨とされてるけど https://en.wikipedia.org/wiki/ExFAT



716:login:Penguin
19/08/30 04:38:30.70 itEjT5Wb.net
なるほど、FAT32は名前に反してクラスタ数として28bitしか使ってなかったのか。(exFATは32bit)
1クラスタのサイズがFAT32は32KBまでだから、FAT32の理論上のボリュームサイズは8TB
exFATでは32bit全部を使うから、これだけでも128TBまで使えることになるが、
さらに1クラスタの最大サイズが32KBから32MBに増えたから、理論上のボリュームサイズは128PBになるんだな
FAT32もexFATも実際の実装はそこまで対応してないから減るわけだけど
将来的に対応の必要性があれば互換性を保ったまま増やせるわけか

717:login:Penguin
19/08/30 11:49:45.26 xVO3b390.net
>>691
btrfsなんて不安定で微妙なFSじゃなくってext4とかXFSで瓦対応してクレヨン……
と思ったが瓦はCoW向きなのか
だったら仕方ないかorz

718:login:Penguin
19/08/30 18:29:14.36 BfSogZjl.net
マジかよ今後はexfat一択じゃん

719:login:Penguin
19/08/30 19:36:46.24 wK/ekzyO.net
でもexfatってジャーナリングファイルシステムじゃ無いんでしょ

720:login:Penguin
19/08/30 20:17:53.57 BfSogZjl.net
マジかよじゃあexfat要らね

721:login:Penguin
19/08/30 21:52:37.76 xOfxtSvx.net
やっぱりntfsが最強だな

722:login:Penguin
19/08/30 22:33:18.67 lt7x2d9b.net
>>704
xfsはSMR対応やる気あるだろ

723:login:Penguin
19/08/31 01:01:49.85 PjcUVRL7.net
xfsのCoWがどんな感じかだな
btrfsはCoWだけじゃなくパケットライトのような構造でSSDへの負担の軽減と効率化を図っている
副作用でデータベースのようなランダム書き換えを繰り返す用途と非常に相性悪いけどな

724:login:Penguin
19/08/31 07:09:26.49 R786WVAl.net
>>706
> でもexfatってジャーナリングファイルシステムじゃ無いんでしょ
ジャーナル対応は可能だよ。

725:login:Penguin
19/08/31 09:11:35.30 PjcUVRL7.net
可能なのと実装しているのは大きく違う
ext2にジャーナルファイルを追加してext3としたように後付ならどうにでもなるが
それでも名前を変えるレベルの変更になる
互換性が重要なリムーバブル向けで大きな変更はできないだろうな
exFATは冒険を避けたのか内部的にはけっこう中途半端な拡張になっている

726:login:Penguin
19/08/31 11:53:17.85 M9ADFjBr.net
ディレクトリエントリ構造がvfat引き継いでんのがクソ

727:login:Penguin
19/08/31 12:43:47.93 KGfTBrB+.net
kwsk

728:login:Penguin
19/08/31 14:12:33.52 JnSDyXRZ.net
kwskっていうのはクソの理由だぞ。
vfat引き継いでるということの説明をされても
クソの理由にはならないからな
ってかvfat引き継いでないがなw

729:login:Penguin
19/09/03 17:02:34.99 yL/ahKNe.net
Linuxに関して言えば,
組込みLinuxが入ってる携帯端末とかはexFATを採用しそう。
そうじゃないのはXFSやext4でいい(「でいい」というか,「が十分使える計算機資源がある」

730:login:Penguin
19/09/03 17:44:40.69 xfgJCc5v.net
exFATを使うというのが単に外部ストレージのファイルシステムとして受け付ける(マウントして読み書きに対応できる)という話なら対応が進むだろうが、
システムやユーザーディレクトリがexFAT上に置かれるようになる、システムパーティションとしてexFATが採用されるという話なら、それは無いんじゃないの?
システムパーティションとしてFATやexFATを利用可能な実装、あるならそれがデフォルトの実装というものが実在するなら、むしろ見てみたい(提示して欲しい)。
パーミッションなにそれという無法の罷り通る組み込み実装というものが実在するなら恐ろしい話だ。
NTFSならUNIXの(POSIXの)パーミッション機能を全て内包した上でより高度かつ緻密な権限設定なども可能だが、それらの機能をUNIXからは満足に扱えず持ち腐れるしかないし、
NTFSをシステムパーティションとして設定可能なディストリというものも記憶に無い(Windowsとの共存を念頭に既存のNTFSパーティション内に構築されるものならあったが)

731:login:Penguin
19/09/03 19:05:09.69 B9+IOgvJ.net
Androidではf2fsとext4が使われているな
これは端末によって分かれる
それとユーザー領域にsdcardFSとか言うのが使われている

732:login:Penguin
19/09/03 19:52:16.19 8FoKpEbS.net
>>717
今北産業

733:login:Penguin
19/09/03 20:37:54.95 2aAU5+p7.net
>>717
今でも使えるか知らないけどUMSDOSというFAT用の拡張があるよ
仕組みはVFATのような感じで長いファイル名とパーミッション等を使える
いにしえの文書
URLリンク(archive.linux.or.jp)
それとNTFSのACLと同等の機能はXFS等でも使えるようになっているよ

734:login:Penguin
19/09/03 20:56:32.09 2aAU5+p7.net
>>717
ACL関係もいにしえの文書だけど
URLリンク(www.itmedia.co.jp)
POSIX ACLはSamba以外では積極的に使われない機能だから
あまり解説されていないだけ

735:login:Penguin
19/09/04 01:58:46.87 AfE9OQrQ.net
>>721
NTFSと同等なのはPOSIX ACLじゃなくてNFSv4 ACLとか、HFSやAPFSに実装されている方

736:login:Penguin
19/09/09 22:59:51.66 SszYAJmS.net
互換性は別にして、機能としてPOSIX ACLになくて、NTFSやNFSv4 ACLにある物って何があるの?
デフォルト値とかが違ってWindowsと全く同じ挙動にはできないけど、機能的には同等だと思ってた。

737:login:Penguin
19/09/10 02:47:59.60 7v2JkFhP.net
>>723
POSIX ACLはパーミッションの素直な拡張で、
・ユーザーやグループ毎にRWXの3種類の許可のオンオフ
・ディレクトリにデフォルト値を設定して子孫に継承させる
だけ。
NTFSの方は、そもそも権限が13種類ぐらいあって複雑怪奇。例えば、
・属性(タイムスタンプとか)の読み込みだけ許可
・ファイルへの追記だけ許可(上書きは不可)
・ファイルは作れるけどサブディレクトリは作れないディレクトリの実現
・ファイルの削除権限をファイル自体に設定
・ファイルを作れるけど消せないディレクトリの実現
・ACL自体の変更権限や所有者の変更権限を設定
などが可能。継承も、
・ファイルとディレクトリで別々に設定
・子には継承させるが孫には継承させない設定
ができる。更に
・許可/拒否の設定が両方ある
・ACLの適用順を明示的に設定できる
ので、ホワイトリスト式とブラックリスト式を複雑に組み合わせられる(これはGUIでは設定不可で、コマンドでやる)

738:723
19/09/10 03:14:54.16 ux9dqJdd.net
>>724
おお。確かに全然違う。NTFSそんなに機能あったのか。
勉強になった。ありがとう。

739:login:Penguin
19/09/10 04:08:11.19 QHsS5imR.net
機能的にはミニコンやメインフレームで大規模なDB載せるような用途にも対応できるような作りだしねえ…
これでもう20年も実績あるんだから、いっぱしのファイルシステムですな >NTFS

740:login:Penguin
19/09/10 04:31:51.09 c/QawrHU.net
そのNTFSの機能はだいたいZFSで網羅してるな

741:login:Penguin
19/09/10 05:23:00.38 h9c2d3nY.net
ZFSで網羅してるとして、何のコマンドでやるの?
ZFS専用コマンド?

742:login:Penguin
19/09/10 06:24:47.98 hXcE461p.net
ZFSってIRIX発祥だったように記憶しているのだけど
IRIXはつまり一般的なPOSIXの枠を超えたACLを独自に実装していたということですかね?

743:login:Penguin
19/09/10 06:35:34.93 c/QawrHU.net
>>728
意外なchmodで全部


744:行ける。まるで呪文だがw setfacl -m owner@:full_set:allow,group@::allow,everyone@::allow acl_test.txt https://docs.oracle.com/cd/E24845_01/html/819-6260/gbacb.html#scrolltoc >>729 Solarisでそ?



745:login:Penguin
19/09/10 06:41:05.19 c/QawrHU.net
>>730
自己レス
ごめん
chmod A3=user:venkman:read_acl:allow filename はSolaris
freebsd はsetfaclでやる実装だった「

746:login:Penguin
19/09/10 13:55:09.50 6sIzNa2X.net
> 729
XFSはIRIX
ZFSはSolarisです。

747:login:Penguin
19/09/10 15:10:51.24 TIJq+nNn.net
ext4でいいじゃん

748:login:Penguin
19/09/10 16:55:49.82 +5M9tkhk.net
>>724
詳しい解説サンクス!
多すぎて頭がフットーしそうだよお

749:login:Penguin
19/09/10 16:56:33.60 +5M9tkhk.net
>>730,731
こっちも詳しい解説サンクス!

750:login:Penguin
19/09/10 19:00:28.68 nfLMQN5s.net
>>732
ああそうだ、IRIXはXFSだったわごめん
おれ個人では普通に信頼してるFSだけど、Linux界隈では個人だと使ってる人あまり見ないよね…

751:login:Penguin
19/09/11 01:29:58.78 U4ts0n/J.net
LinkStationのデフォルトがXFSだったはずたから知らないうちにXFS使ってる人は案外いそう

752:login:Penguin
19/09/11 02:15:06.94 XGTr0XqS.net
CentOS7のデフォルトがXFSだから、個人でも使っている人は沢山いるはず

753:login:Penguin
19/09/11 09:22:32.33 Im0aUzbI.net
NTFSってマジで「多」機能なんだな

754:login:Penguin
19/09/11 20:34:04.82 U4ts0n/J.net
多機能すぎてその詳細を理解してる人も使いこなせる人も少ない…MSにさえ
おまけにフルに機能使いこなそうと思ったら非公開API使わなきゃいけないとかいう残念さ

755:login:Penguin
19/09/11 22:52:50.67 Im0aUzbI.net
URLリンク(m.facebook.com)
これを思い出した

756:login:Penguin
19/09/12 08:02:48.44 A7RqdNx4.net
素直にXFS使っとけ

757:login:Penguin
19/09/12 14:07:40.59 kpioEvUr.net
XFSは多機能すぎて誰も使いこなせない

758:login:Penguin
19/09/13 10:02:05.12 /kG8R/3p.net
LinuxのXFSにもGRIOあるのかなぁ

759:login:Penguin
19/09/15 08:26:10.55 A0tbtNjH.net
EROFSがLinux5.4でメインライン入りするらしい
リードオンリーファイルシステムだから使いどころは限られるが
すでにスマホで動いているので実績はある

760:login:Penguin
19/09/15 09:51:04.18 uMzOqD6G.net
え、エロFS……

761:login:Penguin
19/09/15 13:31:08.77 ua5r3kDz.net
エッチFS!

762:login:Penguin
19/09/15 17:37:09.38 3/04JcE1.net
>>743
何で圧縮は無いの?

763:login:Penguin
19/09/16 01:54:38.69 rJPiMVYE.net
huawaiのスマホのsystemパーティションでEROFS使われてるのか
androidのsystemは元々リードオンリーでマウントされてたから有用だろうな

764:login:Penguin
19/09/16 21:49:59.06 8Mnz6MjR.net
くだらない質問で恐縮なのだが、
既存の、RW可能なファイルシステムで作成したボリュームをROでマウントするのはわかる。
しかしリードオンリーのファイルシステムとなると、
マウントするボリュームは、一体どのような手段で作成されるのだろうか?
卵が先か、鶏が先か…

765:login:Penguin
19/09/16 22:16:57.15 Fjxy1taP.net
>>750
.iso (ISO9660 ファイルシステム、DVD-ROM 等に使われるリードオンリーのファイルシステム)
ファイル作ったことないですかそうですか

766:login:Penguin
19/09/16 22:20:45.35 M+XuPW8F.net
>>750
別のファイルシステムから変換するのでは?
少なくともISO9660はそういう感じだよね。
原理的に、仕様がわかっていて、どう�


767:「う風にファイルを用意したいか決まっていれば、 ビット列は生成可能なのだから、鶏が先か、卵が先かという問題ではないような気がするけど。



768:login:Penguin
19/09/16 22:23:33.54 v2xaK5dV.net
erofs-utilsに入っているmkfs.erofsで作るらしい
URLリンク(git.kernel.org)

769:login:Penguin
19/09/17 00:23:24.54 tEkIjiM2.net
>>750
いや、roなファイルシステムも使用時にroでマウントしてるだけで
作成時はイメージファイル上にFSを作ってrwマウントしてファイルコピーするだけ

770:login:Penguin
19/09/17 02:01:04.20 C2z//eYW.net
>>753
圧縮の有無に違いはあるけど、使い方はSquashFSみたいな感じらしい

771:login:Penguin
19/09/17 09:41:47.16 mAQfPWIi.net
>>754
なるほど,まあ当然っちゃ当然そうだよな。

772:login:Penguin
19/09/17 12:22:17.37 8KO1t32N.net
>>754
isofsはwrite()が実装されてないらしいし、rwマウントしてコピーってのはちょっと違うのでは?

773:login:Penguin
19/09/17 21:24:20.70 2Wuln3eF.net
fuseとかでrwマウント出来るようにした物はあるだろうけど、最初からrwでマウント出来たらroファイルシステムじゃないだろw

774:login:Penguin
19/09/17 22:27:12.02 q0qVtnVz.net
ro専用のファイルシステムって、誰が書き込むの?

775:login:Penguin
19/09/17 22:50:56.62 uhDzaob2.net
mkfsが「XXバイト目にマジックナンバー書き込んでYYバイト目にはこのフラグの値書き込んで」みたいにやってる時に一緒にファイルも書き込むだけ

776:login:Penguin
19/09/21 04:11:32.07 H9H9TTsk.net
これでZFSの重複排除が実用的になるだろうか?
まともに使えそうなら革命的だが
URLリンク(www.phoronix.com)

777:login:Penguin
19/09/21 23:27:31.72 bKqCk4Ie.net
重複排除なんてバックグラウンドでやればいいだけじゃないの?

778:login:Penguin
19/09/22 05:53:45.18 CqaW/Zfz.net
今時のバックアップソフトや専用NASはリアルタイムに重複排除出来る

779:login:Penguin
19/09/30 15:09:29.89 /fxpH8Tk.net
>>762
重複するデータが既にストレージ上に存在するのなら後続の書き込みは行われないのが理想

780:login:Penguin
19/10/01 01:58:35.48 xLonTYnk.net
>>764
コピーするときだけで十分だろ
どうせ上書きしたら内容は変わるんだし

781:login:Penguin
19/10/01 02:38:11.33 C0EfQGgt.net
重複データは書き込み時に判定というのは実際どう判定するのか
書き込み前に一度ファイルを舐めて双方のハッシュでも比較するのか、すごい手間だな
そんなものシステムワイドでファイル作成時や最終書き込みの時にハッシュ引いてファイルの属性データの方に持たせておけばいいのに
それでもハッシュの衝突とか無いとも限らないしな…どうやって検出すればいいんだ
…などと考え始めると眠れなくなる

782:login:Penguin
19/10/01 03:54:30.13 O/YTzUB3.net
うん、だからバックアップでやればいいんじゃねーのって思ってる
最終的にはファームウェア側で実装するのもありかもね

783:login:Penguin
19/10/01 04:01:48.13 O/YTzUB3.net
>>766
ファイルレベルでハッシュ比較しても駄目だよ。
少しデータが変わっただけの巨大なファイルで重複排除ができなくなる。
でもまあそういう例って仮想イメージのスナップショットぐらいしか無いんだよねw
んで、仮想イメージは仮想マシン側がスナップショットを差分で保存してくれるから関係ない
ファイルレベルならバックグラウンドでファイル検索して
ファイルサイズが同じ→中身を比較→全部一緒ならハードリンクにする
これだけで十分だろう

784:login:Penguin
19/10/01 04:34:23.91 LD5IBfg0.net
ログファイルとか重複排除すると効果大きいんだけど


785:な 一般家庭の用途だとストレージのほとんどがメディアファイルで埋まるから効果薄いよね



786:login:Penguin
19/10/01 08:13:43.35 O/YTzUB3.net
>>769
なんで同じ内容のログファイルが
大量にできるんだ?
圧縮ならまだしも何の意味もないだろ

787:login:Penguin
19/10/01 08:17:03.18 O/YTzUB3.net
Windowsは95の時代からドライブの圧縮機能があって
昔はお世話になったもんだが、他のファイルシステムには
そういう機能あるのかな?

788:login:Penguin
19/10/01 10:03:19.94 oU66RV/q.net
>>770
そもそもファイル単位という前提が間違ってる

789:login:Penguin
19/10/01 10:26:58.35 mUwF5icW.net
>>772
ブロック単位とか言いたいんだろうが、何単位であっても
ログファイルなんて同じ内容にはまずならんだろうが
1バイト違っていたりアドレスがずれてるだけでも
だけでも違うものと判断されるんだからさ

790:login:Penguin
19/10/01 22:11:05.16 d4igWScA.net
ZFS とか重複排除はかなりメモリ食うらしいね
NTFS は指定日数経過後のファイルに対してだけ実行するとか
バックグラウンドで実行/高負荷時には実行しないとか
使用メモリ制限とか色々オプションがあるみたい
モードも一般/VDI/バックアップと用途向けに用意されてる
中小規模、ホームユースで考えると NTFS の方式はわかりやすくて
かつ優秀だと思う

791:login:Penguin
19/10/01 22:33:23.76 acLZahM8.net
確かNTFSの重複排除は対象ディスク領域1TiBあたり1GiBのメモリを確保することが推奨されていて、
これはZFSでの重複排除使用時の推奨値と変わらないはずですよ。
重複排除での処理単位のブロックサイズが同じ程度なら、
管理情報のオーバーヘッドはそれほど変わらんでしょう。

792:login:Penguin
19/10/01 22:34:34.00 acLZahM8.net
あ、推奨値じゃなくてこれぐらい消費しますよの目安だったかも。

793:login:Penguin
19/10/01 23:59:37.95 d4igWScA.net
>>775
メモリ使いすぎないオプションもあるよって書いたんだが...

794:login:Penguin
19/10/02 10:24:24.64 MFUU2o8w.net
NTFSって複雑奇怪な仕様のくせにムダに安定してるよな

795:login:Penguin
19/10/02 20:38:07.52 gqMjbdgw.net
NTFSの重複除去処理って理想的な実装じゃね?
URLリンク(www.gmo.jp)
> 重複除去機能はWindows Server2012ですでに搭載されていましたが、
> 最新のWindows Server 2019の重複除去では、重複除去率とパフォーマンスが改善されており、
> ファイル単位ではなくバイナリのデータ単位で重複を検出して除去するため、
> 大幅に重複除去率が向上しています。
> 重複除去は一度設定すればボリューム内のすべてのファイルが対象となり、定期的に実行されます。
> 書き込みごとに圧縮される場合、継続的なパフォーマンスの懸念がありますが、
> 重複除去はスケジュール設定が可能なため、慢性的なパフォーマンスへの影響を回避することができます。

796:login:Penguin
19/10/03 00:59:58.79 OEBySPhx.net
NTFSは本当に優秀だ
NT3.1の頃から業務で使っているが、FS起因でのトラブルには一度も遭遇したことがない
さすが天才カトラーが設計しただけある

797:login:Penguin
19/10/03 02:03:54.40 7cVKYu14.net
MSの開発者のスキルは世界一だからね
本当凄いよ

798:login:Penguin
19/10/03 08:52:36.44 tzg7uxom.net
優秀つっても Isilon や NetApp とかの後追いじゃないか?
OneFS, WAFL, NTFS 以外は完全において行かれた感がある。
zfs や btrfs はそれなりに資金力ある企業傘下だったが残念だ。

799:login:Penguin
19/10/03 0


800:8:52:50.20 ID:47VJX03k.net



801:login:Penguin
19/10/03 15:39:46.94 06JgUDhC.net
zfsはSunがあんなことにならなければ…

802:login:Penguin
19/10/05 20:56:50.83 6SloAFsk.net
NTFSの仕様はマジで謎。

803:login:Penguin
19/10/22 03:48:30 sLMeSFJA.net
Ubuntu 19.10でZFSをルートファイルシステム利用やっとかよ

804:login:Penguin
19/10/22 04:05:31 sWREnU7X.net
ルートにzfs使うことある?

805:login:Penguin
19/10/22 16:37:32.09 bJW2ueVJ.net
zfs重くて泣いた

806:login:Penguin
19/10/22 23:17:46.10 4WVgaPY2.net
zfs raid-1

807:login:Penguin
19/10/24 07:14:24.88 e5plJI2y.net
ZFSの優秀さはメモリと引き換えなのでパソコンクラスのメモリ量だとあまり使えない

808:login:Penguin
19/10/24 14:36:52.38 87akmZa+.net
パソコンクラスってよく分からない表現だな
今のサーバーはほとんどPCサーバーになってきてるのに

809:login:Penguin
19/10/24 15:34:41.99 V0q9EpU/.net
パーソナルなやつだろ

810:login:Penguin
19/10/24 19:01:35.46 XtN2MzoY.net
ZFS出た2005年当時のメモリなんてどれだけだったと思ってるんだ

811:login:Penguin
19/10/25 09:09:25.10 Krt8XDYr.net
うちのパソコンはメモリ512GBだけど足りないかな?

812:login:Penguin
19/10/25 09:54:42.46 dtRwUszk.net
OpenZFSはメモリ要件が改善されたらしくはあるけど
キャッシュヒットが環境によって変わるとはいえメモリの必要量が明確に分からないのは正直つらい
L2ARCの追加もメモリ消費するらしいから安易にできないし
でもZILとかスナップショットとか透過圧縮とか使いたい

813:login:Penguin
19/10/25 10:31:10.97 fu1VNf4G.net
NASでZFSのdedup onで使ってるけど2TBでメモリ10Gも使わない
メモリ512GB積んでおけば100TBぐらいまでは対応できそうだから個人だとこれで十分そうだ

814:login:Penguin
19/10/25 13:35:51.25 +KpuEA9M.net
重複排除設定で使用済みブロックが2TBも使ってるなら相当ゴツいシステムだな

815:login:Penguin
19/10/25 23:24:59.22 IP6r7udF.net
重複排除ってサイズが1バイトずれてるだけのやつも
排除してくれるの?

816:login:Penguin
19/10/25 23:52:06.19 dtVaeIT3.net
な訳ねー

817:login:Penguin
19/10/25 23:54:37.46 IP6r7udF.net
あんまり排除できなくないか?
同じファイル見つけたらハードリンクに
置き換えるツールで十分そうw

818:login:Penguin
19/10/25 23:57:34.59 dtVaeIT3.net
そうだよ、専ら仮想鯖みたいな同じユーザランドが無数に作られる様な用途を想定してるんだろう

819:login:Penguin
19/10/26 01:22:02.81 vQVY0Sjj.net
一日1万枚ぐらいエロ画像を漁ってると20%ぐらいはかつて落としたエロ画像だったりするから
重複排除は容量の20%ぐらい浮く計算になる

820:login:Penguin
19/10/26 01:25:37.95 bm797MDp.net
>>802
そういうのって重複ファイル削除ツール使えばいいだけなんじゃない?
重複させておく必要ないでしょ?

821:login:Penguin
19/10/26 01:29:08.15 Pwsut+Es.net
重複排除はリアルタイムである必要はないわな
ZFSが採用しているようなリアルタイムでの重複排除はメモリを食うし
デスクトップ用途ではデメリットの方が大きい。
XFSの重複排除はパフォーマンスに影響しないし実際に使っているけど便利だよ。

822:login:Penguin
19/10/26 02:04:42.61 /XO9wWRE.net
後で重複を排除するとなると重複かどうかがわからないから結局一度書き込みに行く事になる
zfsはデスクトップ用途だとアレだけどサーバ用途だと理に適ってはいる
あと画像だと今や同じ画像が違うファイル形式であちこちに散乱してたり
同じJPEGでも品質が違ってたりするからあんまし意味ないんじゃ?

823:login:Penguin
19/10/26 02:47:15.22 bm797MDp.net
でも書き込むたびに、これ重複してるかな?って
確認してたら、書き込みが遅くなるじゃん

824:login:Penguin
19/10/26 06:32:43.54 /XO9wWRE.net
それを高速化する為にメモリ内にハッシュの類を持ってるんだろうに

825:login:Penguin
19/10/26 10:45:29.30 ZfJ5IMnc.net
でも書き込むごとに、データのハッシュ値を計算してるんですよね?

826:login:Penguin
19/10/26 11:39:20.84 +7ZIaVI7.net
>>807
非同期書き込みなら書き込み遅いのは気にならないが同期書き込みについては
遅くなるのは致命的だよな
同期・非同期で重複排除をバックグラウンドでやるかリアルタイムでやるか決め
られるだろうけど仮想環境用途の仮想ディスクとかはその上の同期・非同期って
NAS側まで伝わるのかね
>>808
ZFSの場合はハッシュの計算以外にもRAIDの計算もしているが、それをいうなら
商用NASハードはそれで百本越えのHDDとか面倒みながら処理してるわけで
ハッシュ計算はそんなに負担ではないのでは?

827:login:Penguin
19/10/26 11:54:16.15 kG6Y+7fi.net
いやめちゃくちゃ負担だけど
やらなきゃ駄目だから

828:login:Penguin
19/10/27 15:53:27.45 eiS+LtlM.net
>>800
重複排除はファイル単位ではなくブロック単位
もしファイル単位ならそりゃハードリンクと同じだ

829:login:Penguin
19/10/27 17:06:24.41 707D9EX6.net
異なるファイルでブロックが同じってまずないだろ?

830:login:Penguin
19/10/27 23:20:14.99 3lwG/9wl.net
それをファイルレヴェルでやってたらでかいファイルの一部が変更されただけで
ハッシュの類を再度算出しなおさなきゃいけなくなる

831:login:Penguin
19/10/28 00:15:16.75 IKPi8ihE.net
>>812
世代でバックアップとってるファイルとかゲストOSのイメージとか

832:login:Penguin
19/10/28 20:47:04.72 dxvlefLW.net
ファイル単位の重複排除もあるらしい。
更新されなくなったファイルを圧縮するついでにやる?だったかな。
他にもウイルススキャンとかも定期的に走らせるとかあるからハッシュの
再計算を何かのついでにすることで負担は減らせそうだね。

833:login:Penguin
19/10/28 22:31:04.60 9iH4PItu.net
>>814
そういうのって仮想マシンソフト側が対応してますよね?

834:login:Penguin
19/10/28 23:10:44.32 WlwazsDj.net
ファイル単位でやるにしてもどうしても大きさに制限ができる
COWの事を考えるとどうせブロック単位に回帰する

835:login:Penguin
19/10/29 00:52:41.78 fdP/pgCQ.net
>>816
横から失礼
同じ仮想マシンイメージのPCを移動ユーザープロファイルで利用する
ならわかるが、サーバだと初期イメージから離れていくだけだから
差分に対しては仮想マシンソフト側での吸収は難しいと思うが
>>817
データベースの表領域を考えるとそうだけど、それ故最近アクセスしていない
ファイルに限定してるんじゃないかな
そうなると話は変わって逆に大きさがわかる/ファイルサイズがわかるのは
寧ろメリットになってしまう
ブロック単位に回帰する理由を挙げるならスナップショットやシンプロ
ビジョニング、ブロック単位のレプリケーションなど併用すると効率的な
機能要件挙げるべきかな

836:login:Penguin
19/10/29 03:00:41.08 L6q0zJPq.net
自宅のCDデータ倉庫で排除率のシミュレーション'(zdb -S)したけど1%も無くてがっかりだった
やっぱZFSの重複排除は仮想化とセットなんかな
バックアップは取得時だけソフトで差分の処理するほうが安くできそうだし

837:login:Penguin
19/10/29 08:54:54.57 tiBJfX00.net
>>819
zfsは仰る通りだと思う。
コピーオンライトのお陰でスナップショットが高速・少容量な感じに仕上がってる。

838:login:Penguin
19/11/16 21:42:02.73 JSAAagCz.net
重複排除に夢を見ないほうがいいよ
元から圧縮をはじめとする各方面で無駄を無くす努力がなされている現状で
小手先の策は効果がない

839:login:Penguin
19/11/20 20:25:14.01 6yGwAp7b.net
そうか?今日保存したエロ画像は以前見てHDDのどこかに保存したような気がするんだが

840:login:Penguin
19/11/20 20:40:58.51 oxDwVSd5.net
同じ画像に見えてもバイナリ的に同一じゃない要素があってなぁ
というかそういう画像を探すための同一画像判定をしてくれるアプリがあったな

841:login:Penguin
19/11/21 05:47:34.09 FXPGTnmV.net
画像はまだいいけど同一の動画を判定するのは難しそうだなあ
できるソフトあるのだろうか?

842:login:Penguin
19/11/21 09:09:11.59 xIJF9Sc2.net
Googleなら持ってるだろうが

843:login:Penguin
19/11/21 09:58:12.19 qhCu6Ui0.net
おれは一期一会派だから

844:login:Penguin
19/11/21 20:44:46.78 FOikuE8m.net
>>826
年々規制が厳しくなるからいつか後悔するぞ

845:login:Penguin
19/11/23 07:34:28.58 RKp6gT6E.net
すでに御禁制の品です

846:login:Penguin
19/11/26 09:21:12.69 WiM8NUkS.net
>> 826
俺は市毛良枝派だった。

847:login:Penguin
19/11/26 19:19:34.18 dryjMwbD.net
仮想マシンのイメージのように重複排除が効果的なものはあるけど
そういうのは個別に専用の仕組みで対応したほうが早い
例えば掲示板の画像なら重複を探してハードリンクを貼るスクリプトを定期的に回すだけで事足りる
一応btrfsは重複ブロックを探して共有するプログラムが用意されている
さまざまなリスクと制約を負ってでもリアルタイムにファイルシステムでやる必要性が少ない

848:login:Penguin
19/11/26 22:41:02.69 KV/Dsi98.net
>>830
いやそれだったら画像を保存するだけのプール作ってそこだけdupすればいいだけ

849:login:Penguin
19/11/27 01:03:11.01 j6YMclKw.net
URLリンク(www.phoronix.com)
> Linux 5.4 Kernel Released With exFAT Support, Faster Radeon Graphics, New Hardware
exFATキタ━━(゚∀゚)━━!!

850:login:Penguin
19/11/27 01:10:07.14 vV9+H2A1.net
これでexFATが汎用性最強になったね

851:login:Penguin
19/11/27 01:36:26.23 twkxM08i.net
でもジャーナリングファイルシステムじゃないからなぁ

852:login:Penguin
19/11/27 01:39:22.97 BHucuGJr.net
全く用途が違うだろ・・・
何を見当違いな

853:login:Penguin
19/11/27 03:08:57.62 zVRigbnf.net
そう言えばRaiserさんはFS開発に戻らないんだろうか

854:login:Penguin
19/11/27 07:27:41 yuP2HKak.net
そもそもSDXCカードの標準に採用されてるのに読み書きできない方がおかしい

855:login:Penguin
19/11/27 10:28:42.57 aEg54iqa.net
fatは先頭からデータ埋めてくだけだったけどexfatはそのへんどうなの?

856:login:Penguin
19/11/29 08:14:02.98 Vz7mdWod.net
スパースファイルのことなら対応してない
アロケーションのことなら実装次第でFATと変わらんだろう
メタデータの一部がファイル化してるが位置がころころ変わるものじゃないから断片化には影響しない

857:login:Penguin
19/12/03 19:17:30.18 fFA/yNYa.net
Valid Data Length、Linuxで言う所のUnwritten Extentsなら有る
URLリンク(docs.microsoft.com)

858:login:Penguin
202


859:0/01/01(水) 11:10:00.15 ID:scCDRay6.net



860:login:Penguin
20/01/01 12:31:59.53 20dym0cL.net
まじかwww まさか復帰するとは思わなかった

861:login:Penguin
20/01/01 21:13:48.67 p37tb7FW.net
キラーFSになるな

862:login:Penguin
20/01/11 02:19:39.98 UAAx1hWz.net
2020年1月10日 Don't use ZFS ―Linus,ZFSをマージしない姿勢をあらためて強調 階戸アキラ
URLリンク(gihyo.jp)
「Don't use ZFS. ―ZFSは使わない。その理由はシンプルだ。ZFSはこれまでずっと,バズワード以上の
何物でもなく,そして実感するのだけど,例のライセンシング問題は僕にとってZFSを価値のない存在と
思わせるだけだ」
1月6日,IT業界に特化したオンラインメディア「Real World Tech」のフォーラムで繰り広げられたある
スレッドにて,Linus TorvaldsはZFSをメインラインにマージする予定がないことをあらためて明確に主張
している。(中略)
今後のZFSの扱いについては「Oracleの正式なリーガル担当者が署名したオフィシャルレターが届くか,
もしくはラリー・エリソン自身が“⁠ああ,いいよ,手続きを進めよう⁠”といってZFSをGPLにするか,そういう
事態でも起こらないかぎり,僕はZFSに関するいかなる成果もマージしない」と強調,つづけて「ZFSの
コードやインタフェースを取り入れたければ,個々の環境(ディストリビューションなど)で好きにやるのは
かまわないが,訴訟好きなOracleの体質,さらにはライセンスに関する数々の疑念を考慮するなら,僕は
とても安心してそれをやる気にはなれない」とZFSをメインラインに取り入れない理由を説明している。
また,ZFSを直接カーネルに統合しないだけでなく,Shimレイヤのような透過的なインタフェースを通した
実装にも「まったく興味がない。我々にとってなんの価値もなく,Oracleに(Javaのような)コピーライト
訴訟のよいきっかけを与えるだけ」と一刀両断している。
旧Sun Microsystems由来のファイルシステム技術であるZFSに関しては,何度となくLinuxカーネルでの
実装が議論された過去があり,たとえばUbuntuでは2016年ごろからZFSをサポート,最新版の「Ubuntu
19.10」ではZFSをrootファイルシステムにしたインストールが可能となっている。Linusはこうしたディストリ
ビュータの動きに関しては「やらないほうがいいと思うけど,自分たちの責任でやるなら好きにやれば」という
スタイルを通してきたが,今回あらためてZFSのメインライン統合に対し,明確なNoを突きつけたといえる。

863:login:Penguin
20/01/11 04:42:55.15 jnlXzU71.net
マージ無いのはまあ当然だろう
ZFSの為だけに


864:全てのコードをリスクに晒すわけにはいかない



865:login:Penguin
20/01/11 13:42:21.31 6TxpLfrk.net
枯れたjfsで運用しとる奴居らんの?

866:login:Penguin
20/01/11 13:44:36.61 6TxpLfrk.net
LinuxはSiliconGraphics謹製のxfsと添い遂げろ

867:login:Penguin
20/01/11 14:05:29.73 +MC8qtlu.net
jfs いいぞ。
と、言いたいけどAIX由来じゃなくてOS/2からだし

868:login:Penguin
20/01/11 16:12:02.81 ICeSTzlT.net
OS/2ってHPFSじゃないの?

869:login:Penguin
20/01/11 18:40:44.21 K/LCgiW1.net
>>847
どうせならReiserFSがいいな

870:login:Penguin
20/01/11 18:57:24.78 FZkUfr0E.net
>>849
wikipedia の jfs からだが、
1999年4月、新しい JFS が OS/2 Warp Server for e-business に、2000年10月には OS/2 Warp クライアントに向けてリリースされた。
1999年12月、OS/2 の JFS ソースコードがオープンソースコミュニティに提供され、それを受け JFS の Linux への移植が始まった。2001年6月、JFS for Linux の最初の安定版がリリースされた。

871:login:Penguin
20/01/11 19:17:27.72 ptgZv5Qn.net
JFSはビデオレコーダーとかのHDDのフォーマットに使われている場合が結構ある/あったか
今はXFSとかか?

872:login:Penguin
20/01/13 11:25:23.35 mGzs+Xmt.net
>>852
むしろレコーダーにはXFSが使われてるイメージ

873:login:Penguin
20/01/14 04:51:06.14 iZnsu89D.net
うちにちょっと古めのRegza(TV)が2台があるが、録画HDDが認識されなくなって
xfs_repairで3回くらい復活させたことがあるわ

874:login:Penguin
20/01/14 08:15:51.05 bK6lhlF1.net
ZFS厨死亡のお知らせ
URLリンク(www.phoronix.com)

875:login:Penguin
20/01/14 08:55:56.23 U+JHY6EW.net
典型的な老害

876:login:Penguin
20/01/14 09:01:27.05 /3xc9qkj.net
じゃあbtrfs使いますかって話よ
俺はトラウマあるから無理

877:login:Penguin
20/01/14 09:36:14.17 Tzu77Qmb.net
>>855
今までと変えるつもりはないからこれ以上話を出すな、ってだけだと思うんだけど
RedHatがxfsベースで似た機能を持ったもの作るのと、ReiserFSがそこまで取り込んでくれるのを期待

878:login:Penguin
20/01/14 10:05:18.06 3ySwGeCo.net
>>856
法的な問題が解決されない関わらないっていうのを改めて明確にしただけだと思うけど

879:login:Penguin
20/01/14 11:40:03.53 kTd0knbb.net
ZFSなんかバズワードだって一刀両断は胸がすくね
Macが採用を謳ってからの持ち上げようったらおかしかった

880:login:Penguin
20/01/14 12:03:54.46 Co6d2U6R.net
linuxではバズワードかもしれないけれど、
FreeBSDなんかは、UFSの代替として一般化してると思うよ。

881:login:Penguin
20/01/14 14:46:05.21 s3yt3V1I.net
ソースも見ないアホが語っとるわ
リーナスが言ってるZFSはOracleのZFSのことであってOpenZFSではないぞ

882:login:Penguin
20/01/14 17:03:51.82 QOKr6lO9.net
xfsが進化しまくってるから問題ない
俺も早速1年くらいxfsのcowで使っているけど
btrfsとは違ってド安定で一切不具合はないよ
ただしメモリの使用量はなんか多い気がする

883:login:Penguin
20/01/14 17:24:05.89 vHb4j94C.net
>>863
xfsは昔からメモリ大好きっ子やけんな

884:login:Penguin
20/01/14 17:26:23.56 t+wcCOjj.net
スナップショットと圧縮が欲しいんだよー

885:login:Penguin
20/01/14 17:29:22.78 J8UtrzpS.net
>>862
ライセンスがGPLにならないかぎりは同じこと

886:login:Penguin
20/01/14 17:38:02.82 3ySwGeCo.net
>>862
誰にアホといってるのか分からんけど
OpenZFSだろうがライセンスが変わらない限り一緒だといってるだろ

887:login:Penguin
20/01/21 20:00:20.75 ugNUCPRp.net
たとえGPLになって取り込まれたとしてもZFSに使いどころがないわ
ガリガリ読み書きする部分にはメタデータアクセス遅すぎて使えん
ガチ性能と可用性が必要なところはハードウェアRAID組む
ニアライン用なら機能いらんからもっと安定してるやつ使う

888:915
20/01/21 22:45:23 iC7ldWE7.net
LinuxはZFS並みのファイルシステムができるまでまだまだかかりそうね

889:login:Penguin
20/01/22 00:52:27.43 RmlHZiYt.net
超サーバ用途には使わんし、かと言って一般的なPCじゃ必要メモリが大き過ぎて使えんし、
運用のハードルが高い割には使いどころが難しいのよね

890:915
20/01/22 00:59:56.25 97fPzXLY.net
使ったことないんじゃない?メモリ2GBでも快適だよ
今時のマシンなら16-32G積んでるしちゃんと使ってみてから評価すればいい

891:login:Penguin
20/01/22 01:20:43 sJWFkN+Y.net
2GBで快適に動くような使い方してるならZFSでなくてもいいのではって思うけどな

892:login:Penguin
20/01/22 01:58:33 wZeNZHAR.net
メタデータ触ると遅いしメモリ食いなのは確かだけどlvmでスナップショットはかなり無理矢理感あるし透過圧縮ないファイルシステムも多い

893:login:Penguin
20/01/22 07:16:30 97fPzXLY.net
snapshot、promote、細かいACL、send|reciveに透過圧縮など非RAIDでも恩恵はでかいよな

894:login:Penguin
20/01/22 11:38:59 sjf0Rz/o.net
>>874
だね
俺はデスクトップユーザーだからそれら機能の簡易版でもあればbtrでもxfsでも構わないのだが
現時点では選択肢がzfsしかない

895:login:Penguin
20/01/22 16:00:37 vGgGBPjr.net
うんうんZFSは素晴らしいみたいだからFreeBSDでつかっててね

896:login:Penguin
20/01/23 01:55:54.94 7qSP8O0Q.net
FreeBSDもOpenZFSになるのでLinuxで使いますね

897:login:Penguin
20/01/23 14:10:17.07 ZAgXInmL.net
有料でも良ければGPFSが最強なんだけどねえ

898:login:Penguin
20/01/23 14:14:08.14 ZAgXInmL.net
今時は1デバイスで100TB、トータル1PBぐらいのシステムを持っている個人も普通にあるよね
そういうとこで実運用に耐えるファイルシステム、って観点だとこれが以外と難しい

899:login:Penguin
20/01/23 23:53:42.57 6UDxr1tc.net
NTFS

900:login:Penguin
20/01/24 18:35:07 mXgeSarq.net
巨大パーティションは下手すればエラーチェックもままならなくなるから
動画用でもない限り1T程度で切ることにしている

901:login:Penguin
20/01/25 04:40:01 hgworRLd.net
重複排除の実装によくハッシュが使われるがハッシュの計算と保存のコストが馬鹿にならない
例えばKSMは最初ハッシュで実装してたのに結局ツリーを作った上で直接比較する方法に変更した

902:login:Penguin
20/01/25 06:07:36 v2Q4em8k.net
NTFSって理論上は64ビットの番地だけど
現在の実装は32ビットなんだろ

(2^32-1)*2048KiBの8PiBくらいしか管理できない

903:login:Penguin
20/01/25 06:30:47 RUYaEyw5.net
そんな容量が要求される様な用途だとReFSが使われるんじゃ?

904:login:Penguin
20/01/25 07:53:48 TTbJFqbp.net
ファイルシステム上には64ビットで書かれてるよ、
読み書きするときに上位の32ビットを0に固定してるだけ。
たしか、4KBクラスタまでの時代で論理限界16EBとか言ってた。
今は2MBだから増えてる?

905:login:Penguin
20/01/25 10:14:39 9dDjJPoq.net
個人だとだいたい100TBもあれば足りるからな

906:login:Penguin
20/01/25 13:29:15 FQlZOJvl.net
まあストレージやメモリのこれだけあれば十分なんて数字は数年で倍になるし10年で2桁変わる

907:login:Penguin
20/01/25 15:54:16.50


908:Pn3gpz30.net



909:login:Penguin
20/01/25 16:15:25.18 XUbXy/+j.net
10年前でメモリ80MBとかPentium IIを10年使っていらしたんですか?

910:login:Penguin
20/01/25 17:43:01 FQlZOJvl.net
10年前だとメイン機のRAMは8GB、サブ機で2GBだったかな
今はメインで64GBサブ機8GBだから、まあ10倍にはなっていないか
ストレージは1TB→20TB

さらに10年前、2000年時点だとRAM256MBストレージ4GB
1990年頃だとRAM4MBストレージ80MBくらいか

10年で10倍、25年で1000倍目安くらいだな

911:login:Penguin
20/01/25 20:54:00 9YpFJvCS.net
>>888
そこまでいくと実質的に青天井だからS3などのクラウドを選択するだろう
もう自前でストレージを持つ時代じゃない

912:login:Penguin
20/01/26 10:26:40 AHO9IC4m.net
>>888
資源系を筆頭にいくつかの業界や世界規模の大手企業ではPBなんて珍しくないよ
そういうところでは単一ネームスペースでアクセスできるところに意味があるからそうなる

>>891
むしろ逆、そこまで大きくなるとクラウドストレージはI/Oが高すぎて話にならなくなる

913:login:Penguin
20/01/26 11:00:01 OzJ+Z2xw.net
>>892
事業の性質によるだろう
多くのBtoCビジネスでは、必要なストレージ容量やIOはユーザー数に比例するから問題ない
それで赤字ならそもそも商売として成立しない

914:login:Penguin
20/01/26 11:21:19 kSy9PDTE.net
>>892
PBクラスのシステムのファイルシステムは実際は Lustre や GPFS
などの分散ファイルシステムで、その中身は ext4 などのファイル
システムを並列に並べたものだから、単一のファイルシステムとしては
PB 超えれてない

ここでの議論は単一のファイルシステムに限定したほうがいいと
思うんだがどうだろう

915:login:Penguin
20/01/26 11:44:24 kSy9PDTE.net
>>893
> 事業の性質によるだろう

具体的にはスパコン(HPC)と映像系だけかな

CIFS/NFS(autofs)/オブジェクトストレージあたりは複数のストレージを
束ねて1つのネームスペースに見せかけられるからそこそこ安定してて
こなれた価格のストレージを並べるから PB のファイルシステムは不要

テキトーなこと言うけど、PB クラスのファイルシステムが必要になる
のは1ファイルがTB超えるとか1バッチあたりの中間ファイルがTB超える
とかぐらいからじゃないかな

916:login:Penguin
20/01/26 11:53:39 AHO9IC4m.net
>>894
LustreもGPFSもPanFSも中身は独自でext4等の下層fsを持たないよ、何か別のものと勘違いしてない?

917:login:Penguin
20/01/26 12:22:35 AHO9IC4m.net
>>895
HPCはそうだけど映像系は実は必ずしも該当しない、ガチなとこは階層化ファイルシステム使うから
日本では技術力がないのか金があるのか知らないけど単一でゴリ押す映像系の話きくけどね

PB越え単一ファイルシステムが必要なのは、一ファイルの大きさが問題じゃなくて
アクセスする可能性があるファイルが大量にあって、かつテープでは遅すぎる場合
だから金融系・資源系・生命系みたいにデータが大量で時間が金に直結するところで良く使われる

918:login:Penguin
20/01/26 12:26:01 AHO9IC4m.net
>>896
おっとすまない、Lustreは下層がext4だった、ごめん勘違いしてたのは俺だった
でもGPFSやPanFSが下層を持たないのは本当
まあ現状エンタープライズのファイルシステムの最前線はGPFS vs PanFSみたいな雰囲気はある

919:login:Penguin
20/01/26 13:52:42.43 kSy9PDTE.net
>>897
それは失礼。 ちなみに Lustre は ext4 と他に ZFS の実装もあるそうな。
> アクセスする可能性があるファイルが大量にあって、かつテープでは遅すぎる場合
使ってる業種と使い方に異論はないんだけど単一ファイルシステムを使う理由が


920: それかというとちょっとなんか釈然としないなぁ 結局入力ファイルや中間ファイルを複数のファイルサーバに負荷分散するように組むのが 面倒くさいから使ってるってだけって印象だわ 面倒くさがらなった結果の一つが Hadoop/HDFS だと思ってます、ハイ



921:login:Penguin
20/01/26 14:09:39.49 aLHVJ+JL.net
1ファイル1'PBのエロ動画とかどうやって保存してるんだろう

922:login:Penguin
20/01/27 01:02:02 SjNVe4Yy.net
>>900
Display Portが2.7Gb/s最大なんで少なく見積もっても823時間分あるんだが
どういう人向けなのか説明Plz

923:login:Penguin
20/01/27 12:29:14 0w7PQcpt.net
>>901
DPは最大25Gbps出るしDSC使えばもっといける
そもそもファイルサイズとモニターへの転送速度は関係ないでしょ?
実際に販売する段階になったらエンコードして小さくするとしても編集前のマスターデータをそのまま保存しておく場合なら再生するモニター以上の解像度、フレームレート、色域が記録されていても保存に必要な容量が用意できれば全く問題ない

924:login:Penguin
20/01/27 14:05:19 vU+1ytkI.net
>>886
得ろ動画溜め込むのに少ない

925:login:Penguin
20/01/27 18:07:52 udH3RDqL.net
8K24bitの24時間ハメ撮りAVだと無圧縮で計算上約8TBだな

926:login:Penguin
20/02/02 12:09:33 Hg2ze+cG.net
>>836,841,843
この流れ好き

927:login:Penguin
20/02/02 15:16:02 GHB58PtI.net
Linuxのファイルシステム「Btrfs」を5年間使用した記録
URLリンク(gigazine.net)

928:login:Penguin
20/02/02 15:26:44.86 U7jFn1mT.net
RAIDはmd使った方が無難に思える

929:login:Penguin
20/02/02 17:40:25 HE+GXCHP.net
RAID10はmd raidよりbtrfsのほうが安定してる
RAID 1ならmdのほうがいいけど

930:login:Penguin
20/02/02 23:14:15.47 cDfryaOr.net
>>907,908
md の上に何乗せてるん? ext4? xfs?

931:login:Penguin
20/02/02 23:40:34.80 iaNiREzj.net
スーパー32Xに決まっておる

932:login:Penguin
20/02/03 05:01:47.23 9XLDxuL9.net
>>909
RAID1なら何でも乗っける
ESPの多重化もしたいし
それ以外ならファイルシステムのネイティブ機能の方がいいと思う

933:login:Penguin
20/02/03 11:50:13 1h1DB/oS.net
>>910
その発想はなかった。俺は評価する。

934:login:Penguin
20/02/03 23:45:36 OVT3+6Po.net
セガファンは面白いやつ多いのにセガはあれだな

935:login:Penguin
20/02/11 01:11:17 gTMJQSdw.net
2020年2月10日 Linus,次期カーネル「Linux 5.6」の最初のリリース候補版を公開
URLリンク(gihyo.jp)

ここで触れられているZonefsは開発したWDによるとSMR HDDやSSDに適したファイルシステムらしい

What is Zoned Storage and the Zoned Storage Initiative?
URLリンク(blog.westerndigital.com)

936:login:Penguin
20/02/11 10:00:56.86 JmaZPai6.net
ZonefsはPOSIXに準拠していないので既存のファイルシステムを置き換えるものじゃないけどな

937:login:Penguin
20/02/11 22:35:10 F8Fgy0xz.net
f2fsじゃあかんのかね

938:login:Penguin
20/02/15 20:40:39 ko2/1+4j.net
F2FSは最大FSサイズが16TBなのがSMR HDDには今後ネックになる

939:login:Penguin
20/02/15 20:51:22 fQlV7izm.net
FlashFriendly File Systemだからな
HDDとか知らんよ

940:login:Penguin
20/02/15 21:41:41 7ROaKxuF.net
HDDも大容量キャッシュ付き瓦だとあんまりfs側でいじらない方がいいような気がする

941:login:Penguin
20/02/15 23:17:25 Aj0iDWta.net
WinFS でやりたかったDB の機能も付いたファイルシステムってあります?

942:login:Penguin
20/02/16 09:36:26.82 tFc9/bu5.net
>>920
じゃあそれDBでよくね?ってなってどこも開発やめた

943:login:Penguin
20/02/16 11:11:50 Cl0cNLYW.net
最近はDBのためにダイレクトIOのパフォーマンス上げる改善が多い

944:login:Penguin
20/02/19 08:46:06 +vuP13XZ.net
Googleが新しいファイルシステム作ってる
Android用だからLinuxのメインラインに取り込まれるのか分からんけど
ダウンロード中の不完全なファイルでも実行できるらしい
URLリンク(lore.kernel.org)

945:login:Penguin
20/03/20 16:46:34 oDz6Qr3S.net
btrfsはUUIDの変更が鬼門だな
メタデータとUUIDが紐付いているらしくてデータを読めなくなる

946:login:Penguin
20/03/29 17:30:13 ZSfzV/DF.net
btrfs使わなええ

947:login:Penguin
20/03/29 19:29:33.05 A9QWVCnu.net
カーネル5.4で追加されたネイティブexFATは日付の処理にバグ有り
Windows7とfuse-exFATで作成したファイルを5.4のネイティブexFATドライバで見ると、
更新日付がちょうど 1ヶ月+9時間 遅く表示される
アクセス日付は常に 1979/12/31 9:00:00 と表示される
5.4のネイティブexFATドライバで作成したファイルをWindows7で見ると、
更新日付とアクセス日付がちょうど 9時間 早く表示される
また、5.4のネイティブexFATドライバでマウントしなおすと上記の症状が起こる
つまり、
・読み書き共にタイムロケールが正しく反映されない (日本設定では9時間ずれる)
・読み込みのみ暦月がずれて読み込まれる (書き込み直後はキャッシュされるので症状が見えない)

948:login:Penguin
20/03/29 19:38:05.23 A9QWVCnu.net
あと、5.4のネイティブexFATは日本語処理は問題なかった
日付のずれは地味に困るから一旦fuse-exFATに戻す

949:926
20/03/29 20:21:00.98 A9QWVCnu.net
アクセス日付を更新するだけでも更新日付が一ヶ月後ろにずれることも分かった
サムネイル表示機能を有効にしてたから試しに開いたSDカードの日付情報も派手にやられた

950:login:Penguin
20/04/08 08:54:17.25 ctV6ZAP7.net
Windows10
5000個以上のPDFをAドライブからBドライブに移動させたら、ファイル数はそのまんまなのに総サイズが250MBも減少した
なんで?

951:login:Penguin
20/04/08 09:48:50 h2p5sSpc.net
圧縮ディスクだった

952:login:Penguin
20/04/08 16:48:38 nNfYJP3N.net
Aドライブってフロッピー?

953:login:Penguin
20/04/08 18:26:58 9nhczXSy.net
A側はexfat でアロケーションユニットサイズが 1MB (平均512KB/ファイル余計に消費)で、
B側はNTFSで同サイズが4KBで(同平均2KB/ファイル)だったって感じか?
(意図的にやらない限り 1MB なんて値にはならないはず)

それ以外の可能性としてはA側には隠しファイルがあってサイズは隠しファイル込みだった

954:login:Penguin
20/04/09 01:04:11 NYHCWS9d.net
exFatをWindowsで初期設定でフォーマットするとクラスタサイズが128KiBになる
1ファイルあたり平均64KiB余計に消費するので、64KiB×5000個=約312MiB
>>929 は順当な結果

955:login:Penguin
20/04/09 01:09:19.65 NYHCWS9d.net
1件1ファイルで保存するタイプのメールデータをexFatに保存すると大変なことになる
(1件ごとにほぼ128KiB無駄になる)
あとNTFSは約700バイト未満のファイルはメタデータに直接格納しちゃうから細かい設定ファイルやらメールデータの収納効率が非常に良い

956:login:Penguin
20/04/09 08:50:59.38 tHpWeU4o.net
Ubuntu 20.04β試していて初めて知ったんだけどlinux-5.3あたり(?)からNILFS2へ書き込もうとするとクラッシュする(といってもNIFS2を扱っているカーネルのサブシステムだけ)というトラップ(バグ)が仕掛けられてたのね。
/homeをNILFS2で運用していて18.04でバックポートカーネルを入れるとログインできなくなるんで何でだろうと思っていた。
当分18.04+5.0系カーネルで保持かなあ?

957:login:Penguin
20/04/09 10:29:58.44 wTSYL5PJ.net
NILFS2って保守されてるのか?
いつか消されるんじゃないかと思っているのだけど

958:login:Penguin
20/04/09 12:30:14.75 7wAsdCRN.net
4TB の外付けHDDを exFAT でアロケーションユニットサイズを NTFS と同じ 4kB で使う場合、
大きなデメリットってある?
それとも、アロケーションユニットサイズを変更するくらいなら、素直に NTFS で使ったほうがいい?
Linux でもネイティブ対応しそうな exFAT を考慮したいけど、
今までの外付けHDDが全部 NTFS なので、
ちょっと躊躇してしまう。

959:login:Penguin
20/04/09 12:47:50.43 f9lVta1Z.net
数十~数百GB程度ならexFATでも何でも構わんけど
テラバイトサイズのボリュームはジャーナリングファイルシステムでないと怖すぎないか

960:937
20/04/09 13:13:20 7wAsdCRN.net
>>938
確かに、ジャーナルのない点は少し気になるねぇ。

サルベージするときの復元率の違いも気になる。
FAT32 のときは、復元できても断片になることもあった。
もっとも、NTFS の場合、復元できなければ断片すら拾えないという感じだから、
優劣という感じじゃないしなぁ。

961:login:Penguin
20/04/09 17:40:41 vpGccY6F.net
>>936
ジャップ製モジュールはこれが怖い

962:login:Penguin
20/04/09 18:04:57.35 9fEj1NQk.net
チョン?

963:login:Penguin
20/04/09 22:32:27 4pQr46JD.net
手伝お?

964:login:Penguin
20/04/10 16:47:03 mZNoA7ar.net
>>937
そのFSを読めるOSが壊れたときなんて想定は別の同じOSを用意すればいいでしかないぞ

965:login:Penguin
20/04/11 22:41:34.77 XDts1cPd.net
>>937
Windows95/98と同じ程度の信頼性はあるはず

966:login:Penguin
20/04/24 00:01:20.91 OEQFvFGC.net
CoWはその性質上、空き領域をどんどん上書きするからSSDの速度低下が起きやすいようだ
定期的にトリムした方が良い、例えば毎朝と毎夕
マウントオプションでdiscardオプションを付けても良いがLinuxでは遅くなることが多い
fstrim -v /

967:login:Penguin
20/05/03 18:58:52 njMyCBBl.net
>>935
NILFS2開発者のMLにとりあえずの回避策が流れてた。
起動からマウントまでの間にそのFSのデバイスへの書き込みがあればいいので、
マウントの前に
dd if=/dev/なんとか of=/dev/なんとか count=1
みたいにダミーの書き込みを発生さればいいのだそう。
例えば、fstabから削除かnoautoにしてrc.localとかでdd, mountという流れとか。

968:login:Penguin
20/05/05 05:14:55 AUhfSTN7.net
>>946
ありがとう。

たぶんこれかな↓

URLリンク(marc.info)

自分の場合も/homeがnilfs2なんでどうしたものかな???というところですわ。
サブ機のほうはbtrfsに替えてUbuntu20.04に上げたけどメイン機の方はどうするかなあ?

969:login:Penguin
20/05/26 11:43:00 1H93WhIH.net
Btrfsとかzfsって一台のhddだけで運用するのはたいしてメリットないの?

970:login:Penguin
20/05/26 12:46:01.35 +ELcO//y.net
あるだろ
圧縮とかスナックショトとか 盛りだくさんだわ
>>948

971:login:Penguin
20/05/26 17:16:39.31 o4/8jJLs.net
デュアルブートしてたらNTFSのMFTがミラー毎壊れたんですけどなんとかMFTを修復できませんかね?
EaseUS Data Recovery Wizardを使うとディレクトリやファイル名がそのままでデータ救出できるんですけど
という事はMFTも修復できるはずですよね?

972:login:Penguin
20/05/26 22:43:28.04 6YtvPgat.net
Btrfsの将来は

973:login:Penguin
20/05/27 08:05:49.48 uLCM26Hl.net
君の頑張り次第

974:login:Penguin
20/05/27 12:56:13.77 XCSTzVNb.net
まだ始まったばかりだ!
Oracke先生の次回作にご期待ください

975:login:Penguin
20/05/27 20:57:11.66 acGll7c1.net
xfsのCoWを有効化したまま1年以上使ったけど時々フリーズするなやっぱり
あとメモリ使用量がちょっと大きすぎるね。
まだまだext4安定の時代は続きそうだ

976:login:Penguin
20/05/27 21:38:26 0U4TUkPK.net
それならBtrfsの方が安定してるな。できたばかりでこれからなんだろうけど


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch