LVMを語らせていただけませんか？

LVMを語らせていただ� ..

598:login:Penguin
08/03/24 21:07:48 xwvutk/t
>>597
>>1に書いてある

599:login:Penguin
08/03/26 10:27:32 /rbx928m
スナップショットが簡単にできるならと思い、Fedora8で
# lvcreate --snapshot --size=1G --name snap0 /dev/VolGroup00/LogVol00
そしたらエラーになった。
Insufficient free extents (1) in volume group VolGroup00: 96 required

デフォルトインストールなので VolGroup00はLogVol00だけで空きはない。
HDD追加せずにsnapshot領域を確保するには
LogVol00を縮小できればいいような気がするけど、できるの？

600:login:Penguin
08/03/26 10:51:42 JMhK92pu
FSが縮小に対応していて、もちろん空きがあれば。

601:login:Penguin
08/03/26 14:16:06 /rbx928m
>>600
あんがと、できるかどうかから調べるのはNG時のショックが大きいので躊躇してた。
一応
1. レスキューでmountせずに起動
2. lvm vgchange -ay /dev/VolGroup00 <-LVM有効化
3. fsck.ext3 -f /dev/VolGroup00/LogVol00
4. resize2fs /dev/VolGroup00/LogVol00 34G
-- reboot --
5. lvresize -L34G /dev/VolGroup00/LogVol00
6. lvcreate --snapshot　・・・・
無事 snapshot 領域確保できた。

602:login:Penguin
08/04/09 22:10:32 5v+cawCi
pvmove中でも普通にpc使って大丈夫なのかぁ。
なんかlinuxはどの作業が危険だとか認識される／されないが分かりづらいな。
クラッシュしても続きからいけるとか書いてるから安心してwebをm

603:login:Penguin
08/04/10 00:26:18 5lkztsUT
mountされてなきゃただのI/Oよ

604:login:Penguin
08/04/10 02:25:07 GkLC0n+x
>>603
いやマウント中の作業です。
無事終わった。

605:login:Penguin
08/05/05 12:04:22 qLvyVB3C
LVM3開発開始だとか

606:login:Penguin
08/05/05 12:43:49 p+flnnxD
LVM3はちゃんとバリアが効くようにしてください

607:login:Penguin
08/06/04 22:30:36 n3tY6HIr
LVM(中身はext3)の外付けHDDがあります。
これを別のマシンにつないで中を見たいのですが
どうやってLVMをマウントすればいいのでしょうか？
普通だったら
nfs -t ext3 /dev/sda /mnt
だと思うのですがLVMの場合はどうすれば？？？

608:login:Penguin
08/06/05 08:30:16 pEFbHf00
>>607
pvscanしてvgchange -a yしたらいいと思うよ。

609:login:Penguin
08/06/05 17:10:26 JbNBeTqA
nfs?

610:login:Penguin
08/06/05 18:13:27 21YGfzJ8
lvcreateであいているスペースすべてを作成するには以下のコマンドであっていますか？
lvcreate -l 100%FREE -n LV VolGrouptest
URLﾘﾝｸ(linux.die.net)
↑読んだんですけどいまいち-lオプションのVGとFREEについてわからなくて・・・

611:login:Penguin
08/06/05 23:22:00 xuMIbzDB
起動ドライブのVolGroup00をVolGroup99にしたら起動しなくなったのだけれど
助けて

612:login:Penguin
08/06/06 11:11:47 25LbsBUl
>>611
インスコCDのレスキューモードで起動して名前直せばいいんじゃない？

613:login:Penguin
08/06/06 12:48:36 F4ZUbmLb
>>610
>>544-557あたり読んでみれば?
俺がどうしてもサイズ変更できなくて苦闘したときのやりとりだが。
いろんなパターン片っ端から試してる。
(やってるのはlvextendだが指定方法は同じ)

ちなみに、オチはVineのバグだったとゆーw

614:login:Penguin
08/06/07 01:30:03 juXFIy0Q
>>610
%指定は動かないから実装されてないんだと思ってたよ

615:login:Penguin
08/06/07 21:03:01 Gk9jVHRS
gpartedでLVMの入ったパーティションをリサイズ(拡大)したいのですが
どうしてもうまくいきません。
もちろん空きはあります。fdiskで新しいパーティションをつくれます。
どうやってパーティションを広げたらいいでしょうか？

616:login:Penguin
08/06/07 21:10:21 AVJ99GJ4
>>615
未対応

617:login:Penguin
08/06/09 13:15:08 Qv/HdhEc
>>615
pvresize

でもぶっちゃけリスクを負いたくないなら新しいパーティションをPVに追加するだけでもいいんじゃないかと

618:login:Penguin
08/06/14 00:42:09 GtA4XCQf
LinuxLVMで質問です
起動時、grub> のプロンプトでkernel行のroot= の部分でルートファイルシステムを指定しようと思うのですが、
LVMのデバイス名（vg名やlv名）を忘れてしまった場合、
TAＢキーやfindコマンドを使ってもルートファイルしシステムがLVMなので補完したくてもできない場合、
Linux のLiveCD等で起動してLVMのデバイス名を調べるしかないですか？

619:login:Penguin
08/06/14 12:58:34 uzvw2+4m
複数ディスクをLVMで1ボリュームにしてガバっと使いたいんだけど
LVMのデメリットって何？
1つのディスクが死んだら終わりとか？

620:login:Penguin
08/06/14 14:00:20 1+VSoFd/
多少のオーバーヘッドがあるくらい？
あとトラブル時に対応できるスキルがないとダメなくらいかな？
よくわかんないけど。

621:login:Penguin
08/06/14 15:12:39 6SEFplCp
ゴミどもめ

622:login:Penguin
08/06/14 20:08:31 ae9YVSGi
オーバーヘッドだけ？
束ねたディスクのうち1台が死んだらどーなるの？

623:login:Penguin
08/06/14 20:34:58 sC2X09Sk
全滅

624:login:Penguin
08/06/14 21:02:44 qs0Dc9DK
上がってるから何気に開いたらこのスレ2002年からあるのか…

625:login:Penguin
08/06/15 02:37:09 B19FrabJ
>>619
動的に容量を増減できるところはメリットかなぁ

626:login:Penguin
08/06/15 16:20:52 CdTlYS0s
>>622
LVMは普通RAIDと一緒に使う。
RAIDの上にLVM。

627:login:Penguin
08/06/15 19:47:05 BA+ZzdGW
ZFS vs. Linux Raid vs. Linux LVM vs. Linux LVM + Raid
URLﾘﾝｸ(www.unixconsult.org)

628:login:Penguin
08/07/01 21:37:53 3IykgVK0
一つのディレクトリに2箇所からmountすれば
単一のボリュームとして扱われると信じてたころが懐かしい
2箇所からリンク引っ張って合体とか・・・
そういう仕様で作ってくださいとエロい人にいいたい

RAIDの上にLVM必至とか、安全なんだか危険なんだか
便利なんだか面倒くさいんだか全然わかんねーよ

そんな理由でLVMに踏みきらない人は多いはず

629:login:Penguin
08/07/01 21:58:45 0HA3LMf0
漏れも漏れも
使ってるトリのインストーラの標準がLVMだから
切るのまんどくさい。つーかやめていただきたい。

630:login:Penguin
08/07/02 08:03:43 1ybAcnmw
>>626
世の中のUNIXサーバーは、内蔵ディスクに「RAIDの上にLVM」なんてことは
しないが。
LVMミラーリングでRAID1を構成することはよくあるが。

631:login:Penguin
08/07/02 09:16:38 RgaN+n31
俺のRHEL5はインストール時RAID5の上でLVMしてる…
コレって普通じゃないの？

632:login:Penguin
08/07/02 12:33:30 kY+rYQjq
>>630
UNIXサーバとやらだったら
ハードウェアRAIDがデフォルトなんじゃないの?

633:login:Penguin
08/07/02 12:41:27 15uy4jBz
別にデフォルトではないよ。

634:login:Penguin
08/07/02 15:19:43 eGcFOXuW
というか、カードタイプのハードウェアRAIDなんかまず使わん。

635:login:Penguin
08/07/02 20:16:05 1ybAcnmw
ハードウェアRAID使ってるのなんて、PCみたいな廉価なサーバーぐらいしか
思い浮かばん・・・

636:login:Penguin
08/07/04 00:33:48 X/oJ9laK
最近のUNIXサーバは内蔵ディスクでハードウェアRAIDに対応しているものが多いと思う
HPでもSunでも

ただ>>626は外部ストレージのことを言ってる様な気がする

637:login:Penguin
08/07/04 01:57:46 7gcupJvt
>>636
> 内蔵ディスクでハードウェアRAID

?

638:login:Penguin
08/07/05 10:54:50 MeeUCArm
>>637
マザーにRAIDチップが載ってるタイプのことと想像。

639:login:Penguin
08/07/06 19:41:38 AtahaQoe
URLﾘﾝｸ(www.atmarkit.co.jp)

ふつうターゲット上でLVMじゃねーの？

640:login:Penguin
08/07/25 23:39:36 8Ned7Kmk
言っちゃうぞ。

まだスナップショット駄目なんだってな。
素直に evms にしときゃあ……くっ……

641:login:Penguin
08/07/27 03:15:50 RwYz5TZf
LVMを構成しているHDDのうち、１台が故障したとき、
LVMで構成したファイルシステム全体が見えなくなるのでしょうか。
それとも、一部のファイルのみが見ることができなくなるんでしょうか?

642:login:Penguin
08/07/27 12:21:57 zvF1vjzN
ちょっと検索すりゃ
すぐ出てくる話だと思うが

643:login:Penguin
08/07/28 06:10:17 vcSXj+Qj
LVMに経験ある人の話を直積
聞きたいから来たわけだが

644:login:Penguin
08/07/28 06:29:35 vcSXj+Qj
とだけ書いても会話になりそうにないから付け足して書けば、
僕の予想では、LVMの上に構築するファイルシステムの種類によって違うのだと思う。
ファイルへのインデックスが書かれている番地が偏在しているようなファイルシステムで
インデックスがたまたま位置したHDDが故障すれば全部が見えないこともあるし、
逆の場合は、大きなバッドセクタのようになり、ファイルが虫食い状態になる。
そう考えていいのですか?
それとも、LVMシステムがボリューム構築に利用する情報がHDDの障害に脆くて
HDDが１個焼失してもLVMが機能しなくなるのでしょうか・・・。

645:login:Penguin
08/07/28 11:36:57 DQdsBUbz
ちょっと検索すりゃ
(LVMに経験ある人の話が)
すぐ出てくる話だと思うが

646:login:Penguin
08/07/29 01:14:16 8d+X+gCG
>>644
LVMはファイルシステムから見たらただのブロックデバイスだよ。

647:login:Penguin
08/07/29 06:42:34 lGh89x8f
例えばHDD１０個をつなげてLVMを作れば、どこかで故障が起こる可能性は１０倍に増える。
対障害性能があるRAIDと組み合わせて（２重化として対障害は積算か）も、効果が相殺されて厳しい気がする。
だけど１０個つなげばLVM全体から見ればHDD一つは１／１０の故障となるから故障規模は小さくなるわけで
結局RAID+LVMを構成するかしないか決断がつくには、
１個のHDDの故障が、どれだけのデーターの損失波及するかによるよね。
物理的損失より必ず論理的な情報損失のほうが大きくなるわけで、
一つはLVMシステムが持っている管理情報がダメージを受けること、
もう一つは上に構成したファイルシステムに障害がおこりダメージが派生することだ。
すなわちLVMやファイルシステムの障害が個別のデーターではなく、それ以上にデーター全体の整合性に波及することが
怖い。
その辺のから解脱できたひといたら語ってほしい。

648:login:Penguin
08/07/29 08:45:05 cjUPK7RU
> 例えばHDD１０個をつなげてLVMを作れば、どこかで故障が起こる可能性は１０倍に増える。

基本情報処理から勉強し直したほうがいいよ。

それと、「データー」って何?

649:login:Penguin
08/07/29 13:43:57 FOLu2OoK
135から読み直せ

650:login:Penguin
08/07/29 14:39:34 PdclCiTI
実際には、モノの故障率によって変わってくるけど、まあ10倍でいいよ（笑）

651:login:Penguin
08/07/31 13:47:14 jh4IJeuA
>>135
厳しい現実がかかれてるね・・了解。

652:login:Penguin
08/08/13 12:21:14 XmgY44KA
>>648
稼働率0.9のHDDを10台用意し、それらで一つのボリュームグループを作ったら、
LVMの稼働率は0.9^10になります。

653:login:Penguin
08/08/13 12:24:28 XmgY44KA
>>648
>>650
お前らなんでそんなに不親切で知ったかぶりな態度をとるんだ？
そんな小馬鹿にした態度をとる暇があったら答えを書けよ答えを。

654:login:Penguin
08/08/13 12:47:02 XmgY44KA
ああ、つまり、答えを知らない初心者君が同じ初心者をいたぶっているだけか。

655:login:Penguin
08/08/13 23:45:22 sho8OfFG
二週間遅れのツッコミ乙

656:login:Penguin
08/08/15 23:56:12 Dahhif8C
やっと勉強して帰ってきたらしい

657:login:Penguin
08/09/14 12:01:57 O5/W6Pyy
ソフトウェアのストライピングが微妙な件

658:login:Penguin
08/09/14 14:11:22 QHy0db2G
スレ違い?

659:login:Penguin
08/09/17 03:24:11 s5weIHPc
単にインタリーブしてるだけだしな

660:login:Penguin
08/09/25 14:46:51 m/JW7tpN
lvm 使うか普通にパーティション切るかで考えてるですが、
将来HDD交換して増量させたい場合は、lvmの方が良いんでしょうか？
lvmならパーティションのように困らず
自由に領域を変更できる、みたいなのがウリな気がしますが、
結局Gpartedとかでパーティション増やせるし変わらない気がします。
そこのところどうなんでしょう。

これまでlvmを使ってきましたが、
gpartedなどが対応していないため、
部分的にコピーしたい場合など非常に不便に感じています。
ああ、これパーティション切ってたら、パーティションコピーして
終わりなのになあ・・・みたいな感じです。

661:login:Penguin
08/09/25 15:28:36 wLKYoEG2
おれはlvm使わないなぁ。メリットがわからん。

662:login:Penguin
08/09/25 16:04:36 LyRk07KA
交換して増量するなら大してかわらないだろう
追加して増量するときに威力を発揮すると思うんだが・・・

663:login:Penguin
08/09/25 16:15:48 5Y5rOSdf
>>660
HDD交換で増量ではなく
HDD追加で増量のときにメリット大。
ただ、普通に足したらHDD故障時に面倒になるんで
大抵の人はRAIDと組み合わせて使ってるのでは。

RAID + LVM + XFSの組み合わせが
容量変化の要求に対して柔軟に対応できて
かつ安全な組み合わせだと思うが。

こういったメリットが分からない、
あるいは、そのメリットが不必要な人は
別に無理して使うもんでもないと思う。

664:login:Penguin
08/09/25 16:16:44 5Y5rOSdf
ｦ
一部カブった

665:login:Penguin
08/09/25 16:24:35 Mtld4aS2
HDなんて揺らさずに冷やしまくれば10年は壊れない。
と最近思えてきた。

666:login:Penguin
08/09/26 05:29:58 L6fJPxoG
うちのサーバも663の組み合わせにしてるけど、
XFSだと容量を減らせないのが場合によっては扱いづらいかも。

元々は多数のストレージデバイスをうまく抽象化したり、
容量割り当てを固定化しないためのものだから、
660みたいな容量ぎりぎりでやりくり(?)するような使い方は
LVMとしては想定の外だろうね

LVMを使う場合はその複雑性とつきあう必要も出てくるから、
小規模なら使わない方が良い場合も多いだろうね。

667:login:Penguin
08/09/26 10:28:02 3nl099Gm
おれはsnapshotが便利だから使ってるよ。

668:login:Penguin
08/09/26 13:39:08 XgVKNEXu
>>665
それは間違い

669:login:Penguin
08/09/26 13:49:21 QI1JpPNb
>>665
URLﾘﾝｸ(gigazine.net)

670:login:Penguin
08/09/26 14:05:40 c/zlIyMB
>>669
GoogleのHDの使い方と、一般人のHDの使い方は違うから
一概にそうも言えないと思うが。GoogleのHDは環境によるダメージを
受ける前に別の要因で死んだ可能性もあるし。

671:login:Penguin
08/09/26 15:13:37 XgVKNEXu
故障については個人的な経験のみで語ると恥をかく

672:login:Penguin
08/09/29 21:05:23 UaUxgw6s
俺の脳みそを拡張するには
どのようなコマンドを実行すればいいでしょうか？

673:login:Penguin
08/09/29 21:12:44 L4lBHZ6L
>>672
vi

674:login:Penguin
08/09/29 21:23:05 4IQ0HTwg
>>669
頼むからその手のデマをばらまかないでくれ。
グーグルのはサーバルームで冷却されてるのが前提だ。

675:login:Penguin
08/09/29 21:26:58 L4lBHZ6L
>>674
で、君はどんなデマをばらまきたいのかな？

676:login:Penguin
08/09/30 00:51:45 0Isl7Nwk
>>675
意味不明だな。グーグルのアレを出して「HDDは高温でも大丈夫」と
言いふらすのは有害なデマだって事だ。アレを持ち出す奴はみんなそう。

だが実際は、「（サーバルームの温度範囲において）寿命と温度との相関はない」。

異論があるならどうぞ。

677:login:Penguin
08/09/30 00:54:08 iiLEqaD/
>>676
誰がそんな事を言いふらしているのだろうか？
やはり君が少しおかしい人なだけだろ

678:login:Penguin
08/09/30 13:17:49 zvVIh1Zj
>>676
サーバルームの温度範囲を越えた場合のデータってある?

679:login:Penguin
08/09/30 13:40:02 7DeFMFdL
>>676
グーグルのアレを出して「HDDは高温でも大丈夫」と
言いふらしているやつがどこかにいるのか?

お前の脳内に聞こえてくる声かもしれんがそれがデマだよ。

680:676
08/10/02 20:33:06 twJATkUN
>>677
>>679
> お前の脳内に聞こえてくる声かもしれんがそれがデマだよ。

ギガジンの紹介当時、自作板のHDDスレッドには寿命と温度は
無関係と突撃してくる量産型の厨が山ほど涌いたよ。

なら質問だが、>>669が>>665（温度と振動に気をつける）に対して
ギガジン記事のURL貼ったのはそれ以外の「どういう意図」だと思う？

当人じゃないから分からない、と言い逃れるなら意味不明だぞ。

>>678
そもそも20-50度の範囲での使用が前提で、家庭だと夏場
簡単に50度を超える。
電子部品で温度が無関係なんてありえない。

元論文
URLﾘﾝｸ(labs.google.com)
Figure 4: Figure 5: とそのコメント。
・AFRは年間故障率。
・45度未満では温度と故障率に関係ない。
（が、30度未満と45度以上では高い数値）
・あとFig5の３年目に注目。特定モデルの傾向が影響か。

似た別のアブストラクトもどっかで見た気がするが、
これしか見つからないので読みづらくても我慢しる。

/.-Jのやり取りも見とくこと。全件表示が望ましい。
URLﾘﾝｸ(slashdot.jp)

681:login:Penguin
08/10/02 20:36:57 twJATkUN
忘れてた。

>>678
当のギガジン記事にもこうある。

> ただし、ハードディスクの温度が50度を超えるような環境であれば、故障率は如実に
> 上昇しています。これはハードディスクのメーカーも推奨していない温度なので
> さすがに当然か。

682:login:Penguin
08/10/02 21:28:53 WziukuCx
>>680
わかったわかった
君が病人なのは良くわかった
たぶん幼い頃に御両親が君の温度管理に無頓着だったせいだろう

683:login:Penguin
08/10/02 22:02:40 twJATkUN
結局、誤魔化しかよw　クズだなあ。

684:login:Penguin
08/10/02 22:28:01 WziukuCx
誰がクズかはスレを見た人が判断してくれるだろう

685:login:Penguin
08/10/03 02:21:41 gz+UP2MN
このスレには揺らさずに冷やしまくったら、儲からなくなる人が（ｒｙ

686:login:Penguin
08/10/03 02:39:45 eQRaRQ0X
今北

>>680
温度に関しては異論はないというか同意見なんだが……言い方が高圧的すぎて損してるよ。
WziukuCxはクズだろうが。

687:login:Penguin
08/10/03 11:18:37 RuwrUhWh
>>674が意味不明なだけだろ。このスレでデマばらまいた奴がいるわけでもないのに、
いきなりやってきて過去の別スレの敵と戦ってるんじゃ病気と思われても仕方がない。

本人自身、「当のギガジン記事にもこうある」つってるんだから、
Gigazineの記事をリンクするのはデマばらまきじゃないことははっきりしてるわけで。

688:login:Penguin
08/10/03 11:25:32 Ri2P8GoR
元になった >>665 は明らかに温度の低いほうの話。
だから gigazine の記事で google の例をひいて反論するのは正当。
誰も 40 度超える高温の世界の話はしていない。
頭の温度管理が壊れた >>674 が一人で明後日の方向で吠えてるだけ。
吠えてる内容が間違ってないことに大して意味はない。

689:login:Penguin
08/10/04 02:42:02 8+inl+T/
>>680

>HDなんて揺らさずに冷やしまくれば10年は壊れない。

常温であれば「冷やす(冷やしまくる)」ことには意味がない。
常温であれば故障率と温度には相関がないからだ。

意図的に振動を与えたり、高温の状態にすることは考慮していない。
あくまでも通常の使用状況を想定している。

つまりHDを揺らさずに冷やしまくれば10年は壊れないなんて保証はどこにもない。
冷やしまくっても、常温に置いておいても、どちらも明日には壊れる可能性がある。
「HDなんて揺らさずに冷やしまくれば10年は壊れない」というのは間違いだ。

ギガジン記事のURL貼ったのはそういう意図だよ。

690:login:Penguin
08/10/04 12:06:48 zXRpQtaU
いい加減
余所のスレでやってくれないか

691:login:Penguin
08/10/04 16:57:03 L5pGcLlF
LVMってUSB外付けHDDも対象にできるんだっけ？

692:login:Penguin
08/10/04 17:45:08 8zxfUkEV
ブロックデバイスなら何でもいいような気がする

693:login:Penguin
08/10/04 20:30:16 51y1fQ9U
>>691
出来るよ。実際に使ってる。

694:login:Penguin
08/10/14 10:07:10 FyQEQmkb
LVM で構成しているHDDの物理的な引越しについて質問。
現在、machine1 に搭載されている4台の SATA な HDD があります。
この4台は、2台ずつLVMが組まれていて、2つのボリュームとして利用されています。
これを、新規に導入する machine2 に、丸ごと引越したい。
現在の machine1 上での組み合わせのまま、machine2 に物理的に搭載し直し、
machine1 の /etc/fstab に書かれている通りの内容を、machine2 の /etc/fstab に記述すれば、
まったく同様に認識されるものでしょうか？
もしそうでないとすると、これらの HDD はどのように物理的に引越せばいいのでしょうか？

695:login:Penguin
08/10/14 10:33:06 vWmjK4Jt
vgexport して vgimport で良いんじゃないの

696:login:Penguin
08/10/14 11:26:32 aEVCml9h
>>694
まったく同様に認識されるから移設すればいいだけ
デバイス名が変わってもLVMが吸収してくれる

697:login:Penguin
08/10/14 11:29:41 aEVCml9h
>>694
Red Hat系ではinitrdを作り直さないと認識しないから注意

698:login:Penguin
08/10/22 18:24:56 mn9zpdol
ストライピングしたい場合、LVMの機能でやるのと、LVM+raidtoolsでやるのではどちらが速いですかね？

699:login:Penguin
08/10/22 22:34:18 OER6wkY9
md/raidtools
餅は餅屋

700:login:Penguin
08/10/23 11:08:42 1XXgMoB4
thx。
あ、でもLVM上にraidtoolsでRAID0した場合って、LVを拡張/縮小したい場合はオンラインで出来るのかな？

701:login:Penguin
08/10/23 11:53:52 EC+7CKjs
raidtoolでつくったらいd0ボリュームの上にlvmボリュームを作るべきではないか

702:login:Penguin
08/10/23 11:56:09 bfBmD8Ku
RAIDとLVMの役割分担を
何か勘違いしてる感じだなw

703:login:Penguin
08/10/23 12:21:25 1XXgMoB4
そっか。順番を逆にしたらいいのか。

704:login:Penguin
08/12/14 00:35:28 UAh/Kl0e
LLVMじゃドライブの一つが欠損したらどうにもならないだろうと思って
RAID1+LLVMの組み合わせを作ろうかなと思ってるんだけど、どうなの？
無駄？

705:login:Penguin
08/12/14 02:04:20 x3iOnWd3
LLVM?

706:login:Penguin
08/12/14 02:08:59 I0d8H/8+
LowLevelVirtualMachine
たぶん誤爆だと思うんだが。でもRAIDが出てきてるしようわからん。

707:login:Penguin
08/12/14 02:43:28 gTU7GUHh
このスレで質問してるんだからLVMのことじゃねーの？

708:login:Penguin
08/12/14 03:16:48 OkP+EP5M
>>704
ごく当たり前に行われている

709:login:Penguin
09/01/28 23:02:45 tUS0opCF
1). /dev/sda1 + /dev/sdb1 とで /dev/mapper/VolGroup00-LogVol00 を、
2). /dev/sdc1 + /dev/sdd1 とで /dev/mapper/VolGroup01-LogVol01 を作成し、

1). をオリジナルとして、2). をバックアップとして、毎日完全に同期させています。

もし仮に 1). に異常が発生したとき、/dev/sda1 と /dev/sdb1 、
つまり /dev/mapper/VolGroup00-LogVol00 を外し、
/dev/sdc1 を /dev/sda1 に、/dev/sdd1 を /dev/sdb1 に繋いで、
/dev/mapper/VolGroup00-LogVol00 とすることはできるんでしょうか？

710:login:Penguin
09/01/28 23:14:46 auWKhnPP
図で頼む

711:login:Penguin
09/01/28 23:18:27 AqwV8nqk
>>709
正直、

　lvm(raid1(sda1,sdc1)) + lvm(raid1(sdb1,sdd1))

でLVM+MD構成にしたほうがよくね？それなら繋ぎ替えとかしなくても
そのまま片肺で動くし。

712:login:Penguin
09/01/29 10:04:25 FT6dwQZ5
>>711
709は、ハード障害よりも、OS/AP/ﾕｰｻﾞ操作によるソフト障害のリカバリーを心配してるのかも

713:login:Penguin
09/01/29 10:14:51 ZQNgMLUN
LogVol01 を LogVol00 にしたいだけなら、単純に lvrename で済んだりしないかな。

あと、 LVM は各 PV を UUID で見てるから、 sdc が sda に変わっても構成は変化しないと思う。

714:login:Penguin
09/01/30 18:26:47 jo26Z68K
dumpでバックアップ用にLVMでsnapshotを作ろうとしたんだけど、
空き容量足りない、みたいにいってくるんだけど、
もしかしたら、HDDの空き容量がないとsnapshotは作られないんでしょうか？

$ sudo lvcreate --snapshot --size=1G --name snap0 /dev/my/home
Insufficient free extents (0) in volume group my: 256 required

って、もしかして >>599-601 と同じ現象でしょうか？

さすがに運用してからリサイズすんのは怖くて無理だなあ orz
運用がひと段落して時間空いたらリサイズすることにするか・・・

715:login:Penguin
09/01/30 18:46:32 pFX4Hfia
FSに割り当ててない空きがないとそりゃ無理だろ

716:login:Penguin
09/01/31 20:59:24 xCSyeJqC
>>715
うん・・・そうだよね。
最初にそれいってよ！ってことなんです orz
LVMの意味ねえ・・・。

717:login:Penguin
09/01/31 21:34:01 xR7C3gwX
RedHatのインストーラはデフォルトだと全領域をロジカルボリュームにしてしまうからな

718:login:Penguin
09/02/01 22:45:38 W8JBndQ5
SUSEもだ

719:login:Penguin
09/02/21 19:03:15 94qX/ymd
LVMって定期的にディスクアクセスする?

なんかカリカリ言うんだよね…

720:login:Penguin
09/02/21 19:53:36 b/h0+KPy
メタデータのタイムスタンプ更新とかじゃね

721:login:Penguin
09/03/02 17:46:54 eMi0mnVL
LVMのパフォーマンスが出ずに困ってます。
ソフトウェアRAID5(SATA500GBx6)のhdparm -tの結果が
/dev/md0:
Timing buffered disk reads: 958 MB in 3.00 seconds = 318.90 MB/sec

このmd0を全領域そのままLVMに割り当てると
/dev/vg01/data:
Timing buffered disk reads: 292 MB in 3.02 seconds = 96.80 MB/sec

こんなもん…？
特にカスタマイズしてないgentooのLVMパッケージそのままなんですが。
Core2Duo(x86-64)、kernel2.6.27です。
チューニング次第でもうちょい速くなるでしょうか。

722:login:Penguin
09/03/05 09:56:55 TF4Gm0YN
lvcreate --contiguous y

723:login:Penguin
09/04/01 15:43:22 B06/PAhd
LVMで構築されてるルートファイルシステムの入ってるディスクを
交換したいんだけど、手順がわからん。

/dev/hda 壊れそうな起動ディスク
/dev/hdd 新しく起動ディスクにするつもりのHDD

/dev/hddにディスクを追加して中身をコピーして、そのあと
/dev/hdaのハードディスクを捨てて、/dev/hddにあったHDDを
/dev/hdaに差し替えて、ここからの手順が不明。
/etc/lvmの下の設定ファイルとかの取り回しもよくわかんね。

724:login:Penguin
09/04/01 16:36:59 N+qA7O0F
やったことないけど、
適当にknoppixとかで立ち上げて
ddして差し替えるんじゃダメなの?

725:login:Penguin
09/04/02 09:47:02 wLO/nTsR
はやいところZFSでもHAMMERでもBtrfsでもいいから標準になってくれたら
md+LVMの上にFS作ってとかいう三重苦から解放されるのに。

726:login:Penguin
09/04/02 10:00:01 iWqzU7Dl
RAID箱買えばいいのに..

727:login:Penguin
09/04/02 12:07:38 AtKG6Evx
RAID箱とかカードとかは予備も含めて買っておかないと痛い思いをするからなぁ。
仕事で使うのならともかく、家で使うような鯖ならそこまではとても…。

728:login:Penguin
09/04/02 12:08:45 DD255WSi
>>726
RAID箱だとLVMやFSが不要になるの?
すごいね。

729:login:Penguin
09/04/02 13:20:25 iWqzU7Dl
字面しか追えないお子様ですか。それとも非ネイティブ？

730:login:Penguin
09/04/02 13:36:02 l22LEMmy
LVMで構成しているHDDからデータを抜き出したいのですが、
誤って論理ボリューム(LV)を削除してしまいました。
復旧させる方法があれば教えてもらえますでしょうか。

731:login:Penguin
09/04/02 20:39:46 KmPuZOah
RAIDとLVMの関係がいまいち分からんかったので実験してみた。

sda1┐
sdb1--md0(RAID1)--pv0--vg0-----lvol0
　　　　　　　　　　　　　　　　　　　└--lvol1

この状態で、sdaを破損させた。
結果は、普通にlvolにアクセス可能だった。
つまり、物理ディスクの故障はRAIDのボリューム(md0)で吸収されて、
その上位のpv～lvolには影響ないって認識でOKなのかね

732:login:Penguin
09/04/02 21:20:57 h+cIIODu
当たり前じゃんww

733:login:Penguin
09/04/03 13:48:55 DfOWQDhR
当たり前じゃんww

734:login:Penguin
09/04/03 14:24:45 xcr1Fpsd
LVMを好んで使っている奴なんているの？

735:login:Penguin
09/04/03 16:11:01 NGrwCixC
731面白いｗ
それダメだったら何のためのRAID1なんだよｗ

736:login:Penguin
09/04/03 22:53:43 KMrkK/Q+
>>734
俺

737:login:Penguin
09/04/05 10:27:00 F2DWFdY2
>>723
難しく考える必要ない。
・/dev/hddをpvとして登録(pvcreate)して
・/dev/hddを既存のvgに追加 (vgextend) して、
・/dev/hdaに含まれているlvをすべて/dev/hddに移動(pvmove)して
　※アンマウント無しで出来る
・/dev/hdaをvgから除去 (vgreduce)
すればおｋ。lvmconfとかいじる必要なし。

URLﾘﾝｸ(www.linux.or.jp)
URLﾘﾝｸ(www.linux.or.jp)

738:731
09/04/06 22:54:42 D6ic0j5B
>>732 >>733 >>735
過去レス見てて、RAIDとLVMの組み合わせが何回か話題になってたけど、いまいち理解できなかったんだよwww
おかげでやっと理解できたよwww

739:login:Penguin
09/04/10 14:53:39 aZl7+NF4
実際に自分で試してみるのは重要だと思う。
いざっと言う時の不安も減るし。

740:login:Penguin
09/04/11 13:51:09 nGoq+PnZ
いざって言うときの話ならZero fillするなりブランクディスクと交換するなりしてちゃんと復帰までできるか試さないと意味がないぞ。

741:login:Penguin
09/06/19 12:17:03 wDgygRt1
LVMで新しくファイルシステム作ったらOSリブートしたほうが良い？

742:login:Penguin
09/06/19 15:41:06 xOpWvKLs
>>741
どんだけおバカさんやねん

743:login:Penguin
09/06/19 15:45:14 xOpWvKLs
>>737
アンマウント無しに安全にpvmove出来るようになったのはつい最近
RHELやCentOSでは未だに出来ないはず

744:login:Penguin
09/06/19 17:09:34 uVS0LrOc
それはそれとして、せめてgrubのinstallはやらんとマズイでしょ。いろいろと。

745:login:Penguin
09/06/20 15:13:58 fz3w6jiH
>>741
Windowsかよｗ

746:login:Penguin
09/06/20 16:01:09 d0+hafqG
いまどきWindowsだって再起動は不要だ。

747:login:Penguin
09/06/20 16:49:20 Wg4IvLcN
再起動が必要なのはWindowsの制限だけじゃないぞ

748:login:Penguin
09/06/20 17:32:40 mLzLCpGE
使用中のディスクのパーティション構成を変更した時は
再起動が必要だったような。LVM関係ないけど

749:login:Penguin
09/06/20 18:59:45 4+KsKEtJ
partprobeぐらい使えよ

750:login:Penguin
09/06/24 19:00:48 BRl/h1nk
新しく論理ボリューム作って
mkfsでフォーマットしたあと
マウントしたら中身消えたんだけど何で？

751:login:Penguin
09/06/24 19:03:20 +50xqMil
アナタニホンゴワカリマスカ

752:login:Penguin
09/06/24 19:05:16 WxeAnTpj
mkfsでフォーマットしたあと

753:login:Penguin
09/06/24 21:06:38 aCF67bw3
携帯から書いたから文章打つの面倒で。どうもすみません。

たとえば
mkdir /test でディレクトリを作成して適当なファイルを作る。
↓
lvcreate で/dev/VolGroup00/LogVol07 作成
↓
mkfs -t ext3 /dev/VolGroup00/LogVol07 でフォーマットしてから
↓
mount /dev/VolGroup00/LogVol07 /test/ で/test をマウント
↓
/test の中身消失。

って事なんだけど・・・・なんでだろ

754:login:Penguin
09/06/24 21:13:18 bBFYdeOy
自分で消してるから。

755:login:Penguin
09/06/24 21:15:59 WxeAnTpj
アンマウントしたら復帰するはず

756:login:Penguin
09/06/24 22:09:23 N8ozJxG8
>>753
馬鹿だから

757:login:Penguin
09/06/24 22:17:21 iXcZm1Nd
/test をマウント

じゃなくて/testにマウントだろ？日本語教えたろか？

758:login:Penguin
09/06/24 22:27:30 N7wYxMR6
>>753
umount /test/
find /test/ -type f -delete

759:login:Penguin
09/06/24 22:48:19 hXip6hlN
>>753
面白い

760:login:Penguin
09/06/24 22:49:20 aCF67bw3
そうか俺が馬鹿だからダメなんだな。

叱咤激励ありがとさん

761:login:Penguin
09/06/25 11:56:58 h89Zn1ea
ネタだと思いたい

762:login:Penguin
09/06/26 23:26:29 HPdCGQPQ
これはひどい

763:login:Penguin
09/07/10 22:43:44 IJ2is51O
スナップショットは取得元と異なるVGに保存することは可能でしょうか？

764:login:Penguin
09/07/11 21:42:06 LFA7ddCW
>>763
どうも不可能っぽい

765:login:Penguin
09/07/15 22:09:41 2C0YOuic
ということは、例えばVG01に登録されているPV=物理ディスクに
何らかの障害が発生し、復旧不可能になると、スナップショットは意味ないの？
別のVGに保存できるなら、元データがふっとんでも、復旧できると思ってました。

766:login:Penguin
09/07/15 22:12:45 J/B7VN8D
扱う問題のレイヤが違う。
コンポーネントデバイス（物理ディスク）の障害はRAIDとかそこらへんの仕事。
LVMはあくまで記憶領域の柔軟な運用が目標

767:login:Penguin
09/07/15 22:57:00 Wh+3Uee4
つか、そもそもスナップショットがどういうものなのか誤解してるぞ。
なぜスナップショット領域が元のデータ領域の 1割とかで済むと思ってる?

スナップショットは「バックアップなどを取るために」ある時点での状態を記録したものだ。
それを対象にdumpなどを使ってテープ等の「他のデバイスに」バックアップするのが使い道。
元のファイルのコピーではなく単なるリンクなんだから
元のディスクが死ねば当然リンク先の本体がなくなる訳で復旧なんか出来るはずがない。

768:login:Penguin
09/07/21 16:16:21 8jOz+2Dy
LVMってなんなのさ？

HDDのストライピングなの？
領域移動が楽なフォーマットって感じのもの？

769:login:Penguin
09/07/21 16:28:31 0g7wYV4c
メリットが明確に理解出来るまで使わなけりゃいい

770:login:Penguin
09/07/21 16:54:27 L4lOTNSh
>768
ぶっちゃけ、ストレージの仮想化の一手段。
まぁ、仮想化と言っても色々なレベルがあるけどな。

771:login:Penguin
09/07/21 17:56:17 ZhQXycai
複数のボリューム（まあHDDと読み替えてok）を束ねて一つの仮想ボリュームと看做せるから、
HDDの増設や追加でいちいちデータを移動したりしなくても、
単一のボリュームに追加で容量を増やして行けるとか、個人レベルでも結構応用が利くのが利点。

単一ファイルでも物理的な配置をストライピングのようにクラスタ単位で複数のHDDに振り分けたりはしないから、
仮にHDDの中の一台があぼーんしても、読み出せなくなるのはあぼーんしたHDDに記録されていたファイルのみ。
そういう意味ではストライピングほど深刻ではない（どれか一台あぼーんしただけでもボリューム全体があぼーん確定）けど、
元々冗長性や安全性を期待して使う類のものではないから注意。

772:login:Penguin
09/07/21 18:43:09 8jOz+2Dy
>>769　あ、いや、そのCentOSで任せるとLVMで作ってくれるので・・・
>>770　なるほどね、HDDの仮想化ね　そう思ったらなんとなくつじつまが合うかもｗ
>>771　あぼーんしたHDDとまだ生きてるHDDで
生きてるHDDをext3とかでmount してファイル救出ですかね？

ちょっとGoogってきます
みなさま㌧ｸｽですた！

773:login:Penguin
09/07/21 22:08:12 sxU3ftvQ
>>771
マジ？片方死んでも生きてるディスク上のデータ助かるの？

774:login:Penguin
09/07/21 22:33:50 CMRpbGOo
データとしては残っててもFSが不整合になるから
サルベージ技術無い限り結局は望み薄

775:login:Penguin
09/07/21 23:37:41 ne/05ljE
ディスク拡張がラク、スナップショット便利てこと以外に利点。
スナップショット不要、さらにアレイコントローラで、物理ディスクをLU(RG)で纏める場合、LVMの必要性がよくわからん。

ディスク追加する際はLUに追加すればいいんじゃないのと思ってみた。
LVMあんま使ったことないから、混乱してきたな。。

776:login:Penguin
09/07/21 23:39:57 ne/05ljE
↑最初の文章おかしいまま、カキコしてしまいました。
利点は二つだという事を言いたいだけです。

777:login:Penguin
09/07/22 10:04:14 iqxl84l9
ｽﾅｯﾎﾟｼｮﾄ取れてもMBRからの復旧ができる？

778:login:Penguin
09/07/22 11:53:41 PJ2Wnixd
>>775
HDDが内蔵の少数の個数とかって運用なら
メリットはほとんどないだろうね。

LVMの実力が本当に発揮されるのは
もっと大規模な運用なときなんだよ。
ボリューム構成の柔軟性が格段に増す、ってのが最大のメリット。
だから >>769 が現実的な答えだと思う。

最近デフォルトでLVMアリにしちゃうディストリが多いようだけど、
正直、デスクトップユーザには面倒が増えるだけで不要だと思う。

779:login:Penguin
09/07/22 12:06:40 kNb8Im68
アレイコントローラなんて持ってないご家庭仕様のファイルサーバで使ってるが
SATAディスクを3つ4つとスケーラブルに増やしていけるから便利だよ。

780:login:Penguin
09/07/22 16:30:51 L9jtOV+v
家庭内ファイルサーバで、どうしても単一のボリュームを増やしたり減らしたりしなきゃいけない
って状況はあまりないのでは? (もちろん絶対にないとは言わんが)
普通は新しく買ってきたHDDを既存のディレクトリ下のどこかにマウントしてやるだけで事足りるし
その方がいろいろ楽だと思う。
前に出てたけど、ドライブ故障のときとかデータ損失の危険が増えるだけじゃね?

781:login:Penguin
09/07/22 17:07:37 kNb8Im68
確かにね。
だから俺はRAID5で組んでるよ。
1TBを4発で実質3TBの単一パーティション。
そしてsambaでSMB共有として使ってるから
Windowsからの容量管理を考えると単一パーティションの方が楽なんだよね。
いちいちサーバ側でマウントポイントごとの容量を確認するのも手間だし、
かと言ってWindows側でドライブレターが複数になるのも煩雑だし。
なるべく安楽にメンテナンスフリーで使いたいと思ったらこうなった。

782:login:Penguin
09/07/22 17:25:43 i0d9v6zl
>780
面倒なのはHDD partition-RAID-LVM-FSの階層手順が深すぎるからだからね。
zfsやbtrfsみたいな階層ブレーカーを使う様になると、HDDはむしろ纏めちゃった
方が楽ってことになるんだけどさ。

783:login:Penguin
09/07/22 17:41:48 L9jtOV+v
先月だかのソフデ誌のZFS特集見て
ええな～と思っただよ。ほんと。
現状だとマウント可能になるまでやること大杉。

ライセンス変更してなんとかLinuxカーネルに
組み込めるようにしてくれんものかな。

784:login:Penguin
09/07/22 18:07:42 i7pHEMGV
ディスク1台のみのデスクトップ用途でも便利。
/homeが足りなくなってきたが/はガラガラなんてことは結構有りがちで、
そういう時に比較的楽にパーティションサイズを調整出来るのが良い。

785:login:Penguin
09/07/23 12:31:13 L4G0kme3
オンラインでリサイズするの怖い。

786:login:Penguin
09/07/23 14:09:46 cxfbehGv
このチキンが！

787:login:Penguin
09/07/23 18:33:16 V0FXlWLo
>>758　やぱ、こえぇよな
>>786　ﾊﾞｸうｐが万全な方でしょうか？

788:login:Penguin
09/07/23 18:34:25 V0FXlWLo
あーｱﾝｶﾐｽｯﾀ orz

×
>>758　やぱ、こえぇよな
>>786　ﾊﾞｸうｐが万全な方でしょうか？

>>785　やぱ、こえぇよな
>>786　ﾊﾞｸうｐが万全な方でしょうか？

つーかバックアップがテープの人っている？

789:login:Penguin
09/07/23 22:54:36 cxfbehGv
>>788
俺はLTO3

790:login:Penguin
09/07/24 09:53:38 s6i8kuK+
やぱ、いらっしゃいますか。。。
高いし、ワカメが怖いし
テープ以外になんかいいのないですかね？

LTO3ならそう簡単にはワカメにならないですか?　>>789

791:login:Penguin
09/07/24 10:32:02 QDLizY3t
ちっとは自分でぐぐれよ

792:login:Penguin
09/07/24 20:26:08 8cFFY/1k
ジャムるってどんな粗悪品だよ
ヘリカルはクソだがね

793:login:Penguin
09/07/25 12:02:23 b0ziyYCL
>>784
そうなんだけど、現状だと

・一番手間がかからない/のみの１パーティション構成にする人が多い
・LVMしても、その後でファイルシステムをリサイズするのを怖がる人が多い

ということでなかなか普及しませんな。

そういう俺もディスク３台程度でLVMはやめとこうとなって、
一番近いLVM的用法なんてVMwareの仮想ディスクをリサイズして
C:\の容量が足りなくなったWindowsのパーティションを拡張したことくらい。
個人用途だと中々LVMの出番が来ない。

会社だとLVM+iSCSIとかでディスク仮想化便利に使ってるけど。

794:login:Penguin
09/07/25 13:02:10 Em2XyEmO
snapshotの為にLVM使ってる。

795:login:Penguin
09/07/25 13:13:56 Wi3Nn4VF
LVMの利用意義がなんとなくわかってきたｗ

>・LVMしても、その後でファイルシステムをリサイズするのを怖がる人が多い
これってもっといい方法ないのですかねぇ

796:login:Penguin
09/07/25 13:20:15 qTghIUgl
>>795
ディスク追加して、ちょいとマウントしてやれば、簡単に増やせるよ！って方式の
「もっといい方法」がLVMだと思ってたんだが、違うの？

797:login:Penguin
09/07/25 13:24:52 Fb3lMXfZ
>795
> これってもっといい方法ないのですかねぇ

そこら辺を改善しているのがzfsやbtrfs。

798:login:Penguin
09/07/25 13:44:24 lzFVun58
LVM使うのが怖い人は、VMWareやVirtualBoxなどの仮想環境でいじり倒して
みるのがおすすめ。

799:login:Penguin
09/07/26 02:25:39 dKQ6FUJz
>>795
パーティション操作ツールの方が便利
DiskDirectorSuiteとかね
それにLVMはディザスタリカバリとか考えると・・・ねぇ
イメージバックアップソフトでLVM対応したものは無い
無理やり取ってもセクタイメージになるからサイズがでっかくなる
システム領域にはLVM使いたくない

800:login:Penguin
09/07/26 08:31:55 Sqf6GSrG
ZFSにしてみるかなｗ

801:login:Penguin
09/07/27 23:30:05 3M/GH2Yd
ディザスタリカバリしたければ DRBD + LVM2 もいいだろう。

802:login:Penguin
09/07/28 02:15:41 s+fkhqn+
ファイルシステムリサイズ恐怖症は一昨年卒業した。

803:login:Penguin
09/07/28 08:39:33 qkh/vCxj
そして慣れたころに油断してファイルシステムごと吹っ飛ばす。
いつしか動いて当然、という気になって、バックアップとか取らないで
やっちゃうんだよね。

804:login:Penguin
09/07/28 14:15:32 cfCC4a3c
HDDを増設したところ従来のHDDのデバイス名がsda → sdbにずれてしまい、
今まで使用していたLVMのVG/PV/LVが認識されなくなってしまいました。
(もちろん新しいHDDを外して、旧HDDをsdaとして起動すれば認識されます)
この場合の「正しい」再認識手順ってのは、どういうものでしょう?

いや、実は最初 pvdisplay やっても全く見えてなかったんですが、
pvchange(使い方がよく分からん)をオプション変えて何度か実行してたら、
全部エラーだったくせに、いつの間にかVG/PVが見えるようになってたもんで。
# その後 lvchange -a y LVパスで正常に使用可能になりました

という訳で、取り敢えず解決はしたけど「正しい手順」が分からないとゆーw
再び同じ状況になったときのために、どなたかご教示ください。

805:login:Penguin
09/07/29 02:10:47 7FiVoOM7
>>804
pvscan
vgscan
lvscan

806:login:Penguin
09/08/11 18:53:33 N8YxJrhg
DVDから最小インストールしたFedora11でvgremoveを使用すると
Volume group "VolGroup" not removed
Command failed with status code 5.
と出力されます
原因としては何が考えられるでしょうか?
心当たりのある方ヒントをお願いします

807:login:Penguin
09/08/11 18:58:02 WK11feHT
>>806
エラーメッセージでggr

808:login:Penguin
09/08/11 20:25:26 N8YxJrhg
ググり方が悪いのかいまいちわからない
よかったら教えてもらえませんか?

809:login:Penguin
09/08/12 11:56:13 rnZGPXwQ
その二行しか出力されないの?
それより前に何行も出てたりしない?

810:login:Penguin
09/08/12 18:59:24 PPhnpZ+s
既存のLinuxサーバに1TB*2のディスクを増設してRAID1を組み、
1TBすべてをLVMの領域としようと考えています。

このときにパーティションを
- 1TBのおおきなパーティションにする
- 500G*2等、分割しておく
の２つでなにか違いがありますか？

全体をLVMにするので最終的には同じなのですが、障害時や運用上、
パフォーマンス上でなにか良い点、悪い点はありますか？

811:login:Penguin
09/08/13 15:48:40 H9Ey2wIe
>>806
自分で踏んでいるから

812:login:Penguin
09/08/13 22:15:23 rZrZs/Jn
LVMって複数のHDDを１つのHDDみたいな感じで扱うって認識でいるけど
複数HDDでLVMを組んだ場合にHDDがどれか１つでも壊れると全滅ってこと？

813:login:Penguin
09/08/13 22:45:58 cLHxYtSX
盛り土した上に高速道路作るみたいだがｗ
PVを跨がないようにLVを作ればよろし

814:812
09/08/14 01:16:19 9/vKw7tC
>>813
ありがとうです。
これってPVとかまたがっている状態でHDDを抜き取ったらダメだけど
逆に抜き取ったHDDからはデータが読めないから盗まれないって解釈でもOKですか？
HDD3個あればRAIDとLVMを組み合わせて抜き取られてもデータが読めず、1個壊れても問題ない
っていうのが作れるんじゃないかと考えております。

815:login:Penguin
09/08/14 01:49:21 iVeb+he4
mdで3玉RAID5とかして、それをPVにするのね
いいんじゃないかね、２玉持って行かれるとアウトだが

816:login:Penguin
09/08/14 02:33:26 0iNIM8VR
1個抜かれるなら2個でも3個でも抜かれるよね？

PVまたがらないでLVつくるってのはPVとVGを1対1対応でつくるてこと？

817:login:Penguin
09/08/14 03:12:44 iVeb+he4
律儀に１玉抜いて帰る泥棒も居ないと思うがｗ
1VGに3PV入ってても、lvcreate時にはPV指定できるから
PV跨がないでLV作成は可能

PV跨いでないならDISKブチ壊れた時でも全部パーにはならないで
何とかなる >>135な人が追試している

818:login:Penguin
09/08/14 11:08:58 FmrgXovH
>>817
RAID5のアレイからそれぞれ1玉ずつ抜いていくのは、
間違いなくプロの犯行ww

819:login:Penguin
09/08/14 15:19:19 q89o8hhF
PEの大きさ決める時って何か基準とか目安みたいなものあるんでしょうか？
小さい方が無駄が少なそうだから4Mとかにしたりしてるんですが。

820:login:Penguin
09/08/14 16:24:32 hqUEOy8y
LV 1つあたりのPEの最大数が65536個と決まってる。
4MBだと最大256GBのボリュームしか作成できない。
従って、TBクラスのボリュームを作成する場合には
64MBとか128MBとかって大きさで作らんと。

参考 URLﾘﾝｸ(pantora.net)

821:login:Penguin
09/08/14 16:27:38 hqUEOy8y
あ、ごめん。
これ LVM1 の話で LVM2 では制限なくなってるっぽい?

ずっと64MBとか指定してたけど、LVM2だともっと小さくていいのか。

822:login:Penguin
09/08/14 16:32:16 hqUEOy8y
自己フォロー

URLﾘﾝｸ(www.ibm.com)
> LVM2 では、PV/LV あたりの最大エクステント数に制限はありません。デフォルトのエクステン
> ト･サイズは 4MB です。エクステント・サイズの大小による入出力パフォーマンスへの影響は
> 一切ないので、ほとんどの構成ではこのデフォルト･サイズを変更する必要はありません。ただ
> し、エクステント数が多いと LVM ツールを使用しにくくなる場合があるので、エクステント・
> サイズを大きくしてエクステント数を抑えることが得策となります。

とのこと。

次ページ