06/06/30 21:30:39 bt8aI5W+
LVM が
/dev/sda3: 内蔵 SATA、8e → /dev/vg1
/dev/sdb1: 内蔵 SATA、8e → /dev/vg1
/dev/sdc1: 外付 USB(ATA)、8e → /dev/vg2
/dev/sdd1: 外付 USB(ATA)、8e → /dev/vg2
としているとき、内蔵 HDD を単純に 1台増設すると
/dev/sda3: 内蔵 SATA、8e → /dev/vg1 (変更なし)
/dev/sdb1: 内蔵 SATA、8e → /dev/vg1 (変更なし)
/dev/sdc1: 内蔵 SATA、83 (新設。後で vg1 に追加する予定だがひとまず 83 のまま)
/dev/sdd1: 外付 USB(ATA)、8e → /dev/vg2
/dev/sde1: 外付 USB(ATA)、8e → /dev/vg2
と vg2 を構成する外付 USB の順番が 1コずつズレて vg2 がマズい状態になりそうなんですが、
HDD 増設後に vgscan で一発解決できますか？
360:login:Penguin
06/06/30 23:43:50 1bsmmkCt
>>359
再起動すればvgscanも必要ない。
361:359
06/07/01 00:35:05 2s9fKqFU
>>360
ほほぅ、そんなもんですか。だったら気が楽だ。
助かりました。ありがとうございます。
362:359
06/07/02 16:46:58 ebetDEkG
内蔵SATAディスクの増設はサクッと上手く行ったので、調子に乗って
/dev/vg2(3台のATAディスクを積んだ novac 4台はい～るKIT) に
SATAディスクを1台IDE変換コネクタをかませて追加してみたところなぜか認識せず、
vg2 も見失い、困った展開に。
lvscan で探すと vg2 の LV は "inactive" となってデータ自体は生きてるようだったので、
vg2 を作り直し、LV も同名・同サイズ・フォーマットなしで作り直してマウントしてみると、
複数あるうち 1つの LV だけマウントできない。
/etc/lvm/archive/ 中のファイルを見ると、同サイズにしたつもりがマウント失敗 LV が微妙に小さかったことが判明。
vg2 中の全 LV を削除、改めて同名で作り直してマウントしてみると、無事に復活。
失われる前の LV は何度かサイズを拡張したからダメだろうと思いつつやってたんですが、
サイズと名前さえ合ってれば、結構乱暴な扱いをしても OK なんですね。
少々焦ったものの、貴重な体験ができました。
363:login:Penguin
06/07/02 18:54:11 ga9/U/Ul
>>362
乙
参考になりました。
364:login:Penguin
06/07/29 14:26:59 TSQYdC/Y
たくさんのHDDで、RAID使わずLVMのみで構築してる人
結構壊れるもんですか？
・何も考えずにLVMのみで構築
・RAID5組んで、その上でLVM構築
どっちにしよう
後から容量足せるのがいいんだよね
365:login:Penguin
06/07/29 14:31:49 TSQYdC/Y
てゆかスレ止まってるのでage
366:login:Penguin
06/07/29 15:34:35 l49WN+G+
HAになってないDISKにLVMなんてｱﾘｴﾈ-
367:login:Penguin
06/07/29 16:18:38 K2DDu9Rg
>>366
fedoraを否定するにはあまりに分が悪くないでしょうか。
368:login:Penguin
06/07/29 16:51:23 xqKAhYME
スナップショット使っていて、たまたま領域溢れがおきると
それが無効になるだけじゃなくてカーネルパニックになるのは仕様？
カーネルは2.6.17です。
# mount /dev/vg0/p0 /mnt/vg0p0
# lvcreate -s -n p0.snap -L 1 /dev/vg0/p0
# dd if=/dev/zero of=/mnt/vg0p0/big.bin bs=1024 count=8192
# lvremove vg0/p0.snap
<kernel oops>
で 100% パニックになってしまう。マニュアル見ると lvextend で
救えるみたいに書いてあるので、溢れた後で意味あるのかと疑いつつ
# lvextend -L +32M /dev/vg0/p0.snap
# lvchange -ay /dev/vg0/p0.snap
などをしてみたのですが、やはり lvremove でパニックという
結末が避けられません。
十分大きな領域を取るようにする運用である程度回避はできるけど、
うっかり大きな書き込みしたらシステムごと飛ばせるのは怖いので、
パッチや回避策があれば教えて下さい。
369:login:Penguin
06/07/29 16:58:50 18kd3ovo
AIXとかのLVM物理ディスク丸ごとをボリュームグループに追加してるけど
LinuxのLVMだとパーティションをボリュームグループに追加するんだね。
なんか理由があるのかな？
370:login:Penguin
06/07/29 18:35:30 9J5yxANj
パーティションテーブル構造の違いと、
LVMが当たり前になっているAIXやHP-UXでは、物理パーティションを切るメリットが全く無いから
やらないってことじゃないかな？
371:login:Penguin
06/07/29 18:58:31 l49WN+G+
HP-UX@IPFはパーティション切る
EFIのクソッタレ
372:login:Penguin
06/07/29 22:18:25 D7f/oD9K
>>369
おれはもう何年も増設ディスクにパーティション切ってないよ。
LVMでもそうでなくても。
373:login:Penguin
06/07/29 22:26:48 xqKAhYME
>>372
mount /dev/sdb /data とかってこと？漢の切り方ですな。
374:login:Penguin
06/07/29 22:28:32 xqKAhYME
すまん、sageてなかった・・・
375:login:Penguin
06/07/29 23:16:24 bcm1JGhF
>>373
頭大丈夫ですか？
376:login:Penguin
06/07/29 23:25:12 18kd3ovo
>>375
パーティション切らないっていうと俺も>>373みたいなイメージをしてしまうんだけど。。。
377:login:Penguin
06/07/29 23:41:31 ypKIHAUk
領域溢れないのを前提だからねえ。そりゃパニくる。
無効にすればいいと言うけど、アプリケーションからはそんなの理解出来ないし。どう互換性取る？
378:login:Penguin
06/07/30 00:28:39 92rJ+6P6
PVをマウントなんかできねーっつの
379:login:Penguin
06/07/30 00:34:35 bLOnGl/y
>>372はLVMでなくてもパーティション切らずに利用していると言ってるみたいだけど
それはどういう意味なのかが知りたい。
もしかして単にPVにパーティションを１つだけ作成してるという意味なのか？
380:login:Penguin
06/07/30 01:52:59 ARvl2Fmi
全領域を１つのｌｖとして取ってるってことだろ
さて、やっぱバックアップなしのLVMは無謀かな…
HDDケースとかの「コンバイン」と同じだもんなぁ
データ量が多すぎるので複製バックアップは非現実的なんだよな
381:login:Penguin
06/07/30 02:40:26 honuiWv6
>>377
うむむ・・・単にPVの欠乏を検出したらスナップショット側への
書き込みにはENOSPCを返し、ソース側への書き込みについてはスナップ
ショットとの関連付けを最初からなくし、一切スナップショット用PVを
消費しないオプションとかあれば理想的かなーと挙動みて思った。
今すぐどうにかなる話ではないみたいなので対策の話に移ると、
バックアップ用スナップショットってどれくらい領域確保してます？
話では元領域の20-100%確保しろとかあるけれど、読み出し専用な
バックアップ用スナップショットでもそんなに取るものですか？
結局バックアップ所要時間中にどれだけ書くかだからケースバイ
ケースなんだけど、個人利用で300GB HDD中100GBとか食われるのは痛い。
382:login:Penguin
06/07/30 20:21:22 Mx8Fl/aT
>379
ん? mkfs /dev/sda とか pvcreate /dev/sda とか
しててるけど。
383:login:Penguin
06/07/30 21:10:20 bLOnGl/y
>>382
自分で試してみたらできました。
Linuxだからパーティション、AIXだから物理ボリュームとかいう分類は特にないんですね。
AIXとかは大規模システムだからパーティション切る意味がないってだけなんですね。
384:login:Penguin
06/07/30 22:15:50 92rJ+6P6
そのうちx86もEFI使うだろ
385:login:Penguin
06/07/30 23:18:26 +9CxprNK
>>384
怪しくなってきた。
Vistaでx86版もEFI対応の予定がキャンセルされちゃったし。
386:login:Penguin
06/07/30 23:25:52 92rJ+6P6
IA64と共に葬り去ってくれて一向に構わないけどｗ
最近のマカーはEFIっしょ
387:login:Penguin
06/07/31 20:09:00 1rvcY3/L
カーネルにはすでに EFI Support (Experimental) てな感じであるね
肝心のものは市場に出回ってるわけ？
388:login:Penguin
06/07/31 20:24:11 1Tsuyn7I
以前どっかの早漏メーカーが出してた
389:login:Penguin
06/07/31 21:27:57 v1KNHtS2
x86なEFIはIntel MACで搭載済み
390:login:Penguin
06/08/04 11:39:44 3TC8Ado/
zfsがLinuxに移植されたらLVMはなくなると思う。
391:login:Penguin
06/08/04 13:53:06 s5AMUQ9D
zfsがメインになることはありえない。
せいぜい実装できるのは、Solarisで作成したzfs領域に対して読み書きが可能となるくらい。
392:login:Penguin
06/08/04 17:55:20 i6p2sUmz
FUSEで実装してるならまあそうだろうな。
393:login:Penguin
06/08/04 22:11:42 3TC8Ado/
ext3+LVMとzfsを比べると
・物理デバイスを超えたボリューム作成
・信頼性
・スピード
・高可用性
あたりでzfsが有利に見える。
ただ、Solarisにべったりな実装になっていて移植自体が難しい場合は望むべくも無いんだけど。
>>391,392
FUSEかー、ブートはext3なんかのほうが
互換性とこれまでのノウハウの蓄積を考えるといいんだろうけど。
ってか、FUSEだとスピードや信頼性でもともと持ってるポテンシャルを
発揮できない希ガス。
394:login:Penguin
06/08/07 00:39:39 GtH2asAX
lvmを試してます。
OSインストール時に /dev/VolGroup00/LogVol00 を作成しました。
HDDを追加して、fdisk /dev/hdc の/dev/hdc1を
8eで lvmのボリュームを作成しました。
# pvcreate /dev/hdc1
上記コマンドを実行したところ、
Can't open /dev/hdc1 exclusively. Mounted filesystem?
というエラーが発生しました。
なぜ pvcreateできないのでしょうか
OS は cent4.3です。
395:login:Penguin
06/08/07 00:43:52 XI6TJIbe
>>394
mountって打ち込んでみ？
396:login:Penguin
06/08/07 12:36:59 GtH2asAX
>>395さん
# mount
/dev/hda2 on / type ext3 (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/hda1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
/dev/mapper/VolGroup00-LogVol00 on /home type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
上記が表示されました。
/dev/hdc1 は含まれてませんでした。
ちなみに
#mount /dev/hdc1 /mnt
mount: /dev/hdc1 は マウント済か /mnt が使用中です
というエラーになります。
397:login:Penguin
06/08/07 13:24:16 XI6TJIbe
じゃ次は
fuser -v /mnt /dev/hdc1
398:login:Penguin
06/08/07 14:00:39 GtH2asAX
>>397さん
# fuser -v /mnt /dev/hdc1
# fuser -v /dev/hdc1
上記で試しましたが、何も表示されませんでした。
399:login:Penguin
06/08/07 14:51:25 YbuXzI7B
じゃ次は
# dd if=/dev/hdc of=mado --nage
400:login:Penguin
06/08/07 16:12:53 GtH2asAX
dd if=/dev/hdc of=mado --nage
dd: unrecognized option `--nage'
詳しくは `dd --help' を実行して下さい.
と表示されました。
調べましたが、"--nage"というオプションは見つかりませんでした。
401:login:Penguin
06/08/10 02:17:28 oa2uMyiW
お前面白いな
402:login:Penguin
06/08/10 02:41:25 DRx8xrmE
>>400
これで幸せになれるよ
dd if=/dev/zero of=/dev/hda bs=512 count=1
403:login:Penguin
06/08/10 07:36:47 +6NubT9U
Debian(Sarge)＆LVM2なんだけど、
PE指定し忘れたまま550GBのLVを斬ってデータ書き込み、
再起動後にマウントできなくなってしまいました。
こんなエラーが出ます
mount: special device /dev/vg0/data does not exist
（LV名は仮）
vgdisplayすると、550GBのLVは見えます
vgresize（だったっけ）でのサイズ変更はとりあえず成功、250GBに切り直し。
やはりマウントは出来ません。
URLﾘﾝｸ(www.itmedia.co.jp)
ここと攻略本を見てLVM構築したんですが、PE指定、すっかり忘れてたorz
試しにfsck /dev/vg0/dataとやっても、「そのようなファイルやディレクトリはありません」とエラー。
もうこの時点でデータは救えませんかねぇ。。
あとはvgの再構築…
しかしこれやると全部データあぼーんですよね
404:login:Penguin
06/08/10 07:38:53 +6NubT9U
あ、
PVは600GB（640GB）、
VGも同じ
LVは550GB
PEは4MB（ﾃﾞﾌｫ）
です。
本来は255.99GBまでしかLV斬っちゃいけないんですよね
405:login:Penguin
06/08/10 10:39:44 hxxEJfDZ
>>402 さま
おかげさまで直りました。
どうもありがとうございます。
406:login:Penguin
06/08/18 18:14:34 ikn0YhVS
URLﾘﾝｸ(grub.enbug.org)
407:login:Penguin
06/08/22 12:45:52 ktWadiYS
/にマウントしてるLogVol00を15G→5Gに小さくしようとして、
レスキューCDで起動し、
lvm vgchange -a y
resize2fs -p /dev/VolGroup00/LogVol00 5G
lvm lvreduce -L -10G /dev/VolGroup00/LogVol00
と打ち、CDを抜いてrebootしたところ起動時に、
/dev/VolGroup00/LogVol00: The filesystem size (according to the superblock) is 1310720 blocks
The physical size of the device is 1277952 blocks
Either the superblock or the partition table is likely to be corrupt!
/dev/VolGroup00/LogVol00: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e.,without -a or -p options)
*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
*** Warning -- SELinux is active
*** Disabling security enforcement for system recovery.
*** Run 'setenforce 1' to reenable.
Give root passwd for maintenance
というエラーが出てきました。この後rootでログインし、
e2fsch -f /dev/VolGroup00/LogVol00
と打ち、
Error reading block 1277954 (Invalid argument) while doing inode scal. Ignore error<y>?
という問いには全てEnterを押し続けました。
e2fsckが終わったところでrebootしましたがまた同じエラーが出ます。
LV縮小の手順が間違っていたのでしょうか？
408:login:Penguin
06/08/22 12:53:32 MSFbj8Ho
The filesystem size (according to the superblock) is 1310720 blocks
The physical size of the device is 1277952 blocks
これに尽きるんじゃねぇの？
ファイルシステムの方が大きくなってるし。
lv小さくしすぎたんじゃねぇ？
409:407
06/08/22 13:06:19 ktWadiYS
>>408
すいません、自分で書いておきながらそのメッセージを見落としてました。
ジャストサイズで合わせようとしたのがいけなかったですかね。
手順としては
resize2fs -p /dev/VolGroup00/LogVol00 4G ←1G少なく設定
lvm lvreduce -L5G /dev/VolGroup00/LogVol00 ←絶対値で5Gと指定
resize2fs /dev/VolGroup00/LogVol00 ←LogVol00の容量に合わせる
でいいでしょうか？
410:407
06/08/22 13:37:15 ktWadiYS
上記の手順で試したところ成功しました。
>>408氏ありがとうございます。
因みに407な状態になってしまったら復旧することは可能なのでしょうか？
今回はテスト環境だったので問題はなかったのですが。
411:login:Penguin
06/08/28 18:23:16 Qm2KIGHV
良いlvmの参考書ってないの？
412:login:Penguin
06/08/30 21:16:00 EMppbjrW
L inuxで
V olumeを上げたら
M uteになった
ともぞう
413:login:Penguin
06/09/01 01:55:10 +V4to7us
>>411
そんな難しくないと思うけど、LVM HOWTOじゃだめ？
それ見ながらVMwareとかでがんがん挙動確認を兼ねていじってみるのが
いいと思う。
もっともその動作確認で極限状態での挙動が不審なんで怖くなって、
リアル利用はまだ控えてるが・・・
414:login:Penguin
06/09/08 02:43:04 ZNK9r2o4
hdcがLVM で ボリュームグループがVolGroup00としてが一つだけ作られていて、
その中に論理ボリュームがLogVol01の一つだけが
出来ていて、ext3でフォーマットされています。
60％ほど使用している状態です。
これを一つのfatにしたいのですが、
1.LVM内ext3に対応したdefragはありますか？
2.ボリュームグループのサイズを変更することは出来ますか？
よろしくお願いします。
415:login:Penguin
06/09/08 03:06:24 EaO4bLDZ
WindowsはLVMの中のFATファイルシステムをアクセス出来ないと思うが？
416:414
06/09/08 08:54:44 t89DwNuf
LVMのサイズを減らしてFATパーティションを作る
ファイルをコピー。
またVLM内の論理ドライブ内のext3のdefragとresize、論理ドライブのdefragとresize、LVMのdefragとresize。
fatパーティションの拡大
417:414
06/09/08 08:57:11 t89DwNuf
1、LVMのサイズを減らしてFATパーティションを作る
2、ext3からfatにファイルをコピー。
3、VLM内の論理ドライブ内のext3のdefragとresize、論理ドライブのdefragとresize、LVMのdefragとresize。
4、fatパーティションの拡大
5、2からを繰り返し
とやりたいんです
418:login:Penguin
06/09/08 12:42:23 EaO4bLDZ
増設ディスク買ってきて繋げ。おまえにゃ無理。
419:414
06/09/10 03:42:58 WmrMnAO9
URLﾘﾝｸ(pantora.net)
を参考にして ext3の縮小とLVの縮小は出来たのですが
system-config-lvmでパーティションを見ると
ぶつ切れでLVも魅しようスペースもある。
ブツ切れだからなのか論理ビューでの「新しいボリュームの作成」も効かない。
418は対処方法解ってるのならコマンドだけでも教えてくれるとうれしい。
増設ディスクのが楽なのは解ってるが、出来ればこれで何とかしたい。
LVMを一発で普通のext3とかに変更できたりするのだろうか？
420:login:Penguin
06/09/13 05:41:52 QbuQIyy7
バックアップさえ取ればいくらでも好きなように弄って試せると思う。
ハードディスク増設しちゃうのが金で解決で簡単だけどな。
421:login:Penguin
06/09/13 08:00:56 tZ69K+tZ
Time is Money.
422:login:Penguin
06/09/13 17:33:10 Xmrz1r6n
skill is Money.
423:login:Penguin
06/09/14 09:31:47 /BE0hgr7
Skill is Monky!
424:login:Penguin
06/09/14 09:55:48 cafxdNt0
Money is skill.
425:login:Penguin
06/09/14 12:08:00 GgbU7PK9
Time goes by.
426:login:Penguin
06/09/14 13:38:44 CUW9kQ6n
All your base is belong to us.
427:login:Penguin
06/09/20 23:37:09 6BRbwmHO
LVMで作成されたボリュームのマウントについて教えて下さい。
FC3をインストールして使っていたHDDが有るのですが、
この中のデータを読み書きしたくて別のLinuxのマシンのhdcポートに繋ごうと思います
対象のディスクは１パーティション？で作って有り
/dev/mapper/VolGroup00-LogVo00 /
に成っています
LVMでない場合は mount /dev/hdc1 /mnt/xxx
等でOKだと思うのですがLVMの場合はどのようになるのでしょうか？
書籍なども色々見たのですがLVMボリュームのマウント方法が分かりませんでした
LVMは複数のボリュームを繋ぎ合わせて使用する仕組みなので下手に１部分だけマウントされるとまずいかなと危惧しています。
428:login:Penguin
06/09/21 00:06:27 yvq2ZBoB
まず元のOSでデポートしないとだめ。
その後、新OSでクリアインポートする。
429:login:Penguin
06/09/21 00:14:19 inLqedFm
>>427
LVMをサポートしてるシステムなら繋ぐだけで認識して
/dev/VolGroup00/LogVol00
などが出来るはず。
ボリュームグループ名が重複してると駄目だけど。
>>428
そんな事は必要無い。
430:login:Penguin
06/09/21 00:23:09 oYkHcFJt
>>429
有り難うございます。
>ボリュームグループ名が重複してると駄目だけど
全く同じ構成でインストールしたディスクですので、まさに重複してます、
やりたい事はトラブったディスクを動いてるLinuxにマウントして
内容をちょっと補修して元に戻して機動しようと思ったのですが、、
ちょっと工夫が要りそうですね
全てのマシンがLVM使ったデフォでインストールしてるのでグループ名全部同じです...orz
431:login:Penguin
06/09/21 00:28:33 inLqedFm
>>430
レスキューCDなどで起動してlvm vgrename で変名するんだ。
インストーラがデフォルトで常に同じVG名を付けるのはあまりにも不親切だと思う。
思うならパッチ送れと言われそうだが。
432:login:Penguin
06/09/21 00:38:34 oYkHcFJt
>>431
>レスキューCDなどで起動してlvm vgrename で変名するんだ。
有り難うございます、
しかし、安物サーバ仕様なのでＣＤがついてない、、orz
あした取りあえずext3でインストしたディスク持ってきてそれを親にしてやってみます。
これからはインスト時にはVG名を全て変えるようにします、
しかしそうすると管理用の自作スクリプトとかマシン毎に全部書き換えが必要かな、
結構面倒ですねLVMって
433:login:Penguin
06/09/21 00:59:32 inLqedFm
スクリプトではデバイス名を使わず
極力ボリュームラベルやUUIDやマウントポイントで管理するといい。
434:login:Penguin
06/09/21 22:54:28 7K79Wfwz
lvm2のchanglogにはこうある。
* Thu Apr 20 2006 Alasdair Kergon <agk@redhat.com> - 2.02.04-1.0
- New release upstream, including better handling of duplicated VG names.
435:login:Penguin
06/09/24 11:51:03 Zk/lDJT/
Storage Foundation for Linux
って4.1から新しいの出てないけれども、あんまり使われてないの？
436:login:Penguin
06/09/24 19:20:12 +L5JNLMa
veritasが必要になるほどのクリティカルな場面ではｌinuxが使われないから。
437:login:Penguin
06/09/25 01:28:44 6TS6HcDh
>>436
VERITASのLinux対応にやる気がないから。
438:login:Penguin
06/09/25 11:14:46 9knmjZAy
まぁ、veritasいなくても生きてけるし。
439:login:Penguin
06/09/26 12:55:06 MMig26yF
Linux と VxFS の組合せってやたら遅くて使えなかった。
440:login:Penguin
06/10/11 15:42:31 w+0Ut2+I
あれぇ？
作ったはずのVGやLVがシステムをリブートしたら消えちゃった。
ちなみにｵｲﾗはLFSでudevdな人です。
441:login:Penguin
06/10/11 22:45:09 1/ePARRw
夢を見てたんですよ、きっと。
442:login:Penguin
06/10/29 00:03:23 ZTP3SZnn
LVM2でlvcreateやvgchange -ayすると/dev/mapper/の下にデバイスファイルが自動で出来るんですが、
これのownerやgroupやpermissionをあらかじめ設定する方法ってありますか？
443:login:Penguin
06/10/31 11:05:45 6oZjJImq
URLﾘﾝｸ(www.linuxjournal.com)
URLﾘﾝｸ(rio.st)
俺用メモ
444:login:Penguin
06/11/12 23:26:27 ieFinVmQ
RHEL4U4をデフォルトのままインストールした後、
LVMのVGNameやLVNameが気に入らないので変えてみたんだが、
起動中、元の名前でマウントしようとして止ってしまう。
どこかの設定に元の名前を覚えてるっぽいんだが、
正しい変更手順てあるの？
445:login:Penguin
06/11/13 00:20:26 DtKUgmIq
>>444
レスキューCDで起動して変更すると共にinitrdを作りなおす。
446:login:Penguin
06/11/15 09:06:40 FmEvhveD
LVMを試していた際エラーが出てしまい、どうしたら良いか分からず困ってます。(Linux s390)
/dev/dasdc (約2.5Ｇ）をdasdfmtでフォーマットした後
fdasdで3つ（各500M)にパーティションを切りました。
------------------------------- tracks -------------------------------
Device start end length Id System
/dev/dasdc1 2 10667 10666 1 Linux Raid
/dev/dasdc2 10668 21333 10666 2 Linux Raid
/dev/dasdc3 21334 31999 10666 3 Linux native
32000 50069 18070 unused
partition tableを保存して終了しようとしたところ下記のようなエラーが出ました。
fdasd error: IOCTL error
Error while rereading partition table.
Please reboot!
もう一度fdasdでパーティションテーブルを見てみると
正しく表示されていたのでfdasd errorに対しては何もせず
# pvcreate /dev/dasdc3
上記のコマンドを実行してみたところ
"Device /dev/dasdc3 not found." と表示されます。
fdasd error(IOCTL error)の解決法もしくは何故/dev/dasdc3が認識されないのか
お知恵を拝借させていただきたく書き込みしました。長くなってしまい申し訳ありません。
447:login:Penguin
06/11/15 21:51:46 JBx+bP3i
Please reboot!
448:446
06/11/17 13:21:49 GQ4FRfhc
>447
rebootしたら直りました。しっかりエラーで忠告されていたのにお恥ずかしい。
ありがとうございました。
449:login:Penguin
06/11/19 01:22:27 foeXuT5h
>>446
s390でLinux運用してるような奴がここで質問南なんかするなよ、、、。
IちゃんのSEは最近何やってるの？
450:login:Penguin
06/12/02 03:23:43 5H4vnv91
LVMの運用考えているんですが、
HDDの繋ぐ位置を変えて、たとえば /dev/sda が /dev/sdb
になったりしてもデータ壊れたりしないですかね？
ルートは非LVMでの運用を考えているので起動には
影響ないんですが。
ちなみにこういう場合はどうやって復旧させれば
良いのですか？
451:login:Penguin
06/12/02 13:00:17 5H4vnv91
過去ログ読むと、まだまだ不安定そうですね。
複数のHDDをつなげてテラバイトのLV作ろうと思ってたのですが
やっぱ普通のext3で運用するのが適当かな・・。
452:login:Penguin
06/12/02 15:08:11 hDUZpZbY
うちは3TのLV作っているけど特に問題はないな
もうすでに枯れてきている技術だとおもうが
どこを見て不安定だと思ったのか？
453:login:Penguin
06/12/02 15:09:57 XO8VyELM
まず名前がだめだな extの方がいけてるぜ
454:login:Penguin
06/12/02 16:10:54 5H4vnv91
>>452
なんか3台のうちの一部が壊れたときとか
復旧した実績がないみたいなので・・。
LVM HOW-TOだとできるみたいな感じで書いてはあるんだけれど。
455:login:Penguin
06/12/02 16:50:46 kzjFlxSY
>>454
つか、RAIDじゃないんだから、一部壊れたらフツーおしまい。
456:login:Penguin
06/12/02 22:24:16 eQc2JRBC
LinuxではソフトウェアRAIDの品質が悪いので、エンタープライズ用途では
必ずハードウェアRAIDを使えといわれました。本当？
457:login:Penguin
06/12/02 22:37:37 gCRA9JZT
RAID総合スレッド No2
ｽﾚﾘﾝｸ(linux板)
458:login:Penguin
06/12/02 22:49:27 JUv9m8vq
まあ、本当。
整合性とか安定性とかだけじゃなく、故障ディスクの入れ換えもえらく面倒だった（3年以上前の経験なので今は改善されているかも）。
SolarisのDiskSuite（LVM）は、LVMとしての機能はちょー貧弱だけど、
ソフトウェアRAIDとしてはさすがによくできている。
459:login:Penguin
06/12/03 02:28:25 18r037ES
SolarisのSVMでトラブった経験は無いけど。
460:login:Penguin
06/12/03 12:59:20 tXqR4jsK
LVMってバックアップのとりやすさがうｒじゃないの？
461:login:Penguin
06/12/04 00:44:32 PEKo/YR5
過去ログ見ると、Kernel 2.6.9ではsnapshotはやめといた方がよい？
462:login:Penguin
06/12/04 07:48:00 73bxYoAu
>>460 SVMだとmetaofflineでミラー切り離してバックアップ。
463:login:Penguin
06/12/04 09:44:53 JHet0fUL
>>462
それ自体はすごく便利な機能なんだけど、最近はSVMはシステムディスクのミラー化くらいにしか使われんからなぁ。
464:login:Penguin
06/12/04 21:06:47 73bxYoAu
最近のSunサーバはハードウェアRAID積むようになってきたからSVMも不要になる日は近い。
加えて、近い将来ZFSがrootファイルシステムをサポートするようになった日には。。。
465:login:Penguin
06/12/09 03:29:47 EBN5bRDP
ZFSあればそもそもLVMいらね
466:login:Penguin
06/12/09 21:53:37 6srhV/6+
最近居着いてるZFS厨はお前か。
残念ながら味方は居らぬようだぞ。
467:login:Penguin
06/12/10 01:46:43 tyXcoLby
味方というか、近いうちにはリリースされないのは明白だから放置状態なだけだろ
468:login:Penguin
07/01/18 09:49:40 OQ5FlAlV
badblocks の -n オプションは具体的にどういう原理で
非破壊的な検査をしているのでしょうか？
読み出しオンリーのときに badblocks が必要とするメモリを x とすると、
破壊的読み書きによる検査の時には 2x
非破壊的読み書きによる検査の時には 3x
のメモリが必要になるということなので、
元の情報をメモリに保持しておいて破壊的な読み書きによる検査をした後
元の情報を欠き戻すという動作をしているように思えるのですが、
この場合やはり badblocks 実行中に電源が吹っ飛んでしまったりすると
元の内容は失われてしまいますよね？
まぁ badblocks をかけるのはたいてい何も記録していない
ディスクとかだろうと思うので問題はないのかもしれませんが。
469:login:Penguin
07/02/13 23:17:55 1S/FhvJ/
ｽﾚﾘﾝｸ(mac板:64-66番) によると
LVM,セキュアOS,Xenは目糞鼻糞な技術だそうです
470:login:Penguin
07/02/13 23:32:05 WSnRQ6Pg
目糞でも鼻糞でも役に立つならそれでいいじゃない
471:login:Penguin
07/02/13 23:34:24 veakA3NE
Macに実装されたとたんにマンセーしだすに１ﾍﾟｿ
472:login:Penguin
07/02/14 01:20:54 PUSkSyv8
/usr LVMに置き換えたよ記念。
最初からもっと大きくしときゃよかったorz
homeはnfsなので当分大丈夫かな。
473:login:Penguin
07/02/14 10:18:23 MJJeb0Jw
ほちゅ
474:login:Penguin
07/02/21 17:51:23 GEUl/Slj
LVM2でpvsとかlvsとかvgsって入れたときに出てくるAttrのところの意味がわかんない
どこかにまとめページない？
475:login:Penguin
07/02/21 18:09:47 Cx7Ly8SD
man attr
476:login:Penguin
07/03/11 00:10:56 ukEOg9KI
Sarge 2.4.27にlvm2が入っております
PVはmd5とmd6とsdi5という構成です
500GBのmd6デバイスをVGから外すため、
新たに500GBのHDDをpvcreate→vgextendまで完了しました。
これでpvmoveで新HDDへデータ移行しようという段階ですが、
いざpvmove /dev/md6すると
mirror: Required device-mapper target(s) not detected in your kernel
というエラーが出ます。
このエラー文を具具って見たところ、
/etc/modulesに dm_snapshot を追加して
# update-modulesしる
と出てたのでやってみたが状況変わらずです
もちろんvgdisplayでNOT availableを確認済みです
URLﾘﾝｸ(www.itmedia.co.jp)
ここ見て作業してるんだけど、この環境はすんなり行ってるorz
もう止まった・・何をすればいいんだ。。
ﾎﾞｽｹﾃ…
477:login:Penguin
07/03/11 00:11:29 ukEOg9KI
すみませんかなり過疎っぽいのでageます
478:login:Penguin
07/04/07 20:50:11 GOSiQcrK
LVMの完全解説本は出ないのかなぁ。
479:login:Penguin
07/04/08 01:35:33 3IlYmNEr
LVM+mdすげー便利。
いちいちLVMパーティション切らなくてもmdの上でlv作れるし。
mdadmのgrowでディスク追加しまくれるし、PVもそのままgrowできるし。
LVM+md+VMwareで愛用してます。
480:login:Penguin
07/04/09 23:09:10 OjYqpEl9
>>478
HP-UXの本とかホームページでも見れば？
481:その１
07/04/23 23:12:04 TAtKd+oU
(1/3)
古いHDDからデータがサルベージできなくなりました。
助けてください。。。
RedHat9で運用していたサーバのHDDを増設した。
SCSIハードディスクだけだったサーバに、IDEハードディスクを増設した。
増設したHDD(/dev/hda)に、Vine 4.1をインストールし、
BIOS設定の起動順序をIDE優先にした。
RH9(kernel2.4)では、/dev/sda2と/dev/sda6をlvm1にて、
ひとつのVGにまとめ、そこに、ひとつのLVを作って
/homeにマウントしていた。（/dev/vg01/lv_data）
482:その１
07/04/23 23:12:35 TAtKd+oU
(2/3)
新しくインストールしたVine(kernel2.6)起動後、
/dev/vg01/lv_dataが見えないので、
pvscan/vgscan/lvscanを実施したがlvm1だと警告が出て、
期待通りマウントできなかった。
明日の朝までにHDD増設を完了させなければならない案件だったので、
よく調べず、焦って、なにをトチ狂ったか、pvcreate/vgcreate/lvcreateを
/dev/sda2、/dev/sda6に実施し、/dev/vg01/lv_dataを作成した。
LVは作成できたが、mount -t ext3 /dev/vg01/lv_data /mnt/temp
してみると、ファイルシステムが正しくない旨のエラーが現れた。
（エラーメッセージはメモっておらず詳細不明）
483:その１
07/04/23 23:13:44 TAtKd+oU
(3/3)
BIOS設定の起動順序をSCSI優先に戻し、RH9環境に戻そうとしたが、
FSをマウントできない旨のエラーがでてRH9も起動しなくなった。
調べてみると、kernel2.6でlvm2に変わっていて、
vgconvertをすれば良かった事が判明した。
とんでもないことをやらかしてしまったことに気づいた。
orz... ←今ここ。
pvcreate/vgcreate/lvcreateは実施したものの、
ファイルシステムの作成はしていないので、
壊れた（上書きされた）のは、LVMの管理情報だけで、
実データは、まだ/dev/sdaに残っているはず。
なんとかサルベージしたい。。。
何卒お助けを。・・・もうだめです。
484:login:Penguin
07/04/23 23:40:20 hxiP9Yh0
古いシステムのバックアップは無いの？
/etc/lvm/の下にメタデータのASCIIテキストのバックアップがあるよ。
485:その１
07/04/24 00:43:51 TkXAc5rB
>>484
バックアップは無いんです。。
/etc/lvm/の下は明日、さっそく確認してみます。
ありがとうございます。
486:login:Penguin
07/05/19 16:21:03 FBnX1/62
>>485は復活できたかな？
やっぱ複雑だと恐いね。
ふつーにext3だけで運用していれば、他のパソコンに
くっつけてすぐマウントも簡単だし。
487:login:Penguin
07/05/28 07:59:18 JVkG/VZ5
定期バックアップにスナップショットを使おうかと考えているので質問。
ジャーナリングなfsを載せたLVのスナップショットを取るときって、
fsをアクティブに使っている状態のままlvcreateしてもいいんかな。
それともumountとかreadonly mountとかしてからの方がいい?
488:login:Penguin
07/05/28 15:52:24 AoSYt1Xv
要件次第だけど、umountできるならした方がいい。
umountしなくてもlockできるなら、それでもいいけど。
489:login:Penguin
07/08/10 18:35:44 dBMj30OW
LVM2のスナップショットは不安定という過去ログがあるが
現在はどうなんだろうか？
490:login:Penguin
07/08/10 18:58:30 /z8b1l8u
大して進歩してないでしょ。
期待もされてないし。
491:login:Penguin
07/08/11 16:32:47 S+h83dfI
LVM2ってパーティションテーブルIDを0x8eにしなくても
問題ないらしいけど、大丈夫なのかな？
なんか誤って削除してしまわないように0x8eで運用
してるんだけれど。
LVM2はどうやって認識してんだろう？
492:login:Penguin
07/08/11 17:13:29 9PYy2GpA
全てのブロックデバイスをスキャンしてLVMのシグニチャ探すので問題ない。
そもそもRAIDデバイス上にLVMを構築する時などIDに頼れない場合もあるから。
しかし、可能なら8eにしてLVMだとわかるようにしておくべきだとは思う。
493:login:Penguin
07/08/11 17:51:39 S+h83dfI
lvreduce を使う前にLV上のファイルシステム(ext3)を小さくしないと
ダメなんですよね？ 最初にファイルシステムを小さくしないと
dataをlostするとか怖いこと書いてあるし。
で、最初にresize2fsを実行しました。
# resize2fs -p /dev/vg00/lv00 16457728K
Resizing the filesystem on /dev/vg00/lv00 to 4114432 (4k) blocks.
The filesystem on /dev/vg00/lv00 is now 4114432 blocks long.
次のlvreduceを実行
# lvreduce --size 16457728K /dev/vg00/lv00
WARNING: Reducing active logical volume to 15.70 GB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce lv00? [y/n]: y
Reducing logical volume lv00 to 15.70 GB
Logical volume lv00 successfully resized
↑これで問題ないのかな？ メッセージ怖すぎだぜ。
データ入ってたら中止してくれ。
494:login:Penguin
07/08/11 17:59:58 S+h83dfI
(続き)
実は今回のテストは hdb1(15.7GB), hdb2(15.7GB), hdb3(24.51GB)の
PVを使っていたLVをhda1のPV上だけに移動したいと思って
実行しました。実行結果を見ると、下記のようになっていて
hdb3の一部に移動されているようです。lvcreate時にPVを指定して
LVを作れるようですが、それ以外でPVを指定した変更動作はできないのかな。
--- Physical volume ---
PV Name /dev/hdb1
Total PE 4018
Free PE 4018
Allocated PE 0
--- Physical volume ---
PV Name /dev/hdb2
Total PE 4018
Free PE 4018
Allocated PE 0
--- Physical volume ---
PV Name /dev/hdb3
Total PE 6273
Free PE 2255
Allocated PE 4018
↑hdb3に4018を割り当てている。hdb1に割り当てれば過不足無いのに！w
だいたいreduceしたら、後ろを削るもんじゃないの～？
495:login:Penguin
07/08/11 18:00:29 S+h83dfI
>>492
なるほど。thx。
496:login:Penguin
07/08/11 20:16:50 9PYy2GpA
>>494
pvmoveで特定のPVに移動できる。
以前はmount中にpvmoveすると固まった。今は確認してないけど。
497:login:Penguin
07/08/11 22:39:10 S+h83dfI
>>496
thx。
マウント中に処理する予定は無いです。
でも動かないならマウント中はエラー返して欲しいですね。
ところで１つのVG中に複数のLVがあったときに
LVがどのPVを使ってるかって、表示できるんですっけ？
vgdisplay -v やってみたが、関係までは分からない
ようですが。
498:login:Penguin
07/08/12 00:43:42 1FLa+W/M
>>497
lvdisplay -m
499:login:Penguin
07/08/12 19:01:12 TaVGrKuf
>>497
LVMからしてみれば、ファイルシステムなんて知ったこっちゃないし。
500:login:Penguin
07/08/19 23:15:15 T6S2sCgB
512GBのVGに512GBを追加して、
1TBのLVを作ろうとしています。
PVの追加はできたのですが、lvextend ができない。
◆ vgdisplay -v
VG Size 931.52 GB
PE Size 4.00 MB
Total PE 238468
Alloc PE / Size 119234 / 465.76 GB
Free PE / Size 119234 / 465.76 GB
※ 119234のFree PEアリ。
◆ lvextend -l+5000 /dev/vg01/lv01
Extending logical volume lv01 to 485.29 GB
Insufficient free space: 124234 extents needed, but only 119234 available
availableが何故か 119234しかない。-l+119234 でも同じです。
PEサイズはデフォルトですがLVM2(SuSE10.2 / kernel2.6)なので関係ないですよね？
何が原因でしょうか？
501:login:Penguin
07/08/19 23:54:42 T6S2sCgB
結局、LVをremoveして、作り直しました。
その前にPEを64MBにしましたが、lvextend失敗に変化無し。
lvcreate で1TBを指定した場合、問題なく
作成されました。
でもextendできないと不便だなぁ・・。
502:login:Penguin
07/08/20 00:00:34 kH0aJAtz
Semper avarus eget
503:login:Penguin
07/08/20 12:50:52 9YNRh3lY
>何が原因でしょうか？
RTFM
504:login:Penguin
07/08/22 00:43:09 VSzDj+IC
-lと-Lは違うのだよおっさん
505:login:Penguin
07/09/02 00:04:10 9jcT6cwh
バグみたいよ。
506:login:Penguin
07/10/08 02:43:03 noXEAedN
/dev/hdb1をpvとしてvg1を作っていたのですが、
いきなり物理的に繋ぎ変えてhdb1からhdd1にしたら
認識しなくなっちゃいますか？
507:login:Penguin
07/10/08 07:49:33 bgwXsIR/
PVに当てられた固有IDで認識してるから、デバイス名には依存しない
つまり大丈夫ってことさ
508:login:Penguin
07/10/08 14:35:28 noXEAedN
>>507
ありがとうございます。何事もないように認識しました。
509:login:Penguin
07/10/09 17:26:27 CR7wiDCr
>>507
LVMに/を配置しているディスクhdaからddでsdaにディスクコピーしてgrub周りを書き換えましたが、
sdaで起動すると/マウント中にカーネルパニックが起きます。(hdaは取り外し済)
レスキューモードではマウントできるんですが、どうすれば起動できるようになりますか？
510:login:Penguin
07/10/09 17:37:31 dupuTztZ
dd？ なんでpvmove使わなかったの
511:login:Penguin
07/10/09 21:43:02 gFNRvPVM
LVMなんて使わずcp -acがお似合いだと言ってやれ
512:login:Penguin
07/10/10 02:38:16 LDDKpBnL
>>505
一月遅れであれだが、
URLﾘﾝｸ(search.luky.org)
の件やね。
513:login:Penguin
07/10/13 00:05:08 l6GyC4t8
何台も同じパーティション構成のサーバを作るときって、今俺はLVM使ってないので、
予め作っといたパーティションテーブルの情報をsfdiskにぶち込んでパーティションを
切らせてたんだが、LVMで似たようなことをやろうとした時に楽にやれる方法ってある?
pvcreateとかvgcreateとかlvcreateとかをタラタラ流すスクリプト作るしかない?
514:login:Penguin
07/10/17 12:01:13 6v2jXhkm
>>513
1台作ったら、ddでメタデータをコピーすればいいんでない？
515:login:Penguin
07/10/25 11:17:23 4uCOppUn
LVMって複数のHDDにまたがって構築したとき、どれか一台でも故障すると、
全体が壊れて読み出せなくなるんだよね?
つまりLVMはRAID上に構築するのが大前提ですか?
516:login:Penguin
07/10/25 11:29:15 xk5fq29w
>>515
RAIDだって２台同時に死ねばいっしょ。
運用による。
壊れそうなHDDの予兆を察知してディスクを交換するか、
LVMの下のレイヤーで冗長性を確保する。
517:login:Penguin
07/10/25 11:55:52 D3bEYjzi
ストレージを使っていればLVMだけでいいけど、
内蔵とか単なる外付けディスクで組む場合は、RAID併用を考慮しないとね。
VxVMやZFSなんかはLVMとSoftwareRAIDの両方を兼ねているけど。
518:login:Penguin
07/10/25 15:04:00 Lgcv7leu
壊れてないディスクからも読み出せなくなるのか。。。
ファイル単位で記録してるわけじゃないから仕方無いかな。
519:login:Penguin
07/10/25 16:14:04 mZNLZbQp
>>518
ただし残るファイルもあるがな。
だが、250Gのディスクが吹っ飛んだとしたら250G以上の被害があるのは確実
そこは理解して使おう
ま、RAIDのJBODするよりは柔軟性があるってだけ
520:login:Penguin
07/10/25 16:14:41 mZNLZbQp
書いてから気づいたがRAIDのJBODて言い方は語弊があるな
521:login:Penguin
07/10/25 20:29:55 xk5fq29w
RAID0には違和感は感じないの？
522:login:Penguin
07/10/26 13:15:57 2kfwd15n
俺は、冗長度ゼロのディスクアレイなので1台故障したら全滅、
と解釈している。
523:login:Penguin
07/10/26 14:33:04 E+EQY5Mq
ファイルが不必要にディスクをまたがないような仕組みにしたら
ある程度軽減できるんじゃないかな。
524:login:Penguin
07/10/26 16:18:56 k8++Xzzr
それリニアモードじゃね？
525:login:Penguin
07/10/26 16:31:49 ICp0Nr8Q
リニアとかコンカチ（ネイト）とかいろいろ呼び方があるんだな。
526:login:Penguin
07/10/27 10:26:16 tpLgCQ0c
んーRAID5の/dev/md0をまるごとLVMで切って使ってるけど。
527:login:Penguin
07/11/10 17:50:37 75KqCEgM
fdisk -lの結果が実態とズレてて困ってるんだが、
こういうのってどうやったら修正できる？
Device Boot Start End Blocks Id System
/dev/sda1 * 1 12749 102400000 7 HPFS/NTFS
/dev/sda2 12750 12761 96390 83 Linux
/dev/sda3 12762 30401 141693300 8e Linux LVM
/dev/sda1は Linux LVMなのだが。
528:527
07/11/10 18:06:30 75KqCEgM
自己解決しました。微妙にスレ違いでした。
529:login:Penguin
07/11/20 01:30:54 jEvbITJ+
ハードウェア板からきました。
Linux の SoftRaid で インストール時にRAID1を組みました。
md0 -> /boot
md1 -> PV (/, swap)
この後md2 (RAID1)を追加で作成して上のmd1のVGに追加した後、
lv / を拡張しました。拡張して領域も増えてうまく行ったんですが、
再起動したら、/ が無いとか言われて Kernel Panicになります。
この場合どうしたらよいのか、またなぜそうなるのかがよくわかりません。
SoftRAIDを組んでない場合は / の拡張はうまく行くのですが・・・
よろしくお願いします。
530:login:Penguin
07/11/20 02:31:13 JgF19cQw
mkinitrdし直した？
531:login:Penguin
07/11/20 08:17:38 jEvbITJ+
>>530
し直してないです。
532:login:Penguin
07/11/20 08:20:33 FQmr64dD
>>531
聞いている側はそんなレス期待してない
そういうときは言われたことをやってから、その結果を答えるもんだ
533:login:Penguin
07/11/20 14:48:10 rmTyWI1j
>>530
>>532
ありがとうございました。
mkinitrd でうまく行きました。
オリジナルのイメージファイルから起動するとやはりカーネルパニックに
なりましたが、mkinitrd で作成しなおしたイメージから正常に起動できました。
534:login:Penguin
07/11/26 21:44:37 aR8zYa9e
Vine 3.2でLVMを入れようと思ったのですが、Howtoなど読みながらいろいろと
試行錯誤しているうちに妙な状態(消したはずのVGが認識されたり)になってしまいました。
一旦全部消してゼロからやり直そうと思い、apt-get remove lvmの後 /etc/lvm*を削除したのですが、
その後 fdiskからやり直すと、前回の設定がどこかに残ってしまっているようで、VGが既にある、と認識されてしまいます。
/etc/lvm* 以外に、どのファイルを削除すればスッピン状態に戻ってくれるのでしょうか?
535:login:Penguin
07/11/26 21:50:45 asrSmFuw
dd if=/dev/zero of=/dev/hd** とかで一旦ディスクをまっさらにしてみては？
pvscan が多分勝手に PV を見つけてくれちゃってるせいではないかと。
536:login:Penguin
07/11/26 21:57:57 kqJnnjsh
いや、そういうときはpvremoveを使うのが本式だろう
しかしfdiskしてるのに何でVGを検出するんだろな
537:534
07/11/26 22:43:44 aR8zYa9e
ファイルシステムからは見えない場所に情報が書き込まれている、ということでしょうか?
(vgscan すると、「前回作ったVG名」の内容で /etc/lvmtab.d/ および lvmtab か作られてしまいます)
なお、Vine 3.2 の LVMにはなぜか pvremove コマンドが入っていません。
/sbin で ls pv* すると出てくるのは以下のものだけです。
pvchange pvcreate pvdata pvdisplay pvmove pvscan
ちなみに LVM のバージョンは lvm-1.0.3-19vl1 となっています。
だいぶ古いですね。そのせいでしょうか。
538:login:Penguin
07/11/26 23:19:48 kqJnnjsh
lvm2じゃないのか…
適当なアドバイスですまんかった
539:login:Penguin
07/11/27 02:02:02 TK2aPOw7
fdiskしても同じサイズアロケートしたら前の情報丸々残ってるんじゃ･･･
わかりにくい例だけど
windowsでクイックフォーマットしても、復旧ツールで直せるのと同じだと思うよ。
540:login:Penguin
07/11/27 14:09:00 PE+7IEYU
initngってLVMに対応しました？
541:534
07/11/27 17:07:34 kwFAlWL3
>>539
なるほど。
ということで、一旦fdisk で先頭から数百MB程度の小さいパーティションを作り、これをext2で
フォーマットをかけた後、再度 fdisk で前回よりも少しだけ小さい LVM領域を確保しました。
この状態で vgscan を掛けたところ、今回は VGは検出されませんでした。
ところが、pvcreate -> vgcreate と進んだところで、前回と同じ VG名を指定したところ
「そのVG名は既に使われている、他のを指定しろ」と蹴られてしまいます。
前回だけでなく、これまでテストとかで使った VG名は全部残っているようです。
続いて ddでゼロ埋めしてみましたが、やはり過去の VG名は消えてくれません。
(もちろん vgremove を行おうとしても、「そんな VGねーよ」となります)
こうなるとLVM領域とは別の場所(システム側)に情報が保存されているとしか思えません。
ここで最初に戻ってしまうのですが、/etc/lvm* 以外に LVMの設定が保存されているファイル
というのは存在しないのでしょうか?
/etc 内のファイルは一通り grep してみたのですが、VG名が書き込まれているものはなさそうです。
/proc/lvmにもなさそうですし。(このディレクトリはapt-get remove した際、一度消えてました)
542:login:Penguin
07/11/27 17:11:28 4HpV7mg9
lvm2なら/etc/lvm配下だけなんだが…
/varとかに作ってるのかなぁ…
543:534
07/11/28 20:52:14 L0IMODeH
結局Vineを現行の4.1に upgradeして LVM2入れたところ、何の問題もなく設定できました。
LVM1でのトラブルの原因も解決法も分かりませんが、取り敢えずはヨシということで。
特に問題も出てないのにOSのメジャーバージョンアップって、余計な手間が掛かりそうで腰が引けてたんですが、
結果からいえば LVM1であれこれ苦労した時間を考えると、さっさと upgradeしときゃよかったっつー感じですw
お騒がせいたしました。
544:534
07/11/29 22:06:57 yTYjvc/A
連日申し訳ありませんが、引き続き質問です。
昨日は意図的に小さめのLVMボリュームを作成し、今日はそれを拡張するテストをしました。
(1)昨日余らせたHDDの空間を fdiskで LVM用に確保 (仮に /dev/hdb2 とします)
(2)そこにPV作成 → pvcreate /dev/hdb2
(3)昨日のVGを拡張 (VG名を仮に VG_1 とします) → vgextend VG_1 /dev/hdb2
と、ここまでは特に問題なく意図通りに進んだことを vgdisplay にて確認しました。
現在は
VG Name VG_1
VG Size 838.00 GB
Alloc PE / Size 6128 / 766.00 GB
Free PE / Size 576 / 72.00 GB
という状態です。
しかし次に LV(仮に LV_1 とします)の拡張を行おうとするとうまく行きません。
lvextend -L 838.0G /dev/VG_1/LV_1
lvextend -L +72.0G /dev/VG_1/LV_1
lvextend -l +576 /dev/VG_1/LV_1
どの指定方法でも
Insufficient free space: 6704 extents needed, but only 576 available
と表示され、拡張されません(766GBのまま)。
何がマズいのでしょう?
545:login:Penguin
07/11/29 22:48:29 choThEVO
>>544
man lvextend
をよく読め。
まぁ、意図したい操作をするのに一番いいのは
lvextend -l +100%FREE /dev/VG_1/LV_1
かな
546:login:Penguin
07/11/29 22:49:25 choThEVO
あとサイズの指定に小数点の数値は使えなかった気がするな。
547:534
07/11/30 04:03:15 XRlfEnID
>>545
もちろん man lvextendは散々読んだのですが……
-l, --extents [+]LogicalExtentsNumber[%{VG|LV|FREE}]
Extend or set the logical volume size in units of logical extents. With the + sign the value
is added to the actual size of the logical volume and without it, the value is taken as an
absolute one. The number can also be expressed as a percentage of the total space in the
Volume Group with the suffix %VG or relative to the existing size of the Logical Volume with
the suffix %LV or as a percentage of the remaining free space in the Volume Group with the
suffix %FREE.
-l, --extents [+]LEの数 [%{VG|LV|FREE}]
LVのサイズをLEユニットのサイズで拡張、もしくは設定する。+をつけると現在の LVのサイズの増分、
+がなければ値は(LVのサイズの)値そのものになる。また、末尾に%LVを付けると数値はVG全体中のパー
センテージを表し、%FREEを付ければVGの残りのフリーな空間のパーセンテージを表す。
-L, --size [+]LogicalVolumeSize[kKmMgGtT]
Extend or set the logical volume size in units in units of megabytes. A size suffix of M for
megabytes, G for gigabytes or T for terabytes is optional. With the + sign the value is
added to the actual size of the logical volume and without it, the value is taken as an abso-
lute one.
-L, --size [+]LVのサイズ[kKmMgGtT]
LVのサイズをメガバイト単位で拡張、もしくは設定する。数値の末尾にMを付けることでメガバイト、G
ではギガバイト、Tではテラバイトをそれぞれ表すこともできる。+記号を付けるとLVの現在のサイズか
らの増分を、なければ(LVのサイズの)値そのものになる。
"actual size"を「現在のサイズ」と解釈しましたが、これが間違っていますでしょうか?
548:534
07/11/30 04:04:21 XRlfEnID
いろいろぐぐって見たのですが、上記の解釈と矛盾するものは見つかりませんでした。
例えば URLﾘﾝｸ(www.docs.hp.com)
> 論理ボリュームの論理エクステント数を 100 に増加します。
>
> lvextend -l 100 /dev/vg01/lvol3
>
> 論理ボリュームのサイズを 400MB に増加します。
>
> lvextend -L 400 /dev/vg01/lvol4
論理エクステント(LE)の数というのは、物理エクステント(PE)の価と同じだと理解している
のですが、違うのでしょうか?
> lvextend -l +100%FREE /dev/VG_1/LV_1
> かな
前述の解釈が正しいならば、+0%FREEになりそうですが、違うのでしょうか。
また、%を付けないスタイルでの正しい指定方法はどうなるのでしょうか?
ちなみに、小数点以下は付けても付けなくても同じ結果でした。
549:534
07/11/30 04:14:11 XRlfEnID
>>547
あ、すいません。
訂正です。
-Lオプションでの%VGと%LVがゴチャマゼになっちゃってますね。
末尾に%VGを付けるとVG全体中でのパーセンテージを、%LVを付けると存在するLVに対する比率を表す
550:534
07/11/30 04:35:07 XRlfEnID
再度すみません。
remaining の解釈を間違っていました。
a percentage of the remaining free space in the Volume Group with the suffix %FREE
というのは「現在残っているVG中のフリーな空間」でのパーセンテージなのですね。
作業後に残る分ではなく。
従って -L +100%FREE は ADD 100% of the current FREE space の意味だと理解しました。
どうもありがとうございます。
あまり使う機会はないかもしれませんが、バイト数での正しい指定方法も教えて頂けるとありがたいです。
551:login:Penguin
07/11/30 08:19:54 PbsH8r35
>>550
× -L +100%FREE
○ -l +100%FREE
バイト数での正しい指定ってmanに書いてあるじゃないか…
-L [+]LVのサイズ[kKmMgGtT]
てか、うまく行かないなら小さい数字で少しずつ大きくしてみて
確かめればいいじゃん？(使用してなければ)拡張縮小思いのままなんだしさ
めんどいからちゃんと調べてはないけど、vgdisplayで出てくる数値は
読みやすいように丸められてるように思う。
だからlvextendでそのまま指定してもうまくいかない、と思う。
vgdisplay --units b
とかで見てみたらどう？
552:534
07/11/30 12:20:33 XRlfEnID
>>551
失礼。typoでした。
実は>>547-550は問題のPCとは別の場所から書き込んでました。
先ほど実機の方で試してみたところ、結果としてはダメでした。
-l +100%FREE
-l 100%VG
-L 838G
-L 838.0G
-L +72G
-L +72.0G
改めて全部試しましたが、前と同じですべて
> Extending logical volume LV_1 to 838.00 GB
> Insufficient free space: 6704 extents needed, but only 576 available
と出てしまいます。
1行目の内容(と2行目がすべて同じ数値であること)から察するに、どの指定方法も「正しい」ように思えます。
問題は何か別の原因?????
>>544の手順で、何か間違いがあるのでしょうか?
少なくとも、「空いてる空間を100%使え」あるいは「存在するVGを100%使え」と指定しているにも関わらず、
free spaceが不足している、というのは通常はありえないと思うのですが。
(空き容量がゼロだ、という表示になるならばまだ分かりますが)
553:login:Penguin
07/11/30 12:33:57 heZ0YSeF
Vineだから
554:534
07/11/30 12:47:10 XRlfEnID
> めんどいからちゃんと調べてはないけど、vgdisplayで出てくる数値は
> 読みやすいように丸められてるように思う。
というのは確かなのですが、-Lオプションがそもそも「メガバイト単位で指定」
なので、「丸められた数値」での指定が正しいはずでは。
ちなみに vgdisplay --unit bで表示される数値は
> VG Size 899795648512 B
> PE Size 134217728 B
> Total PE 6704
> Alloc PE / Size 6128 / 822486237184 B
> Free PE / Size 576 / 77309411328 B
となりますが、lvextend で「バイト単位での指定」を行う方法が存在しません。
最小単位が「キロバイト」です。
そもそもLVMが管理する最小単位はバイトではなくPE or LEであるはずです。
555:534
07/11/30 12:50:18 XRlfEnID
ということで、LEの数を直接指定してみました。(まだやっていなかった)
-l 6704
-l +576
全く同じ表示でした。
> Insufficient free space: 6704 extents needed, but only 576 available
6704が「増分」とみなされてしまうのならば、と
-l 576
も試してみましたが、これだと
> New size given (576 extents) not larger than existing size (6128 extents)
> lvextend: Add space to a logical volume
と、「本来の正しい」エラーメッセージが出てきます。
もうお手上げです。
556:login:Penguin
07/11/30 12:50:33 PbsH8r35
>>552
だから単位の丸め方に違いがあるんじゃないかなって見解示したじゃん
本当は837.99999GBくらいだけど、838.00GBって表示しちゃうのかも。ということ。
！！！憶測でしかないから本当はどうか知らんがな！！！
で、ワークアラウンドとして、小さい量から積み重ねて増やす。
10Gずつとか。何回かやって、そのたびにvgdisplayで残りを確認。
完全にFree PEが0になったら積み重ねた量を足し算してみればいいと思う。
一気に増やすも少しずつ増やすも一緒だ。
557:534
07/11/30 17:33:33 XRlfEnID
>>556
仰ることは分からないでもないですが、>>552に書いたとおり、
-l +100%FREE
-l 100%VG
というパーセンテージの指定方法でもまったく同じエラーメッセージが出る
という点から考えて問題点は別にある(指定サイズの大小ではない)のは明らかと思われます。
と、書くと「やってもみないで」と言われそう wですので、
一応 -L +1K と最小の指定で実行してみましたが、結果はやはり
> Insufficient free space: 6129 extents needed, but only 576 available
となります。
(もちろん実際の最小の増分は1Kバイトではなく、PEのサイズになりますので、
実質 -l +1と同じ指定になります)
>>553の通り、Vine 依存の問題なのでしょうかねぇ……
本来はこんなに手間がかかる作業ではないんでしょうけど。
困りました。
558:534
07/11/30 19:13:33 XRlfEnID
実のところ、Vine依存のトラブルというよりは
根本的に LVMボリューム拡張の手順を間違えている
という可能性の方が高いような気がしているのですが。
実際に何度も拡張を経験している方の目から見て
>>544の手順というのは正しいのでしょうか?
559:login:Penguin
07/11/30 19:19:58 heZ0YSeF
>>558
>>512あたりを嫁
560:534
07/11/30 20:38:57 XRlfEnID
>>559
なるほど。
リンク先記事では複数HDDとなってますが、実際は複数PVを含む LVは全部 NGなのですね。
(最初の一つ分のPV以上のサイズにできない)
これじゃなんのための LVMか分かりませんね。
(縮小はできるけど、やっぱり主用途は拡張でしょうから)
しかし、もう 4ヶ月も前の投稿なのに、まだアップデートされてないってのが……
Vineなワケですかw
取り敢えず原因が分かりました。
どうもありがとうございました。
561:login:Penguin
07/11/30 22:35:07 PbsH8r35
わけわかんね、Vine腐ってるんじゃないの？
もうそんなディストリ投げ捨てろ
って書こうとして自粛してたのだが、本当に腐ってたのかよｗ
562:login:Penguin
07/12/07 20:25:25 0Todx2Do
lvm2 Build Date: 2007年12月01日
Dﾀﾝ..
563:login:Penguin
07/12/30 03:47:41 GnmabIoz
lvm2ってミラーリング(Mirror/UXのlvcreate -mみたいな)とかストライピングできるようになった？
clvmってやつがRHEL4up4でクラスタ化ボリュームミラーリングとか書いてあったからもしかしたら
できるようになったのかなー？
URLﾘﾝｸ(www.jp.redhat.com)
564:login:Penguin
07/12/30 14:48:22 kD6wUebp
あれ？
ミラーリングはすでにできてたんじゃなかったっけ？
ストライピングは無理だけど。
565:login:Penguin
08/01/01 01:06:02 k+j/wHVO
2.6カーネル下でのsnapshotって安定して使えるようになった？
566:login:Penguin
08/01/01 08:11:57 B56glK3n
2.6.19 あたりは安定していた。
最近のはいまいち。
567:login:Penguin
08/01/19 17:42:04 M8Nmbs0I
>>407にもあるように
/dev/VolGroup00/LogVol00: The filesystem size (according to the superblock) is 1310720 blocks
The physical size of the device is 1277952 blocks
Either the superblock or the partition table is likely to be corrupt!
/dev/VolGroup00/LogVol00: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e.,without -a or -p options)
このようになってしまった場合の解決策ありませんか？(´･ω･｀)
physizal sizeの縮小に対して filesystem sizeの縮小がおこなえていないことが原因なのはわかるのですが
具体的にどこで設定できるのかがここ数日挑戦しても解決できません。
どなたかアドバイスいただけませんか(つд⊂)
568:login:Penguin
08/01/21 14:32:19 CLm+aD3F
ファイルシステムをまず小さくしてからLVを小さくしなきゃダメ
そもそも小さくできるファイルシステムは限られてる。確か、
ファイルシステム標準のツールで小さくできるのはReiserだけで、
GNU parted で ext[23] も小さくできる、んだっけかな？
いずれにしても壊れてしまってるものは運良く復元できるかも
しれないしダメかもしれない。
569:login:Penguin
08/01/21 20:06:22 0424Edot
CentOS4.6で
SCSI device sdf: 20507805696 512-byte hdwr sectors (10499997 MB)
こんなディスクをつけたんだけど、pvcreateすると、
PV Size 9.55 TB / not usable 1.00 MB
なんて言われる。0.5TBはどこへ行った？
570:login:Penguin
08/01/21 20:22:40 0424Edot
20507805696*512/1024/1024/1024/1024=9.5497
すまね。
あまりの天使の取り分の多さに気が動転してたようだ。
571:login:Penguin
08/01/21 21:51:29 C2nM2YT+
>>568
ext2,ext3はe2fsprogs付属のresize2fsで小さくできるよ。
作業ミスが怖いからGNU Partedを使ったほうがいいけど‥
572:login:Penguin
08/01/21 22:00:50 y073FPoP
partedは最近の拡張に追い付いてこれてるか？
573:567
08/01/22 05:35:38 KvGSt0M/
レスありがとうございます！
resize2fsを試してみたのですが
resize2fs: Can't read an block bitmap while trying to resize /dev/XXX
とでてしまい次へすすめませんでした。
また、GNU partedというヒントから検索してみたところ
/**ファイルシステム総合スレ その1**/
ｽﾚﾘﾝｸ(linux板)
こちらの640～647の下りで似たようなケースを発見しました。
上記のケースではMBMの区画エディタにて復旧できたそうです。が
残念ながら、肝心の区画エディタO&Oのoodlinuxなるソフトウェアの公開が停止しているようで
試すことができませんでした。orz
万策つきた感じでしょうか（T-T
574:567
08/01/22 05:43:25 KvGSt0M/
O&O Defrag Linux BETAはベータで開発中止、ボツったそうです・・・。
575:567
08/01/22 06:33:11 KvGSt0M/
すいません、深夜作業でテンパってたみたいです。
上記のケースではMBMの区画エディタを利用したわけですね。
休憩後チャレンジしてみます：）
576:567
08/01/22 07:55:09 KvGSt0M/
MBM区画エディタではect3閲覧できずorz
577:login:Penguin
08/01/22 12:03:32 yiAXiNME
MBMに区画の中を見る能力なんてない
あんたのスキルじゃあまりに無茶だろ、その作業は、正直
578:login:Penguin
08/01/23 09:17:27 lfCjtbY5
LVMにMBM無意味だし
もう諦めろよ
579:567
08/01/23 09:52:59 FgvqTTFZ
あきらめずにKNOPPIXから
vgchage,e2fsck,resize2fs,lvextend,lvreduceを駆使して、
もとのphysical sizeに戻し正常な状態になんとかもどせました。
お世話様でした。m(__)m
580:login:Penguin
08/01/23 11:33:50 6pJ/x7kZ
良かったな
581:login:Penguin
08/02/02 17:34:16 Sk+gOLYe
manみたかんじだと-mと-iでミラーもストライピングもできるってかいてあるんだが
ちゃんと使えるならmdadmとかのraid0、raid1、raid10とは機能的にかぶるよね、どっちが良いんだろ？
clusterlvmでも-mと-i使えるんだろうか？
raid5とraid6も使えるようになればlvmだけでよくなりそうやね
582:login:Penguin
08/02/02 21:42:55 hWODtnUX
VxVM化するのか。
バグも同じように増えていくんだろうなｗ
583:login:Penguin
08/02/07 02:19:17 hSH8lz3u
RAID総合スレでも同じような話題が出ているな。
っていうか内部で raid5 とかやっちゃうと、不良HDDがでたときに、
pvmove で健康なHDDに寄せるということができなくなっちゃうんじゃないの?
あ、raid5 だから、一台とりかえてリビルドすればいいのか。
なんか頭がこんがらがってきた。
584:login:Penguin
08/02/07 02:47:04 MhI2GJBO
くだ質だったらすみません。
LVM で2個イチにまとめた 500GBx2 のボリュームを2つ使っています。
具体的には /dev/hda と /dev/hdb で /VolGroup00、
/dev/hdc と /dev/hdd で /VolGroup01 を作成しています。
前者を /home に割り当て、後者をそのバックアップ /home_backup にしています。
ここで疑問なのですが、LVM を構成するHDDの一つに障害が発生した場合、
その LVM をバラして各 HDD の内容を救出する、というようなことは可能なのでしょうか
いま現在は上述どおりバックアップも取っているのでまだいいのですが、
いずれは VolGroup00 側の HDD も VolGroup01 側の HDD も故障すると思うので、
そういう事態がないとは言い切れません。
どうなんでしょうか？
やはり LVM をバラすとそのドライブは読めなくなってしまうのでしょうか。
585:login:Penguin
08/02/07 03:34:36 wkwo0mxs
「lvm 故障 復旧」でぐぐってみれば?
情報はいっぱい出てくるよ。
586:login:Penguin
08/02/07 08:32:32 PJ0xyyBI
>>584
>>149～あたりの話かな？
587:login:Penguin
08/02/07 10:29:17 j9YRu0Ee
どうもありがとうございます。
>>148-156 の大作ですね ←自分のメモ用です。すみません。
ちょっとじっくり読ませていただきたいと思います。
588:login:Penguin
08/03/04 23:11:07 K8yPdd7W
くだらねぇ...。
で相手にさらなかった（長文すぎて）ので質問させてください。
勉強不足なのはわかってますので、ご容赦を。眠くてかなり思考力おちてます。
ぶっちゃけた話、FC4でLVM組んでますが、/dev/hda2に/dev/VolGroup00/LogVol0[01]があったとして、
そのVGとLGを消してしまった場合、元に戻す方法ってありますか？
/dev/hda2の中にboot以外とswapのみはいってました。（=LV00,LV01)
最悪LVMでなくても普通のファイルシステムとしてマウントできる方法とかないのでしょうか？
LVMの管理情報が消えたときって中身のデータ自体は無事ですよね？
全くバックアップをとってないのというのはあきれてますが、頼まれたら嫌とはいえない性格ですので。
かなりこまってます。
申し訳ないですが、分かる方ヒントのみで結構ですので、お教えください。
589:login:Penguin
08/03/04 23:29:41 f138xmmP
FC4を捨ててから出直してこい
590:login:Penguin
08/03/05 02:36:07 HWfQXJWF
まず寝ろ
591:login:Penguin
08/03/05 08:51:14 W53eNevY
ないんじゃね？
592:login:Penguin
08/03/05 09:16:46 V8HqIqNE
>>588
dd if=/dev/hda2 bs=512 count=255 skip=1 | strings
これで何も見えなかったら諦めれ。
593:login:Penguin
08/03/08 16:44:17 tl0WRxQT
>>592
レス有り難う。つД｀)･ﾟ･｡･ﾟﾟ･*:.｡..｡.:*･ﾟ
ちなみに古いPV,LVはのこってない。
ちゅうか、痕跡もなかったです。
で、馬犬 目 ぽ..._〆(ﾟ▽ﾟ*)、データレスキューの会社に頼みましょうっていったら、
じゃ、そうしてって...。
最初からプロにまかせりゃはやいっていってるのに。
本当に(;´ρ`) ｸﾞｯﾀﾘ でした。
本当、こんな訳わからんことにレスしてくれて有り難う。
もっと精進します。
594:login:Penguin
08/03/08 18:01:09 OXyuHSqg
SUSE 9から10にあげたんだ。
LVMは1のままだったんだ。
スナップショットとったらLVM関係がうごかねーんだ。
リブートしたらはんぐなんだ。
うわー。
595:login:Penguin
08/03/12 20:33:22 7jQsVz/g
最近やっとLVMの意味がわかった
しかしまぁ・・・・いまさらHDをいじるのが怖いｗ
OS入れ替えのときにLVMにしてみます
596:login:Penguin
08/03/15 07:00:20 5C7unTpW
>>594
いい事いうじゃねえか。
で、やれるんだな？
今すぐ頼むぞ。
597:login:Penguin
08/03/24 17:48:52 xks+NIrR
>>595
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
俺