LVM จำเป็นต้องใช้ตารางพาร์ติชันหรือไม่

18

ปรากฏว่าฉันสามารถสร้าง pvcreate ได้สำเร็จบนอุปกรณ์ raw block โดยไม่ต้องทำขั้นตอนการสร้างตารางพาร์ติชัน ฉันสามารถสร้างกลุ่มวอลุ่มโลจิคัลวอลุ่มและในที่สุดก็เป็นระบบไฟล์ติดตั้งและทดสอบผ่าน dd

ดูเหมือนว่าจะใช้งานได้ แต่ฉันต้องมีการตรวจสติ นี่เป็นความคิดที่ไม่ดีเหรอ?

ฉันจะสร้างตารางพาร์ติชัน GPT หรือ MBR ที่ด้านบนของอุปกรณ์บล็อกดิบได้อย่างไร

ฉันจะใช้งานแบบแยกส่วนเพื่อแสดงตารางพาร์ติชันที่ใช้งานอยู่ได้อย่างไร ฉันได้ลองทำ:

แยกให้เลือก / dev / sdb พิมพ์และฉันจะได้รับ:

ข้อผิดพลาด: / dev / sdb: ป้ายกำกับดิสก์ที่ไม่รู้จัก

ยังมีการใช้งานไดรฟ์อยู่ในขณะนี้และฉันสามารถอ่านและเขียนได้ นั่นคือผลลัพธ์ที่คาดหวังเมื่อทำ LVM ที่ด้านบนของอุปกรณ์บล็อกดิบโดยไม่มีตารางพาร์ติชัน ความคิดใด ๆ

ขอบคุณ!

lvm parted

— กางเกงแมว
แหล่งที่มา

29

แม้ว่า LVM เองไม่สนใจเกี่ยวกับการมีพาร์ติชันจริง แต่เหตุผลหนึ่งในการสร้างมันขึ้นมาก็คือการแจ้งโปรแกรมการแบ่งพาร์ติชันว่ามี "บางอย่างที่นั่น" สถานการณ์ฝันร้ายคือระบบดูแลระบบใหม่ที่วินิจฉัยปัญหาการบู๊ตบนเซิร์ฟเวอร์, เริ่มโปรแกรมการแบ่งพาร์ติชัน, เห็นดิสก์ที่ไม่ได้แบ่งพาร์ติชั่นและสรุปว่าไดรฟ์เสียหาย

ฉันไม่เห็นข้อเสียในการสร้างพาร์ติชัน LVM คุณ

— ฟิลิป
แหล่งที่มา

1

+1 สำหรับสถานการณ์ มีโอกาสมากเกินไปในชีวิตจริง

— Hennes

1

+1 สำหรับการมีไหวพริบ

— Alexander Janssen

ขอบคุณสำหรับการตอบกลับ! แน่นอนฉันไม่เห็นข้อเสียของการมีตารางพาร์ติชัน ฉันแค่ต้องการยืนยันด้วยการตรวจสุขภาพ ดังนั้นลำดับที่ถูกต้องของเลเยอร์คือ: อุปกรณ์บล็อก, ตารางพาร์ติชัน, กลุ่มวอลุ่ม, โลจิคัลวอลุ่ม, ระบบไฟล์นั้นถูกต้องหรือไม่?

— กางเกงแมว

8

ข้อเสีย: หากคุณขยายอุปกรณ์บล็อกและไม่ได้ใช้ตารางพาร์ติชันคุณสามารถขยายฟิสิคัลวอลุ่มด้วย pvresize ได้ทันที ถ้าคุณใช้ตารางพาร์ติชันคุณต้องลบพาร์ติชันและสร้างใหม่ด้วยขนาดที่ใหญ่กว่าก่อน

— sciurus

1

การออกกำลังกายด้วยความระมัดระวังเป็นสิ่งที่ดี แต่การส่งคำถามกลับไม่ได้เป็นคำตอบที่ดี ไม่จำเป็นสำหรับพาร์ติชันนี้และมีข้อเสียคือมีพาร์ติชัน

— bryn

16

ในขณะที่คุณสามารถสร้าง pv จากอุปกรณ์ raw block ปกติแล้วฉันพยายามหลีกเลี่ยงมันเนื่องจากอาจทำให้เกิดความสับสนว่าอุปกรณ์บล็อคนั้นถูกใช้งานอย่างไร นอกจากนี้ยังอาจทำให้การค้นพบกิจวัตรอัตโนมัติบางอย่างที่ LVM สามารถใช้ได้หากไม่มีไฟล์การกำหนดค่า

นี่คือตัวอย่างของการใช้การแยกส่วนเพื่อสร้าง GPT ด้วย 1 พาร์ติชันที่เป็นไดรฟ์ทั้งหมดและตั้งค่าสถานะพาร์ติชันเป็น lvm mkpart ต้องการให้คุณระบุระบบไฟล์ แต่ไม่ได้สร้างระบบไฟล์ ดูเหมือนว่าจะเป็นข้อผิดพลาดอันยาวนานในการแยก ออฟเซ็ตเริ่มต้นของ 1M ก็เพื่อให้แน่ใจว่าคุณได้รับการจัดตำแหน่งที่เหมาะสม

parted /dev/sdb
mklabel GPT
mkpart primary ext2 1M 100%
set 1 lvm on

— 3dinfluence
แหล่งที่มา

3

"mkpart ต้องการให้คุณระบุระบบไฟล์ แต่ไม่ได้สร้างระบบไฟล์" ขอบคุณที่พูดถึงสิ่งนี้นั่นเป็นเรื่องใหญ่มากในการสร้างสติ! :)

— กางเกงแมว

1

ไม่เป็นความจริงอีกต่อไป mkpart primary 1M 100%ทำงานและปล่อยให้ฟิลด์ระบบไฟล์ว่างเปล่า

— สิ้นเชิง

1

@ 3dinfluence LVM ตอนนี้จะจัดตำแหน่งโดยอัตโนมัติหลังจากหลายปีที่ผ่านมาฉันไม่เห็นกรณีการใช้งานจริงเพื่อใช้พาร์ทิชันสำหรับดิสก์ข้อมูล dicated สำหรับ LVM

— c4f4t0r

5

หากคุณสร้าง PV โดยตรงบนอุปกรณ์จัดเก็บข้อมูลเสมือนภายในแขกของ KVM คุณจะสังเกตเห็นว่าโลจิคัลวอลุ่มจากผู้เยี่ยมชมสามารถมองเห็นได้บนไฮเปอร์ไวเซอร์ สิ่งนี้อาจทำให้สับสนได้หากคุณใช้ชื่อโลจิคัลวอลุ่มและกลุ่มวอลุ่มเดียวกันกับแขกหลายคน คุณอาจได้รับคำเตือนบางอย่างจากไฮเปอร์ไวเซอร์โดยบอกว่าไม่สามารถหาอุปกรณ์ได้

ตัวอย่างเช่นฉันได้สร้างปัญหานี้ขึ้นใหม่บนไฮเปอร์ไวเซอร์ทดสอบของฉัน:

[root@testhost ~]# vgs
  Couldn't find device with uuid dCaylp-1kvL-syiF-A2bW-NTPP-Ehlb-gtfxZz.
  VG          #PV #LV #SN Attr   VSize   VFree  
  vg_main       2   2   0 wz-pn-  19.25g 768.00m
  vg_main       2   2   0 wz-pn-  19.25g 768.00m
  vg_testhost   1   8   0 wz--n- 237.98g 120.15g

ที่นี่คุณสามารถเห็นกลุ่มวอลุ่ม 2 กลุ่มที่มีชื่อเหมือนกันทั้งจากแขกที่ไม่ควรปรากฏบนไฮเปอร์ไวเซอร์

ด้วยเหตุนี้ฉันขอแนะนำให้คุณใช้พาร์ทิชันหรือ fdisk เพื่อสร้างพาร์ติชัน KVM ที่นั่นก่อน (ดังแสดงในคำตอบก่อนหน้าโดย 3dinfluence) ก่อนสร้าง PV และเพิ่มเข้าไปในกลุ่มวอลุ่ม ด้วยวิธีนี้แขกโลจิคัลวอลุ่มยังคงซ่อนจากไฮเปอร์ไวเซอร์

— Paul Maunders
แหล่งที่มา

1

สิ่งนี้สามารถหลีกเลี่ยงได้หากคุณใช้filterใน /etc/lvm/lvm.conf เพื่อกรองอุปกรณ์บล็อกทั้งหมดที่ใช้โดย VMs ของคุณโดยตรง

— Mircea Vutcovici

ดิสก์จะมีอยู่ในโฮสต์เสมอ - พาร์ติชันไม่ได้ถูกแมป kpartx -aจะทำเพื่อคุณ ไฮเปอร์ไวเซอร์มีการเข้าถึงดิสก์แขกทั้งหมด แต่ไม่ควรเปิดใช้งานกลุ่มวอลุ่ม

— bryn

4

ข้อเสียอย่างหนึ่งคือมันเป็นไปไม่ได้ที่จะเพิ่มพื้นที่ว่างให้กับ PV ภายในตารางพาร์ติชัน นี่ไม่ใช่ปัญหาถ้าคุณใช้อุปกรณ์บล็อกทั้งหมดสำหรับ PV

— user217432
แหล่งที่มา

ตั้งแต่ปี 2018 คุณสามารถเพิ่มพื้นที่บน PV ภายในตารางพาร์ติชัน ฉันสร้างสคริปต์นี้ซึ่งสามารถสร้างคำสั่งที่จำเป็นในการทำเช่นนั้น: github.com/mircea-vutcovici/scripts/blob/master/vol_resize.sh

— Mircea Vutcovici

3

ตามคู่มือ LVM จาก RedHat หัวข้อ 4.2.1 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administr/physvol_admin

พวกเขาบอกว่าไม่จำเป็นต้องมีตารางพาร์ติชั่นพวกเขายังแนะนำให้เราทำลายมันถ้าเราใช้ดิสก์ทั้งหมดสำหรับ VG (กลุ่มวอลุ่ม) เว้นแต่ว่าเราตั้งใจจะรวมเฉพาะบางส่วนเท่านั้น (พาร์ติชัน)

— พิศศรีศรีนวล
แหล่งที่มา

3

แม้ว่าในอดีตที่ผ่านมาฉันใช้ดิสเก็ตดิสก์ MS-DOS หรือดิสเก็ตต์ GPT สำหรับ PV ตอนนี้ฉันต้องการใช้ LVM โดยตรงบนอุปกรณ์บล็อกหลัก ไม่มีเหตุผลที่จะใช้ 2 disklabels ยกเว้นว่าคุณมีกรณีการใช้งานที่เฉพาะเจาะจงมาก (เช่นดิสก์ที่มีบูตเซกเตอร์และพาร์ติชันสำหรับบูต)

ข้อดีของการมี LVM โดยตรงคือ:

ความเรียบง่าย - คุณไม่จำเป็นต้องใช้เครื่องมือ 2 ชุด
ความยืดหยุ่น - คุณสามารถใช้ pvmove เพื่อย้ายข้อมูลจากดิสก์โวลุ่มหนึ่งไปยังอีกไดรฟ์โดยไม่ต้องหยุดทำงานคุณสามารถใช้สแน็ปช็อตและการจัดเตรียมแบบบาง
คุณไม่จำเป็นต้องเรียกใช้ partprobe หรือ kpartx เพื่อบอกเคอร์เนลว่าคุณสร้าง / ปรับขนาด / ลบโวลุ่ม และpartprobe / kpartx อาจล้มเหลวหากมีการใช้งานพาร์ติชั่นและคุณอาจต้องทำการรีบูท
อาจมีประสิทธิภาพที่ดีขึ้นเมื่อเทียบกับการใช้ LVM ที่ด้านบนของ MS-DOS หรือ GPT disklables

— Mircea Vutcovici
แหล่งที่มา

2

ไม่แน่ใจว่าทำไมทุกคนต้องการพาร์ทิชันนั้น - แต่คำตอบที่นี่ไปในทิศทางของ "ทำไมไม่" คำตอบนี้ดีกว่า - คุณไม่จำเป็นต้องใช้พาร์ติชั่นถ้าคุณจะใช้ทั้งดิสก์ การมีพาร์ติชันสามารถทำให้การปรับขนาด / ขยายดิสก์มีความเจ็บปวดมากขึ้น

— bryn

หลายผู้ดูแลระบบยูนิกซ์นำตรรกะนี้เพื่อลินุกซ์ผมจำได้ว่า Veritas ผู้จัดการปริมาณที่ทำงานร่วมกับภาครัฐและเอกชนใน Linux doesn นี้มีความรู้สึกใด ๆ

— c4f4t0r