ファイルシステム総合スレその18

**login:Penguin** · 2017/12/28(木) 23:50:51.14

● 前スレ
ファイルシステム総合スレその17
http://mao.5ch.net/test/read.cgi/linux/1421502118/

● 関連スレ
ジャーナリングファイルシステム
http://mevius.5ch.net/test/read.cgi/unix/979408065/

OpenSolaris/Illumos (OpenIndiana, etc.) 6
http://mevius.5ch.net/test/read.cgi/unix/1337411922/

FS関連スレ
http://medaka.5ch.net/test/read.cgi/os/1137387538/
過去スレ, 関連リンクは >>2-10 あたりで.

**login:Penguin** · 2018/12/26(水) 01:18:41.06

､i｀ヽ　　　　　　　　　　　　　　　　　　　 ,r‐'ァ
　｀ヽ：：　　　　　　　　　　　　　　　　　　　：：´
　　ヽヽ　　　　　　 , -‐--､　　　　　　 /　/
　　　ヽ　＼　　　　 I:：：：：：:I_ 　　　　_ /　/　┌────────────
　　　　ヽ　ヽ　　　 i,(;;;ﾉI､;;;)l　　　 ,,／　 , ' 　＜レイザーエスエフゥゥゥ！
　　　　　ヽ　` ｰ､.,,ゝ´ヮ｀,ﾉｭ_, - '　　 r' 　　　└────────────
　　　　　　 ` ､_ ／：:: `山'::::：　　　／
　　　　　　　　ヽ：::::::::::|:::::::："",r‐'
　　　　　　　　　〉::::::::|::::::::::¨/
　　　　　　　　　/;;;;;;;/;;;;;;;;;;/
　　　　　　　　/;;;;;;;/:::::::::::《
　　　　　　　<;;;;;;;《:::::::::::::ヽ　　　））
　　　　　／　ヽI,r''"""^~ヽ
　　　　 /　　　,／　ヽ　　　　ヽ

**login:Penguin** · 2018/12/26(水) 21:54:51.33

ライザーエフエスだよHG

>>920
今は使ってないが
壊れかけのHDDでEXT3よりも頑張ってくれた思い出

**292** · 2018/12/26(水) 21:55:35.75

>>290
ね

**login:Penguin** · 2018/12/26(水) 22:47:15.21

壊れかけのレ　　いざーえすえふぅぅぅ！

**login:Penguin** · 2018/12/26(水) 23:38:01.14

https://inmatelocator.cdcr.ca.gov/Details.aspx?ID=G31008

Hans Reiserは2020年5月に仮釈放の申請ができるようになるらしい（仮釈放が認められるとは限らない）

**login:Penguin** · 2019/01/09(水) 03:02:08.47

ラップトップでスナップショット使おうとするとやっぱりbtrfsしかないんだろうか
LVMも使ってみたけどスナップショット取ると遅すぎて使い物にならなかった
ZoLのほうが良かったりするのかな

**login:Penguin** · 2019/01/09(水) 05:34:15.75

ZFSってファイルサーバーに使うもんだって勝手に認識してるわ
一般的なデスクトップに使うのってどうなのかね

**login:Penguin** · 2019/01/09(水) 06:33:05.71

zfsは遅いから向かない

**login:Penguin** · 2019/01/09(水) 08:36:15.65

軽さと安全性はトレードオフ
速さが必要ならext2でも使ってなさいってこった

**login:Penguin** · 2019/01/09(水) 09:18:43.98

>>299
今はext4の方が速いよ

**login:Penguin** · 2019/01/09(水) 09:24:22.22

もうxfsでいいじゃん

**login:Penguin** · 2019/01/09(水) 11:02:07.20

>>297
ワークステーションならまだしもラップトップじゃ力不足だろうね

**login:Penguin** · 2019/01/09(水) 12:17:22.03

zfs遅い速いって不毛な議論されてるけど、zfsはボリュームの構成で激しくちがうからなんとも言えないだろう
zfsでシングルボリューム、シングルプールだと力なんか必要ないだろう

**login:Penguin** · 2019/01/09(水) 14:00:00.41

いや巣の速度が遅いから

**login:Penguin** · 2019/01/09(水) 15:51:24.98

データ壊れるより遅くても耐障害性があるほうがいい、、
ext/xfs/reiser/jsf色々使ったけど懲りた

**login:Penguin** · 2019/01/09(水) 16:02:24.88

ZFSは使って楽しいけどね。覚えるコマンドも
少ないし。

**login:Penguin** · 2019/01/09(水) 16:42:54.90

>>305
何使ってるの？
btrfsに関しては普段はいいけどいざ問題が起きてメンテナンスしたりするとすげーバギーで常用は辛いって感想
とりあえずlvm+ext4に逃げてる
zfsは使ったことない

**login:Penguin** · 2019/01/09(水) 20:07:50.74

>>307
メインはfreebsd+zfs
linuxならext4,xfs
macはapfs
winはNTFS

使いたいOSが押してるやつだな

**login:Penguin** · 2019/01/09(水) 20:12:46.50

NTFSは堅牢だよな
カトラーが設計したからな

**login:Penguin** · 2019/01/09(水) 21:32:17.43

cephを組む猛者はさすがに居ないか

**login:Penguin** · 2019/01/10(木) 01:10:07.66

使ってるけど自動でデプロイされたから中身よく知らない

**login:Penguin** · 2019/01/10(木) 03:23:15.64

SSDでも気にするほどの差出るの?

**login:Penguin** · 2019/01/10(木) 04:16:12.47

とりあえずbtrfsが遅い
まあxfsやext4はlvm使うことが多いからそうなるとbtrfsとそんなに違わなくなるのかもしれないが
https://www.phoronix.com/scan.php?page=article&;item=linux-50-filesystems&num=1

**login:Penguin** · 2019/01/10(木) 12:33:23.19

zfsは構成がどうのとか関係なくメタデータ操作系が全般的に遅いから
homeやspool的なものとかデスクトップマシンとかでは使いたくない

**login:Penguin** · 2019/01/10(木) 13:16:00.06

鯖には用途に合わせてxfsとZoL
デスクトップにはbtrfs使ってる
btrfsはもう少し速くなってくれたら言うことないんだけどなあ

**login:Penguin** · 2019/01/10(木) 13:38:23.11

zfs勢はbtrfsをpoor man's zfsとか揶揄するけどエンタープライズしか考えていないようなのをノートパソコンで使えたもんじゃないよな

**login:Penguin** · 2019/01/10(木) 15:14:33.70

>>173
zfsは、高価なハードウェアを使わない
より安価なソフトで解決する
プアマンズRAIDだしね。

**login:Penguin** · 2019/01/10(木) 15:43:56.87

>>317
今どきはCPUが性能余してるからソフトウェアRAIDの方が速いと思う

**login:Penguin** · 2019/01/10(木) 16:40:39.19

停電とかの事を考えるとそう単純な話じゃなくなる
バッテリとか大容量キャパシタ積んだコントローラなら突然の停電でも
書き込んだなら書き込んだ、書き込まれてないなら書き込まれてないの
保証がある程度できるけど、
ソフト側で逐次各記憶装置に書き込み命令とか送り込んでると一貫性がなくなる

win10以降の記憶域プールはその辺の対策はしてるみたいだけどめっちゃ遅い
IsPowerProtectedをTrueにすれば早くなるけどその辺の対策がされなくなるしな
所詮ソフトウェアRAIDだからっつーて、
単純にパリティ分散とかミラーリングとかすればいいっちゅーもんでもない

**login:Penguin** · 2019/01/10(木) 16:49:02.93

RAIDZで雷の日でも精神ダメージが入らなくなったのは嬉しかったな
バッテリ付きRAID

**320** · 2019/01/10(木) 16:51:25.84

ごめん途中送信した
バッテリ付きRAID高いから手が出せなかったって言いたかった

**login:Penguin** · 2019/01/10(木) 16:56:22.43

小規模・個人レベルならどっちでも良いよ
データ保証はアプリとファイルシステムが担うべき
DCクラスでハードRAIDはナンセンス

**login:Penguin** · 2019/01/10(木) 21:27:48.95

ファイルシステムが物理層の構造に依存するとか非現実的だろう

**login:Penguin** · 2019/01/10(木) 21:58:54.96

物理というかブロック層はbarrier/fua/flushに従うだけやろ？データとしての一貫性は上位のソフトウェアにしか分からんから>>322は当たり前の事を言ってるぞ

**login:Penguin** · 2019/01/10(木) 22:14:30.50

そういえばWindowsはファイルシステムの下位にフィルターが入るとかでWSLがやたらIO遅いとかネタになってたな

**login:Penguin** · 2019/01/10(木) 23:36:19.35

WSLが遅いのはNTFSの上でfuseみたいなの動かしてるからじゃないか

**login:Penguin** · 2019/01/11(金) 00:02:58.95

>>324
データの保証ってチェックサムレベルだったら勘違いしてるぞ
停電とかで一部のHDDにだけ書き込みが実行されて他に書き込まれなかった時、
単純に分散するだけじゃハードの恒久的な障害かそうじゃないかがわからなくなる
そのフラグなりジャーナリングなりまでをもファイルシステムがやれって事でしょ？

zfsみたいなチェックサムとは訳が違う

**login:Penguin** · 2019/01/11(金) 00:55:44.89

>>327
raid5/6のwrite hole問題の話か
あれはストレージノードの冗長構成とっていて頻繁なディスク同期のできない企業向けシステムが気にする問題やろ？停電や強制電源オフを頻繁にする人なら気にしたほうがいいが

**login:Penguin** · 2019/01/11(金) 00:59:47.13

それに限らずハード起因の不整合は起こり得る

**login:Penguin** · 2019/01/11(金) 01:06:21.03

win10の記憶域プールはファイルシステムより下で
ハード起因なのか停電とかなのかを判別してる

その機能の有効無効のフラグがIsPowerProtected

**login:Penguin** · 2019/01/11(金) 11:39:07.98

ZoLの未来は明るくないな
https://www.phoronix.com/scan.php?page=news_item&;px=ZFS-On-Linux-5.0-Problem

**login:Penguin** · 2019/01/11(金) 23:46:17.04

互換APIないの？

**login:Penguin** · 2019/01/12(土) 16:09:53.17

bcachefsが今年中に使えるようになるんじゃないかね
結構期待してる

**login:Penguin** · 2019/01/12(土) 16:46:59.06

今年使えるようになったばかりのfsなんて怖くて使えない

**login:Penguin** · 2019/01/12(土) 17:43:51.46

>>334
人柱様に水を差すんじゃねえだ。

**login:Penguin** · 2019/01/12(土) 18:12:49.01

Linuxのメインラインに取り込まれるのが今年になるだろうってだけで何年も前から使えるけどな

**login:Penguin** · 2019/01/12(土) 19:22:16.98

Linux上のZFSがLinux 5.0でひっかかる
https://www.phoronix.com/scan.php?page=news_item&;px=ZFS-On-Linux-5.0-Problem

**login:Penguin** · 2019/01/12(土) 20:50:02.41

少し上のレスくらい見ようぜ

**login:Penguin** · 2019/01/12(土) 20:57:27.94

何言ってんだこのバカ

**login:Penguin** · 2019/01/12(土) 23:56:12.11

>>337
>>331

**login:Penguin** · 2019/01/15(火) 13:06:56.35

Ubuntuどうするだろ

**login:Penguin** · 2019/01/23(水) 00:57:56.89

https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuki09/20160703/20160703191828.jpg

一杯あるねー君達

**login:Penguin** · 2019/01/23(水) 02:31:34.66

jfsって使ってる人どれくらい残ってるんだろう

これに新しいReiserfsにRedhatが新しく作ると言われてる奴が加わると思うと、胸が熱くなる

**login:Penguin** · 2019/01/23(水) 18:35:07.23

UX4800で主流だったvxfsってどうなったんだろ

**login:Penguin** · 2019/01/31(木) 19:49:57.57

olacleのzfsアプライアンスのボリュームをwindows10からsmbアクセスしたとき、大文字小文字の違いしかないファイルペアがあると、それらが8文字の長さの別のファイル名に見えるのはどういう機能なのでしょうか。
NFSでCentOSでマウントして、"hello.txt"と"Hello.txt"を作成すると、Windowsでは
HE~B3GZT.TXT
HE~C3GZT.TXT
という2つのファイルに見えます。

**login:Penguin** · 2019/02/01(金) 08:04:15.23

>>345
Windowsはケースセンシティブじゃないから…

**login:Penguin** · 2019/02/05(火) 23:09:56.64

ext4で大文字小文字の区別をしないモードが開発されているらしい

**login:Penguin** · 2019/02/06(水) 20:07:35.87

それはそれでまた阿鼻叫喚の予感が…

**login:Penguin** · 2019/02/08(金) 19:16:10.92

ケースセンシティブでなきゃ死ぬ環境にも問題がありそうな気がする

**login:Penguin** · 2019/02/08(金) 22:49:20.26

昔、別の板でだけど
FAT32の外付けディスクにWin2000で大文字小文字だけの違うファイルを作って
それをWin98で読んだらどうなるかってのの話題があったな

FATの特性(エントリべた書き)もあるだろうけど
dirで表示されるファイルとエディタで開くファイルが違うとか、
移動させようとすると別な方が移動されるけど残った方が読めるようになるとか
いろいろ挙動不審だったらしい

**login:Penguin** · 2019/02/15(金) 13:03:48.45

>>345
FS側じゃなくてsambaのname manglingじゃねえの
Windowsで使えない文字とかもSamba経由だとそうなる

**login:Penguin** · 2019/03/06(水) 12:57:44.81

釈放されたんだから早くreiser4復活しろよ

**login:Penguin** · 2019/03/07(木) 02:54:37.96

ようやく時代がreiser4に追いつくか？

**login:Penguin** · 2019/03/07(木) 09:33:29.95

今はbcachefsのほうが期待されてるだろう

**login:Penguin** · 2019/03/11(月) 00:35:21.09

md-raid 6上の6TBのbtrfsボリュームが怪しくなった
> BTRFS error (device sdb): parent transid verify failed on 222893 34353920 wanted 631557 found 632032
そして消せないサブボリュームがある
# ls -l /mnt/BtrfsTank
ls: /mnt/BtrfsTank/encoding にアクセスできません: 入力/出力エラーです
合計 0
drwxrwsr-x. 1 root video 636 3月 10 13:13 datastorage
d?????????? ? ? ? ? ? encoding

この?の並びが激しく気持ち悪くて不気味だ、このencoding内のデータはどうでもいいってか何も入ってなかった気がする
今の所読めないデータはないし読み書き含め他の部分は問題なく動いて見えるが、btrfs-select-superやbtrfs check --repairやってもダメなので
データ退避してから作り直すしかない
スナップショット撮っては消ししまくりにしてはよく頑張ってくれたと思う

データ退避処理の進捗をみながらRedHatがbtrfs投げ捨ててからの動きとか見てるけど
btrfs on md-raidでいいのかZFS on Linuxに移行すべきかなかなか良いスタンダードが確立してないよねぇ

**login:Penguin** · 2019/03/11(月) 00:40:43.65

btrfsはトラブるたんびにモグラ叩き、の繰り返しだったろうに何故に実運用しようとするのか

**login:Penguin** · 2019/03/11(月) 00:52:12.93

video encodingかw
エンコ厨のアニヲタは氏ねばいいよw

**login:Penguin** · 2019/03/11(月) 03:25:35.52

btrfsは失敗だもう捨てろ

**login:Penguin** · 2019/03/11(月) 03:39:15.17

btrfsのスナップショットは作る分にはいいけど…

**login:Penguin** · 2019/03/11(月) 10:13:10.16

もうNILFS2は誰も見てくれないのかなあ。
結構好きで/homeに使っているのだけれど。。。

**login:Penguin** · 2019/03/11(月) 23:14:39.58

どんなメリットがあって使っているの

**login:Penguin** · 2019/03/12(火) 20:49:05.55

>361
Logファイルシステムなんでファイル操作ごとにチェックポイントができるから保存されている限り任意の時点のファイルシステムの状態が復元できるんで、
あ、消しちゃったとか、間違えて書き換えちゃった時にすぐ取り返せる。
ルートで対象のチェックポイントをスナップショットに変更してマウントする作業する必要があるけど。。。
ファイルシステム止めずにスナップショットが得られるので他の作業しながらコンシステンシー気にせずにバックアップが取れる。
書き込み量とストレージのサイズによるけどデフォで1時間で設定で24時間位は遡れるようにしているので割と気軽にファイル操作している。
とは言っても実際にファイル取り返さないといけないケースは1年に数回程度だけど。

**login:Penguin** · 2019/03/16(土) 17:38:18.22

このディスクのファイルシステム何かわかる人いませんか・・・・・・FreeBSDのUFSではマウントできず・・・・・・。

GPT fdisk (gdisk) version 0.8.10

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdf: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 5D5F6FE4-4185-11E4-AE7C-20C6EB48C57A
Partition table holds up to 128 entries
First usable sector is 88, last usable sector is 3907029134
Partitions will be aligned on 8-sector boundaries
Total free space is 5071 sectors (2.5 MiB)

Number Start (sector) End (sector) Size Code Name
1 88 4194391 2.0 GiB FFFF
2 4194392 3907011775 1.8 TiB FFFF
3 3907011776 3907024063 6.0 MiB FFFF

パーテション１をddで吸い出してfileしてみたら↓

# file backup-disk-image-sdf1.img
backup-disk-image-sdf1.img: Unix Fast File system [v2] (big-endian) last mounted on /tmp/mnt/ustorage3,
last written at Mon Mar 11 10:13:02 2019, clean flag 0, readonly flag 0, number of blocks 524288, number of data blocks 520071, number of cylinder groups 4,
block size 32768, fragment size 4096, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0,
system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization

**363** · 2019/03/16(土) 17:50:40.75

あ、ディスク自体はパナのVIERAに外付けHDDとして接続してたTV録画HDDです。
HDD自体はsmartやら、ddやらの読出し結果からは異常はないっぽくて、
どうも中のファイルシステムがおかしくなってるっぽいなんとか復旧したく。

各パーテション、CodeがFFFFでファイルシステムが何かわかりません。
fileの結果からは、/tmp/mntとなってるので、UNIX系の何かだとは思うんですが・・・・

**login:Penguin** · 2019/03/16(土) 18:42:10.51

レコーダで初期化したHDDは独自のファイルシステムになってるもんじゃないの？
そうでないと録画データの引っこ抜きとかが容易になるわけで。

**login:Penguin** · 2019/03/16(土) 19:11:00.46

> Unix Fast File system [v2] (big-endian)

これが「UFS2」にしか見えなくて、
まずこれをやって
https://www.google.com/search?q=ufs2+%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%80%E3%83%BC
次にこれをやってみて
https://www.google.com/search?q=ufs2+%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%80%E3%83%BC+viera
なんとなく

>>365
そんなことしてたら、コストに見合わない
安定性やバグ取りにサポートまで必要なことに手を出すほど、メーカーはヒマじゃない
せいぜい多少の細工をして外部から読みにくくすることがあるかも程度

**363** · 2019/03/16(土) 21:15:49.38

ありがとうございます。独自ファイルシステムだとコスト的にあわなさそうというのは同意見です。
TV側のOSkernelレベルからカスタムする必要がありそうですし。

吸い出したddをもとに、現状、以下をやってます。

・別HDDへのｄｄでの丸コピでどうにかならないか
　　→　HDD個体識別はGUIDでやってるだろうという推測ベースで激遅コピー中。HDD異常ではなさそうなので望み薄。

・ddとったイメージをいろんなOSでマウントして中身をみてみる
　　→　USF2対応のFreeBSDでマウントしてみたけど、なぜかデバイスファイルのリンクがきれててNG。
　　　　GUIDとか、gpt上のファイルシステム№、ラベルとかを振りなおしてもだめでした。
　　　　ddイメージのfileの結果はUSF2だけど、gptのcode上はUSF2を示すA503ではなく、
　　　　FFFFで、リザーブ№というか、末番なのが果てしなく怪しい。

・マウントせずにファイルを見れるツールを使ってファイルだけ吸い出してみる
　　→　大量の分割ファイル（mp3、mlv？）。あとSQliteとかいうDBMS関連と思われるファイル（dbx、sqlite、txt）
　　　　某社みたいにmpegファイルとして直で保存してなくて、DBMS内に格納していそうな予感。
　　　　DB論理破壊なら絶望的・・・・・。そもそも構造もよくわからんし・・・・。

現状からすると、UNIX系をベースにファイルシステム、保存方法の両方に細工がされてそうに見えます。
DB解析はあきらめて、ちょっとファイルシステムが壊れてるだけです！の方向で継続してま・・・・・
東芝のTVにしとけばよかったなぁ・・・・

**363** · 2019/03/16(土) 22:17:05.43

てきとうにやってたら━(ﾟ∀ﾟ)━DB構造見えてきたー
https://imgur.com/pg50Nq7

このDBはプリセットっぽいけど一応データを見ておこう・・・・・・
？？？？TVよりはるか昔のなにやら不穏な文字列がががが・・・・・・
パナに怒られても嫌なのであれなところは黒塗りで・・・・・・・・
https://imgur.com/ZtSb9BI

ということで全力でDBデータ吸い出し中。

**login:Penguin** · 2019/03/16(土) 22:54:00.06

TV録画HDDまるごとddイメージ用の2TB、
TV録画HDDのパーテションごとddイメージ2用のTB、
パーテションごとddイメージの一応swabイメージ用の2TB、
DB吸い出し用の2TB。空き容量ガー。
今日はもうddでHDDコピーしながらDB吸い出し仕掛けて寝ることにしま・・・・

もし同じような境遇でデータ救えた人がいればアドバイスいただきたく・・・

**login:Penguin** · 2019/03/18(月) 19:49:09.41

デコードできるのそれ？

**login:Penguin** · 2019/03/18(月) 20:09:35.84

録画データ壊れてて読み込んだ時点で死んでるとかじゃなければDB修復したら元のTVで見れるでしょ

**login:Penguin** · 2019/03/18(月) 21:24:29.74

あ、そゆことね

**363** · 2019/03/21(木) 01:42:47.79

はい。結局マウントかけずにフアイルを読み出すツールだと、情報が断片的にしか読めずDB復旧にはいたりませんでした！あと、ddの完コピディスクも予定通りダメなとこまでコピーされてだめ！南無！

**363** · 2019/03/21(木) 01:45:46.80

結局、gpartのFFFFコードの小細工を突破して、正攻法でマウントして読み込んでffckなりするしかなさそうですが、これはうちのスキルではむりんご。

**login:Penguin** · 2019/04/09(火) 13:17:11.49

【速報】削除後、起動しているだけでデータが復元できなくなるという性質がLinuxのファイルシステムに存在することが判明
https://cloud.watch.impress.co.jp/topics/dds1904/

>Windowsでは、1回削除してもファイルシステム上にはフォルダ構成が残っているのですが、
>Linuxに関しては、削除後はしばらくそのままにしているだけでどんどん消えていきます。
>起動しているだけでデータが消えるという性質がLinuxのファイルシステムにはあります。

**login:Penguin** · 2019/04/09(火) 13:22:56.97

ファイルシステム名すら書かずに

**login:Penguin** · 2019/04/09(火) 13:39:29.81

セキュリティ的にはそのほうがいいんじゃない？

**login:Penguin** · 2019/04/09(火) 13:41:03.99

>>375
Linuxでは削除したデータの復活が難しいって話でしょ?
データが勝手に消えるという意味ではないぞ

**login:Penguin** · 2019/04/09(火) 14:45:23.63

ファイルシステムの仕様の話でバグでもなんでもないよな
それにファイルシステム上から完全に削除したファイルの復元なんてWindowsにしろLinuxにしろ保証なんてしてないし

**login:Penguin** · 2019/04/10(水) 11:00:23.00

ext4との比較かな
そんな性質あるのか？ssdの場合か？

**login:Penguin** · 2019/04/10(水) 11:51:08.21

ext4は結構戻せるからxfsのことでないかな

**login:Penguin** · 2019/04/11(木) 07:56:59.03

>>377
一般的には、そうだよね。
記事の内容は、視点がフツーじゃない。

**sage** · 2019/05/02(木) 07:41:59.61

>> 363

LGのTVの録画に使っていたディスクが壊れて調べたらLGのモデルでは次のようなことがあるらしい。

https://www.avforums.com/threads/recording-on-lg-smart-tv-lm760t.1697353/

ひとことでいうと、録画ファイルのメインデータは　JFSの第一パーティション。
メタデータ（リストとかかな？）　はext3の第二パーティションに書き込む。
パーティションタイプはa2という独自のものを利用している（！）

新しいディスクはLG TVにフォーマットさせてたが、
TVが初期化した以前の２TBのWDディスクは
fdisk -l でみるとパーティションのバウンダリがセクターの始まりにないという。
そこでlinux の上で gparted で jfsのパーティションと最後に５０MBほどのext3のパーティションを
つくり、そのあとfdiskの t コマンドでパーティションタイプをa2 に書き換えて、
上のAVForumの投稿にあるように無事つなげた。
（最初まちがってa1を書き込んだらUSB機器に問題があるといって認識せず。
正しくa2にしたら接続したが、「初期化」しますかと聞いてきた。
パーティションから作りかえることはしないだろうとOKして使えるようになった。）

古いディスクは　ddrescueで読みだそうとしているが、3日かかるとか出ていてあきらめ状況。
小さいext3部分は強制的にext3としてマウントできた。jfsの方はだめだった。

消費者としては録画ハードディスクをつなげることができるTVでは
- S.M.A.R.T.の情報を表示して欲しい（ディスクが壊れる場合の８０％くらいはS.M.A.R.T.で予測できるのではないかな。
あとの２０％はいきなりこわれるから、気休めだが。）、
- Windowsマシンなどでバックアップコピーを簡単にできる方法を提供してほしい
とつくづく思った。
（TVの内部キーで暗号化している部分があると思うので、他では再生できないバックアップなんだけども。）

メーカーが独自ファイルシステムなんて作る余裕はないという考えには同意。
LGはパーティションタイプを変えることで　obfuscateしているんだけども上記のAVFORUMの投稿者はどうやって知ったんだろう？

**login:Penguin** · 2019/05/03(金) 02:19:19.70

ファイルのヘッダ見るだけでファイルタイプがわかるように、
その人もパーティションのヘッダを見てファイルシステムがわかるんしゃないかな。
ファイルシステムにシグネチャとかあるのか知らんけど。

**login:Penguin** · 2019/05/03(金) 12:16:35.70

無かったら mount -t auto なんて出来ないぞ

**login:Penguin** · 2019/06/05(水) 11:45:36.91

NixOS Takes Action After 1.2GB/s ZFS Encryption Speed Drops To 200MB/s With Linux 5.0+
https://www.phoronix.com/scan.php?page=news_item&;px=NixOS-Linux-5.0-ZFS-FPU-Drop

ZoLもうダメそうだな

**login:Penguin** · 2019/06/05(水) 14:08:52.34

AES-NIが使えなくなってそこまで遅くなってるんだろう
暗号化をAESからchacha20に切り替えたらかなり改善されると思う

**login:Penguin** · 2019/06/05(水) 16:08:58.99

>>386
あらら(´・ω・｀)

**login:Penguin** · 2019/06/13(木) 01:37:16.29

>>387
ChaChaもChaChaでSSE/AVX使えないのはつらいぞ

**login:Penguin** · 2019/06/16(日) 06:51:50.05

ARXはあまりアーキテクチャ依存しないから速いよ