ファイルシステム総合スレ その16
■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin
2013/03/15(金) 11:51:55.78ID:O3XCXQazhttp://engawa.2ch.net/test/read.cgi/linux/1341012960/l50
●関連スレ
ジャーナリングファイルシステム
http://toro.2ch.net/test/read.cgi/unix/979408065/
OpenSolaris/Illumos (OpenIndiana, etc.) 6
http://toro.2ch.net/test/read.cgi/unix/1337411922/
FS関連スレ
http://kohada.2ch.net/test/read.cgi/os/1137387538/l50
過去スレ、関連リンクは >>2-10 あたりで。
0334login:Penguin
2013/09/28(土) 23:45:55.63ID:p0ZSXVr1例えばfatのUSBメモリをPC起動中に抜いたとしても、
書き込み途中とかでない限りはさし直せばだいたい問題ないかと思います。
zfs(raidzは未使用)の場合にUSBが抜けた場合はやはり面倒なことになるのでしょうか？
それとも複数ディスクで1つのプールを作ってるか否かで変わってきたりするのでしょうか
0335login:Penguin
2013/09/29(日) 00:33:39.81ID:bZpHRofoいまいちよく分からんけど
別にzfsだからといって何か特別なことは起きない
fatと比較した場合ジャーナリングがあるからfatなら壊れる場合でもzfsなら大丈夫という状況はあり得る
0336login:Penguin
2013/09/29(日) 01:23:54.60ID:nx/u7RNa余っているLinux機をファイルサーバにしてWinとMacの両方からHDDを使いたいと思っています。
いままで使っていたHDDをLinux mint 15 KDEで使用する予定ですが、HDDはいざというときのためにWinやMacでも読める
ファイルシステムにしたいと思っています。
この場合ntfsをそのまま使うよりはexFatにフォーマットしなおしたほうが無難ですか。
最近ではntfsもかなり安定しているという話なのでntfsそのままでも特に問題ないでしょうか。
Linuxではntfsの性能が落ちるという話も聞く一方で、exFatはそもそも非常に遅いという話も散見します。
多種のOSから使用する際のファイルシステムでおすすめ教えてください
0337login:Penguin
2013/09/29(日) 02:37:59.36ID:tcJWpgsA外部HDDとして読むのはLiveUSBとかFUSEでどうとでもできるから
そこまで考えることでもないとおもう。
0338login:Penguin
2013/09/29(日) 03:02:53.71ID:3+phKdAFいざという時のためには、tarで固めてvfatでCDRかなんかに焼いとく。
0339login:Penguin
2013/09/29(日) 07:16:10.73ID:GdIUCdB80340login:Penguin
2013/09/29(日) 10:11:55.35ID:+JFBMWZb信者しかいないからだろ
0341login:Penguin
2013/09/29(日) 10:15:05.68ID:nx/u7RNaたしかにLiveUSB使えばLinuxマシンが死んでもWin機にLiveUSB入れれば問題ないし、
Linuxで使う以上はLinux向けファイルシステムを使うべきなのはわかるのですが、
下みたいなことがあるといろいろ面倒かなと。
1, LinuxマシンとWin機が同時に死亡
2, Win(TrueImage)やMac(Timemachine)のバックアップはバックアップソフトが未対応のFS上に配置されてる
3, Win(TrueImage)からもMacからもバックアップにアクセスできず手が出せない
上みたいな場合に、PC修理 -> LiveUSBでLinux起動 -> ntfsのUSBにバックアップコピー -> 復元
みたいな手順を踏むことになる上に、修理完了するまではファイルにアクセスもできないというのはなかなかしんどいため、
多少性能を落としても全OSからアクセスできるファイルシステムのほうが無難かなと思った次第です
0342login:Penguin
2013/09/29(日) 10:48:51.41ID:PR8qOYot0343login:Penguin
2013/09/29(日) 10:57:02.86ID:+JFBMWZb> 1, LinuxマシンとWin機が同時に死亡
こんなケースまで考えるなら、素直に Linux マシンの予備持っときなよ...
raspi とかなら、数千円程度だし。
0344login:Penguin
2013/09/29(日) 11:15:05.94ID:bZpHRofoそんなものはない
いざというときはliveCD使えばいいのでwindowsで読める必要はないと思う
0345login:Penguin
2013/09/29(日) 11:23:16.49ID:Zgc/HmvdsambaサーバーやFTPサーバー入れておけば、そのまま臨時サーバーにもなる。
0346login:Penguin
2013/09/29(日) 13:10:08.87ID:D/UKYMxKそして、活用済みだ。
これは7との大きな違いのひとつだね。
0347login:Penguin
2013/09/29(日) 13:11:19.98ID:6LM62DHq0348login:Penguin
2013/09/29(日) 15:58:02.61ID:AAJG1dPfさすがに三台全部壊れることは稀だろう。
0349login:Penguin
2013/09/29(日) 18:53:41.31ID:KXi+xUbv別マシン（特にWin）に直接繋いだらuidとかパーミッションぐちゃぐちゃになって問題を悪化させるだけだろうな。
iOSとか書いちゃう>>336の知識から推察すると、今まで通りWinにファイル置いて
ファイル共有経由でMacから参照できるようにした方がまだ良いだろう。
0350login:Penguin
2013/09/29(日) 19:55:56.22ID:ptrYCiQbNTFSやexFATのHDDでもWinに繋ぐだけでパーミッションがぐちゃぐちゃになるとは知りませんでした。
みなさんにご指摘いただいた通りLinuxをファイルサーバにする以上
わざわざNTFS、exFATにせずext4あたりを使ってLinuxのみで運用しようと思います。
ありがとうございました。
0351login:Penguin
2013/09/29(日) 22:33:34.34ID:Z67CFY9UZFSのことなら
・Windowsでは使えない
・Mac用は安定版がかなり古く、新しいものはまだ不安定版
・Linux用はライセンスの都合で公式のカーネルに含まれてない
ってのが原因だな
0352login:Penguin
2013/09/30(月) 00:12:53.17ID:xTtbMftW信者がいるってイメージ的にbtrfsとZFSしか浮かばんけど前者は主流になる完成度じゃないし後者はライセンス的に主流にはなれないよね。
0353login:Penguin
2013/09/30(月) 00:44:45.61ID:+Dkxw1iN256〜500GBくらいで余ってるHDD複数台を束ねたいものの、1台死ぬとどのファイルが欠けるかわからないんだよね？
かといってしょぼいHDDを再利用するのが目的なのにraidなんて面倒で組む気しないし、
何より組めるほどHDD容量の組み合わせが揃ってるわけでもない。
0354login:Penguin
2013/09/30(月) 00:48:11.55ID:0wML9P/3あの時小さく悟りを得たと思うｗ
0355login:Penguin
2013/09/30(月) 01:36:43.21ID:iK7cCLds0356login:Penguin
2013/09/30(月) 02:03:32.77ID:mK0VY5+f結局FSはOSの重要な要素なんだよね
0357login:Penguin
2013/09/30(月) 06:12:12.19ID:zTFHeC1x0358login:Penguin
2013/09/30(月) 10:44:36.72ID:DNJ2sqhK> 1台死ぬとどのファイルが欠けるかわからないんだよね？
それを万能に解決する仕組は他の FSでも存在しないでしょ
ZFS なら
* HDDの大きさが揃っている -> mirror/RAID-Z/RAID-Z2/RAID-Z3
* 大きさバラバラ -> copies という属性で FS 内の(mirror的な)冗長度を設定可能
複数のデータコピーは「可能な限り」別々のHDDに放り込まれるので，
HDD外してもある程度はデータが生存できるのかも(使ってないから知らない)
要するにヤワいmirrorみたいな概念だけど，おてがるに設定できる仕組．
0359login:Penguin
2013/09/30(月) 18:12:07.22ID:xTtbMftW大きさが揃ってないときはあれだ、drobo式でパーティション毎にn-1のRAIDZ/mirrorを組めばいいｗ（droboみたく拡張はできないけど）
0360login:Penguin
2013/09/30(月) 20:09:52.76ID:+Dkxw1iNcopiesは初めて知ったからちょっと調べてみる。
圧縮ファイルでいうリカバリレコードみたいなもんかな？
でもまぁゴミドライブ複数たばねてメインドライブのバックアップ先にする程度が無難な気がしてきた。
USBケーブルごてごてさせて複数台繋ぐのも不便と言えば不便だけど。
かといってゴミドライブ接続するためにポートマルチプライヤ買うのも何か間違って気がするしいろいろ難しいな。
0361login:Penguin
2013/09/30(月) 21:55:04.36ID:5HqVbRoJcopiesは、単純にHDDの中に同一ファイルを、複数保存するって事だ。
2copysなら2分の1、3copysなら3分の1の容量になる。
一部のセクタが読み取り不能になっても、正常ファイルを読み込めるって事だな。
HDD自体が死んだら、RAID組んで無い限り、意味ないけど。
0362login:Penguin
2013/09/30(月) 22:34:06.87ID:+Dkxw1iNなるほど俺がいままで各HDDのハッシュ一覧出力してdiffとってたのが、
容量は犠牲になるものの全自動になるのか。それは確かに便利だなぁ。
0363login:Penguin
2013/09/30(月) 22:58:33.15ID:rPqXGk6B300GBあたりを越えると安HDDでも誤り訂正符号で書き込まないと品質を維持できなくなってる
らしく、それぐらいの容量の HDD ではセクタ単位の死亡ってあまり聞かない気がするが、
俺の気のせいかな？
DVD-R とかだと copies 的な機能は欲しいが、壊れやすいのはアクセス頻度の高い？
ディレクトリやスーパーブロックだったりするのが困る。
0364login:Penguin
2013/09/30(月) 23:04:08.11ID:0P9+rhln0365login:Penguin
2013/10/01(火) 05:10:24.57ID:zyGhBIm8実際死んでるかはともかくとしてソフト的にしろハード的にしろなんらかの問題が起こって不整合起こすことはままある。
特にSMARTエラー出てないアレイでzpool scrubかけてチェックサムエラー出たことはあるよ。
0366login:Penguin
2013/10/12(土) 11:25:26.22ID:AYsx1LKJ用途は"各PCのバックアップ"と"各PC間でのファイル共有"で、
それぞれHDDを1台づつ(2台くっつけてzpoolでまとめたりしない)使おうと思っています。
バックアップ用のHDDはスナップショット機能が欲しいのzfsでマウントしようと思っていますが、
ファイル共有用のHDDはスナップショットは特に必要ない(操作ミスでの削除対策や破損対策くらい)ので
EXT4あたりが無難でしょうか。
HDDを増設する際に便利そうなのでzfsにすることも考えたのですが、
容量が圧迫されると不安定になったり、HDDを増設してHDD2台で1プール構成にすると片側HDDだけをはずせないとか、
1つのファイルが複数HDDを跨ぐように配置されるとHDDが壊れたときの損害や破損状況がわかりづらいと聞いて
デメリットは大きいように感じています。
0367login:Penguin
2013/10/12(土) 11:48:11.72ID:9h5alWYm0368login:Penguin
2013/10/12(土) 12:10:36.90ID:/0NAHuooファイル共有用はバックアップしなくていいの？
ext4はぶっ壊れた時に泣けるから、覚悟があるならどうぞ。
どのファイルシステムでも容量カツカツまで使ってはいけない。COWだからより影響が出やすいだけで。
zfsとかraidとかではストレージの取り外しは避けるべき。
ファイルサーバは壊れるまで電源すら落とさずつけっぱなしで放置するようなもの。
ファイルが分散しているのはパフォーマンスの改善と耐障害性のため。
NetAppとかIsilonの高めのNASでもストレージ/ノード両方でファイル分散させて、かつパリティも分散させてる。
どのようにばらまくかが設定できるこんな感じで。
ttp://s2.gazo.cc/up/17007.png
まあ、zfs快適に動かすならそれなりにリソースいるから好みでいいんじゃない。
HDD1つでも圧縮とかメリットあるわけで。
0369login:Penguin
2013/10/12(土) 17:45:04.23ID:dteNadERバックアップ先の方が、元のオリジナルもあるんだから壊れてもリカバーできるんじゃないの。共有用だとそこにしかなかったとかありそうだけど。
0370login:Penguin
2013/10/13(日) 00:06:41.61ID:fA3eVhxXファイル共有用のバックアップはVPNで繋いでる外部のPCにWAN越しで1ヶ月に1回程度の間隔でミラーリングしています。
zfsで懸念してたHDD2台で1プール作るっていう部分も最悪HDDごとにプールわければ何の問題もないし
圧縮やチェックサムなんかの機能も考えたらzfsじゃなくext4を使う理由がさほどない気がしてきました。
0371login:Penguin
2013/10/13(日) 01:25:47.59ID:a3OCf+XjPC1とPC2に単一HDDでzfs環境を構築する。
PC1は常時稼働、PC2は雷などによる被害を回避するため基本的には落としておく。
ある程度ファイルの更新が溜まったらPC1からPC2にsend/recvしてバックアップ。
ミラー、raidをせずにsend/recvでバックアップを行っている場合、
1, PC1がチェックサムエラーを起こした場合にスクラブなどで破損部分のみ復旧可能ですか？
2, もし1が不可能な場合PC2からPC1に破損したファイルを丸々上書きコピーすると、
過去のスナップショット時のファイルは破損したままになり、
消費するHDD容量は破損ブロックのみではなく破損ファイル分の容量を更に消費する認識で問題ないですか？
0372login:Penguin
2013/10/13(日) 19:00:22.65ID:de1d8bC8大前提として、scrub はエラーを修復するコマンドではない。エラーを発見するコマンドだ
発見されたエラーは、可能な限り自動的に修復されるが、それは副作用に過ぎない
copies とか パリティがあれがカバーされるが、ファイルシステムとしての健全性と、単体ディスクのそれは違う
> 過去のスナップショット時のファイルは破損したまま
なんでそう思うのかが謎
0373login:Penguin
2013/10/13(日) 21:08:44.59ID:O+ivi31r371 ではないが...
send/recv ってことは日時、アドレスが特定されるブロック情報がやり取りされるわけだから、
理論上は破損したブロックを recv したプールから修復できそうなもんだが。
それっぽいコマンドが無いからそういう機能はなさそうではあるが。
> なんでそう思うのかが謎
じゃぁ破損したファイルはスナップショットではどう見えるの？アクセスした瞬間に修復不能判定で lost+found 送り？
ま、個人的には scrab でエラーが出るようなディスクを運用し続ける気にはなれないが。
0374login:Penguin
2013/10/13(日) 21:30:12.93ID:de1d8bC8> 理論上は破損したブロックを recv したプールから修復できそうなもんだが。
ファイル一式あるのに、そのブロックだけ持って来ても大抵の場合はあんまり嬉しくないからだろうね
> じゃぁ破損したファイルはスナップショットではどう見えるの？
どう見えるもこう見えるも、コピー先のファイルは、コピー先のディスクもファイルシステムも壊れてなければ
普通に見えるだろう
> アクセスした瞬間に修復不能判定で lost+found 送り？
なんでそう思うのかが謎。コピー先とコピー元の区別がついてないんじゃない？
コピー元の話をすれば、元々そのブロックを含むファイル全体が読めればなんのエラーも出ないだろうし、
スナップショットが取ってあっても、そのブロックが書き換えられてなければファイルとしては壊れてるだろうし、
書き換えられていて、かつ元のブロックにエラーがなければ、スナップショットのファイルには何の問題もないだろう
あと、zfs に lost+found は無いよ
0375login:Penguin
2013/10/13(日) 21:43:16.85ID:a3OCf+Xjraid、mirror、copiesで冗長設定を行っていれば
ファイルのエラーを修復することが可能なのは了解です。
send/recvで全く別のPCに同じzfsプールを作成してバックアップしているような場合に
ファイルをコピーする以外の方法でエラー箇所を修復することは可能でしょうか。
>なんでそう思うのかが謎
ファイルA作成 -> スナップショット取得 -> ファイルAを少し追記してファイルA'にする。
ここでオリジナルのファイルAが破損した場合に
ファイルA'にも影響があるかと思ったのですがdedupしてなければ無事でしょうか。
0376login:Penguin
2013/10/13(日) 22:08:31.96ID:de1d8bC80377login:Penguin
2013/10/14(月) 00:14:45.63ID:b0jVcrh/いみふ
>>375
>ファイルAを少し追記
の時点でAとはべつの実体（A'）が出きるんじゃなかったっけ。つまり無関係
0378login:Penguin
2013/10/14(月) 00:21:42.45ID:ZoNJuLo2それだとファイルAの破損箇所がファイルA'との差分箇所以外の場合
ファイルA'ごと破損するはずなので言ってることが矛盾してるように感じるが
話題は変わるんだけどzfs on linuxでも.zfsって見れない？
zfs set snapdir=visible は設定してるけど表示されない。
正直これが使えないとなるとzfs-fuseから乗り換えた意味が全くないんだが
0379373
2013/10/14(月) 01:00:55.67ID:sAc0KzgY> ファイル一式あるのに、そのブロックだけ持って来ても大抵の場合はあんまり嬉しくないからだろうね
1GB のファイルの 4KB の１ブロックだけ壊れた場合にファイル全体(1GB)書き戻すのと、
4KBブロック１つ書き戻すのだと、俺は4KBブロック１つ書き戻すほうがうれしいけどなぁ。
> どう見えるもこう見えるも、コピー先のファイルは、コピー先のディスクもファイルシステム
> も壊れてなければ普通に見えるだろう
質問しなおすけど、壊れたコピー元ではスナップショットのファイルはどう見えるの？
0380login:Penguin
2013/10/14(月) 09:50:58.32ID:Zfe6LAQJ> の時点でAとはべつの実体（A'）が出きるんじゃなかったっけ。つまり無関係
できない。その場合、追記されたブロック以外は同じまま共用される
>>378
すまん、どことどこが矛盾してるのか分からん
>>379
> 質問しなおすけど、壊れたコピー元ではスナップショットのファイルはどう見えるの？
壊れてるなら壊れて見えるだろうね。つか、俺は>>371を、「コピー先に存在するはずの過去のスナップショット」
についての質問だと思ってたんだが、違うのかな？
0381login:Penguin
2013/10/14(月) 11:04:48.02ID:ZoNJuLo2>できない。その場合、追記されたブロック以外は同じまま共用される
真偽はともかくこの共用されてる部分でエラーが出たら
ファイルAもA'影響受けるんじゃないの？
そしたら>>372のコメントと矛盾してるじゃん。
こうやって考えるとsend/recvでバックップしてても使い勝手微妙だな
・エラー時もファイルを修復できない。(正しいと思われるファイルを手動で上書きする必要あり)
・過去にスナップショットしたファイル破損時はファイル上書きによる修復すらできない。
(スナップショットの状態そのままで過去のファイルを変更できないため)
0382login:Penguin
2013/10/14(月) 12:17:44.52ID:sBIgmQeX済まんが、どことどこが矛盾してるのか分からん
コピー元のAとA'は、その共通部分が壊れりゃ、そりゃ両方共読めなくなるよね
コピー先にあるAもA'も、まだ壊れてないんだから、両方とも問題ないでしょ
これ↑矛盾してるか？
つか、>>371が想定していると俺が思ってる運用法とお前さんが思ってる運用法が違ってる気がする
もしかすると、コピー元にも延々過去のスナップショット残しておく感じなのかな？
> ・エラー時もファイルを修復できない。(正しいと思われるファイルを手動で上書きする必要あり)
「ファイルの修復」が何を意味してるのかよく分からんけど、cp では不満だというなら
コピー先のスナップショットを send, recv して持ってくればいいんじゃないの？
> ・過去にスナップショットしたファイル破損時はファイル上書きによる修復すらできない。
> (スナップショットの状態そのままで過去のファイルを変更できないため)
コピー先のスナップショットを一式、全部まとめて持ってくればいいんじゃないの？
現在、過去1、過去2とか、まとめて普通に send, recv 出来るけど？
よく分からんけど、壊れたブロックその物を物理的に修復してほしいって話なのかな？
send, recv なり cp なりなんなりで元のデータが手に入れば問題ない気がするけどな
壊れたディスクは交換して、バックアップからデータを書き戻すことに何の問題があるのか分からん
0383login:Penguin
2013/10/14(月) 12:32:23.46ID:ZoNJuLo2>コピー元のAとA'は、その共通部分が壊れりゃ、そりゃ両方共読めなくなるよね
>コピー先にあるAもA'も、まだ壊れてないんだから、両方とも問題ないでしょ
じゃあ上の状態で壊れたコピー元のファイルA'に対して
正常なコピー先のファイルA'を上書きコピーで書き戻せばどうなるの？
コピー元のファイルA'は正常な状態でも、スナップショットのファイルAは壊れたままじゃないの？
そりゃ過去のスナップショットも含めて全部片っ端からsend/recvすりゃ話は別だけど
そんなこと>>371のどこにも書いてないわな。
0384login:Penguin
2013/10/14(月) 13:19:42.53ID:sBIgmQeXその操作はエラーになるんじゃないかと思うよ。CoW なんで書き込む前に読み出すはずだからね
で、元の A はそりゃ、壊れたままだろうけど、それのどこに矛盾があるの？
もう一回書くけど、俺は>>372 で「コピー先に存在するはずの過去のスナップショット」について言った
>>371を「元ディスクには現在のファイルしか無く、先ディスクにはその時々のスナップショットがある」
と理解していたからね
それが勘違いだったとしたら、「あぁそこは勘違いしてましたね」って話
0385login:Penguin
2013/10/14(月) 14:06:13.22ID:CymNGmWP>>371の解決に繋がる話が何もなくてワロタｗ
0387login:Penguin
2013/10/14(月) 19:33:14.04ID:x6sl8hV+>>380
ＰＣ１にスナップショットが殆ど残っていないという解釈については理解したが、
質問２の「PC2からPC1に破損したファイルを丸々上書きコピーすると」が、
説明不能かと思うがどうよ。
0388login:Penguin
2013/10/14(月) 20:57:21.79ID:lNF4NHwS.zfs/snapshotから差分ファイルに直接アクセスするのは
zfs-fuseだろうがzfs on Linuxだろうがまだ実装されてない？
それともsnapdir=visible以外に何か設定が必要？
0389login:Penguin
2013/10/15(火) 18:26:41.23ID:uMxQLvVIZFS on Linuxだとsnapdirの設定はls -aとかで.zfsディレクトリが表示されるかどうかくらいしか影響がなくて、
どっちにしろコマンドラインから.zfs直打ちすれば見られるよ。
/pool/fs/.zfs/snapshotとかをnetatalkで共有してマウントとかもできてる（あまり行儀良くないけど）。
単にls -lとかで出てこないから見られねー、って思ってるだけでは？
0390login:Penguin
2013/10/15(火) 19:21:18.18ID:3/XRQc90ls -la、cd .zfsともに試したのですがやはり存在しないようです。
ファイル作成後、削除後でそれぞれスナップショット取ってみてもやはり存在せず…。
mint archive # zfs get snapdir data/archive
NAME PROPERTY VALUE SOURCE
data/archive snapdir visible local
mint archive # pwd
/data/archive
mint archive # ls -la
total 5
drwxr-xr-x 3 mint mint 4 10月 15 19:11 .
drwxrwxrwx 3 mint mint 5 10月 15 18:51 ..
drwxr-xr-x 2 root root 2 10月 15 19:11 test
-rw-r--r-- 1 root root 0 10月 15 19:11 tste
mint archive # cd .zfs
-su: cd: .zfs: No such file or directory
0391login:Penguin
2013/10/15(火) 20:13:32.41ID:9yslWU/U0392login:Penguin
2013/10/15(火) 20:20:22.57ID:3/XRQc90入れようと思ってたんですが文字数の関係で。
mint ~ # zfs list
NAME USED AVAIL REFER MOUNTPOINT
data 273K 58.6G 43.5K /data
data/archive 72K 58.6G 34K /data/archive
data/archive@1 19K - 30K -
data/archive@2 19K - 31K -
0393login:Penguin
2013/10/16(水) 00:42:15.06ID:bV92DcXSまさかfuseが動いたままとかじゃないよね？ zpool get version data は - （feature flags）になってる？
0394login:Penguin
2013/10/16(水) 00:47:20.29ID:WYtw9dDo0395login:Penguin
2013/10/16(水) 20:12:10.18ID:5KXerEgC- defaultになっていますがもしかして何かおかしな感じですか？
mint@mint ~ $ sudo zpool get version data
NAME PROPERTY VALUE SOURCE
data version - default
0396login:Penguin
2013/10/16(水) 20:18:01.51ID:3H37weR+は？
0397login:Penguin
2013/10/16(水) 20:31:16.67ID:5KXerEgCやっぱディレクトリ自体がないみたいです。
mint@mint ~ $ sudo ls /data/archive/.zfs/snapshot/
ls: cannot access /data/archive/.zfs/snapshot/: No such file or directory
0398login:Penguin
2013/10/16(水) 20:38:55.02ID:Dz3qOO7d例１: Solaris10 1/13
# zpool get version rpool
NAME PROPERTY VALUE SOURCE
rpool version 29 local
例２：FreeBSD 9.2-STABLE
# zpool get version rpool
NAME PROPERTY VALUE SOURCE
rpool version 28 local
0399login:Penguin
2013/10/16(水) 21:43:40.64ID:5KXerEgCSolarisとLinuxの違いでしょうか。
少なくともfuseが残ってるわけではなさそうですが…。
mint ~ # find / -name zfs
/lib/modules/3.8.0-19-generic/extra/zfs
/lib/modules/3.8.0-19-generic/extra/zfs/zfs
/etc/bash_completion.d/zfs
/etc/sudoers.d/zfs
/etc/default/zfs
/etc/zfs
/var/lib/dkms/zfs
/var/lib/dkms/zfs/0.6.2/build/cmd/zfs
/var/lib/dkms/zfs/0.6.2/build/module/zfs
/var/lib/dkms/zfs/0.6.2/build/etc/zfs
/sbin/zfs
/sys/devices/virtual/misc/zfs
/sys/class/misc/zfs
/sys/module/spl/holders/zfs
/sys/module/zfs
/sys/module/zavl/holders/zfs
/sys/module/zunicode/holders/zfs
/sys/module/zcommon/holders/zfs
/sys/module/znvpair/holders/zfs
/usr/src/zfs-0.6.2/cmd/zfs
/usr/src/zfs-0.6.2/module/zfs
/usr/src/zfs-0.6.2/etc/zfs
/proc/spl/kstat/zfs
/dev/zfs
/dev/disk/by-partlabel/zfs
0400login:Penguin
2013/10/17(木) 18:33:21.63ID:KqIM93ZTいや、それはVALUEのところが - ってことだから正しい。
28までやSolarisでは>>398みたくバージョン数が表示されるけど、
feature flags導入以降のZFSでは - になる。
- ってことはZFS on Linuxがちゃんと動いてるはずなんだけどなぁ・・・わからん。
0401login:Penguin
2013/10/17(木) 19:13:25.79ID:tkXuK3Ha0402login:Penguin
2013/10/17(木) 22:01:11.67ID:Otb/u/+Oマウントもされてます。
とりあえずテストで仮想環境に入れたから何かイレギュラーなことになってるのかなぁ。
mint ~ # zfs mount -a
mint ~ # zfs list
NAME USED AVAIL REFER MOUNTPOINT
data 342K 58.6G 31K /data
data/archive 30K 58.6G 30K /data/archive
mint ~ # ls -la /data/archive/
total 3
drwxr-xr-x 2 root mint 2 10月 15 22:39 .
drwxrwxr-x 3 root mint 3 10月 15 22:54 ..
0403login:Penguin
2013/10/18(金) 23:00:04.49ID:av8klvMNストライプをオフにしてプールを拡張することはできないでしょうか。
(片肺だけ接続すればディレクトリ構成と残ったほうのファイルだけ表示されるイメージ)
できない場合はmhddfsとかaufsが妥当な方法に思えますが、
mhddfs、aufs、unionfsといくつか種類があり違いがわからないためおすすめを教えてください。
0404login:Penguin
2013/10/18(金) 23:44:03.72ID:3s4nR1Z90405login:Penguin
2013/10/18(金) 23:59:35.96ID:N6zLLs+Fそれ、zfs な単体ディスクを２台マウントするのとなんの違いがあるの？
0406login:Penguin
2013/10/19(土) 10:24:01.63ID:GgoqxQieZFS on Linux界隈の話はよく知らんのだが、
.zfs/snapshotディレクトリのautomountが動いて無いんじゃないか？
ちょっと古い情報だが
http://askubuntu.com/questions/103369/ubuntu-how-to-mount-zfs-snapshot
これでマウント出来るようなら、どこかがおかしい。
0407login:Penguin
2013/10/19(土) 15:04:47.08ID:NAIzXW3Sその目的（単純なディレクトリ結合）ならmhddfsだろうけど。
unionfs/aufsは光学ディスクとRAMディスクみたいな性質の違うメディアをくっつけることが主目的だし。
ただ目的とその動機がマトモとは思わんけどね。どうせ飛んだディスクに一番大事なデータが乗ってて泣くんだろう。
0408login:Penguin
2013/10/19(土) 16:02:45.17ID:xoeGYH0+sambaで共有するときには2台のHDD(ディレクトリ)を束ねた状態で表示したいのです。
ようはWindowsのほうでドライブレターを分けたくない
>>407
mhddfsで束ねようと思います。ありがとうございます。
バックアップ自体は容量が中途半端な古いHDDを束ねてcopies=2指定で構築した
zfsファイルサーバがあるのでそちらにsendしています。
そのマシン自体は古く、音も煩いので押入れに配置しており、
回線も無線で飛ばしているような状態なのでメインで使うつもりはありません。
0409login:Penguin
2013/10/19(土) 16:14:00.78ID:OAyqpWjp0410login:Penguin
2013/10/19(土) 16:25:54.31ID:FWlaMzyb>sambaで共有するときには2台のHDD(ディレクトリ)を束ねた状態で表示したい
普通にシンボリックシンク張ればいいだけじゃないの？
0411login:Penguin
2013/10/19(土) 16:43:42.05ID:xoeGYH0+/zfs/fs/dirA/
/zfs/fs/dirB/
/zfs/fs/dirC/
上のような構成だとdirA、B、C以下でディレクトリ分けをせずにファイルを直接配置しています。
また、dirAとdirBは容量がほとんどなく、
dirCの直下に大量の大容量ファイルが存在するような形なので、
dirC自体を2つに割りたい状態です。
3TBのHDDを購入すればシンボリックリンクでも解決できますが
シンボリックリンクではなくmhddfsを使うと何かデメリットがあるのでしょうか。
0412login:Penguin
2013/10/19(土) 17:01:55.40ID:ujSq5fBA0413login:Penguin
2013/10/19(土) 17:02:44.55ID:FWlaMzyb/zfs/fs/dirC/dirB_s ←dirBのシンボリックリンク
/zfs/fs/dirCをsambaで共有
いまいち分からんけどこれでだめなの？
0414login:Penguin
2013/10/19(土) 17:09:19.48ID:n/G/XApW0415login:Penguin
2013/10/19(土) 17:13:34.78ID:xoeGYH0+共有しているのは以下のディレクトリです。
/zfs/fs
で、新しくプールを追加して下の配置にするとzfs2の容量がしんどくなる。
/zfs/fs/dirA
/zfs/fs/dirB
/zfs/fs/dirC_s <- シンボリックリンク
/zfs2/fs/dirC
win側のバッチでもろもろ処理をしているためfs以下のフォルダ構成は変えたくない状態です
0416login:Penguin
2013/10/19(土) 17:24:30.93ID:ujSq5fBA0417login:Penguin
2013/10/19(土) 17:30:59.74ID:FWlaMzybだからこんなこと書いても他人が見ても分かるわけないでしょ？
0418login:Penguin
2013/10/19(土) 17:50:06.88ID:xoeGYH0+dirCが容量の大半を食っているので
2TBのzfsプールと同サイズのzfs2ではすぐに限界が来てしまいます。
3TBを購入すればしばらくはもつと思いますがそれもいつまでもつかわかりません。
mhddfsで簡単にdirCを重ねられるならそれに越したことはないかなと思いました。
0419login:Penguin
2013/10/19(土) 18:49:21.14ID:EFTZEr4F0420login:Penguin
2013/10/19(土) 22:57:40.19ID:JHcTRlgiSSDに最適化されているというF2FSを使ってる人いる？
0421login:Penguin
2013/10/19(土) 23:45:24.40ID:LBGng1/xいる。少なくとも開発者は使ってんだろ。
0422login:Penguin
2013/10/19(土) 23:47:23.01ID:xoeGYH0+何回かにレスを分けてたので自分でもどこまで話したかわからなくなっていました。
結局dirCをzfsプールとzfs2プールにわけようと思うとmhddfsを使うほかないですよね？
そもそもmhddfsではなくシンボリックリンクが勧められる理由は何なのでしょうか。
手軽なのは確かにそうなのですが、ファイルパスが変わるとすべてのリンクを作りなおす必要があったり、
リンクファイルをコピーする際に、アプリによってリンク先の実体をコピーするものと
リンクファイル自体をコピーするものでまちまちなためmhddfsのほうが便利だと思っていたんですが
0423login:Penguin
2013/10/20(日) 00:01:33.25ID:gTxMqX1Iストレージの大事さを理解してればコストは惜しまないと思うよ
0424login:Penguin
2013/10/20(日) 00:49:58.77ID:fYTyHLf/0425login:Penguin
2013/10/20(日) 03:14:43.76ID:LybDE0D6何でmhddfsからいきなりシンボリックリンクの話に飛ぶんだろうか
0426login:Penguin
2013/10/20(日) 09:32:16.08ID:lUo3Q4yG>>407 その目的ならmhddfsがいい
>>408 じゃmhddfs使います
まとめるとこういう事
他はノイズ
0427login:Penguin
2013/10/20(日) 09:55:29.72ID:dkuoGXU6あと、mhddfsとやらが実際の所どの程度信用できるかは知らんが、少なくとも、
・性能が低下する
・元のディスクが一杯になるまで追加したディスクには書き込まない
んだろ？
もしかしてこいつの中では「片方のディスクが壊れても、半分のファイルは生き残る」
事になってるのかも知れんが、それは両方が一杯になった時だけで、元のディスク
の方が古い＝壊れるのも先なんだから、今の所殆ど全てのファイルを失う可能性の方が
高いだろ。その時にはバックアップがある！ってのなら、そもそもzfsでもいい話で
貧乏性でどうしても古いディクも使いたいってなら、
4TBと2TBか3TBと1TBのディスクとJBOD出来るカードを買うなりなんなりで入手
→ 新しいディスクの大きい方で zpool create して autoexpand=true
→ zpool attach → 古いディスクを detach → 新しいディスクの小さい方と古い
ディスクで JBOD組む → attach とかするかな？
つか、自分なら2TBx4とかでraid-z2するだろうけど
0428login:Penguin
2013/10/20(日) 09:58:51.19ID:dkuoGXU6×そもそもzfsでもいい話
○そもそもzfsでストライプすりゃいい話
0429login:Penguin
2013/10/20(日) 11:10:41.88ID:C/3bPKFZおまえこの前の高飛車勘違い君だろ。
>そもそも、こいつのお大事なバッチとやらを書き換えれば、何の問題も無いんだろ？
それがしたくないからって質問してるのにお門違いもいいとこ
>あと、mhddfsとやらが実際の所どの程度信用できるかは知らんが
知らんならえらそうに話すな。
性能測定まではしてないが次のディスクに書き込み始めるまでの容量は決めれる
>もしかしてこいつの中では「片方のディスクが壊れても、半分のファイルは生き残る」
>事になってるのかも知れんが、それは両方が一杯になった時だけ
もう無茶苦茶。片方のディスクが壊れても当然生きてる方に書き込まれたデータは生き残る。
両方じゃなくて片方と言いたいんだろうが次ディスクに書き込む容量は変えられるからそれも間違ってる。
>古い＝壊れるのも先なんだから、今の所殆ど全てのファイルを失う可能性の方が
>高いだろ。その時にはバックアップがある！ってのなら、そもそもzfsでもいい話
まず古いHDDが壊れたら殆ど全てのファイﾙを失うっていう前提が意味不明。
どういうファイルを管理してるかは知らんが新しいデータが生きてることは大きいだろ。
>つか、自分なら2TBx4とかでraid-z2するだろうけど
>>単品HDDのzfsを拡張したいのですがRAIDは怖いし、小回りがきかないので避けたいです。
こう言ってるやつにRAIDを勧める意味がわからない。
将来また足すかもとか言ってるやつが一回RAIDZ2なんて組んだらディスク1本だけ足すとかができないだろうに。
0430login:Penguin
2013/10/20(日) 11:31:51.12ID:dQajVw2Kデキる自分を主張したくてクズでもかまいたがるゴミクズ回答者はくたばれ
0431login:Penguin
2013/10/20(日) 19:29:27.08ID:o0GJpDC3俺のディスクは全てRAID1。
0432login:Penguin
2013/10/20(日) 20:50:51.47ID:C/3bPKFZ企業と違って個人ではファイルサーバが一時的に停止しても問題ないし
コスト度外視で考えてもそこまでRAIDが必要ってわけでもないと思うんだけどな。
確かにzfsの機能をフル活用するならガンガンHDD繋ぐほうがいいんだろうけど
・仮に死んだときにデータが全て飛ぶ上に復旧も絶望的
・HDDをちょっと別PCに繋ぎたいときもHDD4個も5個も運ばないといけない。
・RAIDZならHDDを1個追加みたいなことができない。
・RAID1の場合も増設時は同容量のHDDを2つ用意する必要がある
(HDDだけならともかくsata端子が足りなくなってきてポートマルチプライヤ買うはめになったりする)
スナップショット、cow、圧縮、チェックサムが便利だからzfs使ってるけど
raid嫌いな人のためにもストライプ切れるようにならないもんかね。
というかマイナーなところ探せばそういうFSもありそうだけど人柱怖い
0433login:Penguin
2013/10/20(日) 21:40:46.40ID:jf7+doXb＞zfs使ってるような人は元々趣味でRAID組んでるような人が多いから意見が偏ってるんだよなぁ。
それを偏見って言うんだよ。
そんな事言う奴の話なんて、誰も聞かねーよ。
みんな、使える道具の中で運用考えてんだよ。
RAID嫌いな奴はそもそも、そういう運用前提で、
ちゃんとHDDを使い分けてるだけだろ？
■ このスレッドは過去ログ倉庫に格納されています