ข้อดีของระบบไฟล์แบบไม่แบ่งพาร์ติชัน

39

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

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

filesystems partition lvm

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

Oracle VM ก็ทำเช่นนี้เช่นกันสำหรับ "ที่เก็บข้อมูลในเครื่อง"

— นิลส์

3

ฉันคิดถึงคำถามนี้และเริ่มหนึ่งใหม่ซึ่งครอบคลุมพื้นดินเดียวกัน: unix.stackexchange.com/q/52389/4801 คำถามนี้ถูกปิดไปแล้ว แต่คำตอบบางข้ออาจมีประโยชน์สำหรับผู้อ่านคำถามนี้และอาจรวมอยู่ในที่นี่ด้วย

— dubiousjim

1

... และอีกอันหนึ่งที่unix.stackexchange.com/questions/206141/…

— derobert

แต่ผลงานที่นำไปสู่ปัญหาที่จะจบลงด้วยการสูญเสียเวลาตามที่แสดงไว้ที่นี่ - access.redhat.com/documentation/en-us/red_hat_enterprise_linux/...

— slm

24

Pro: คุณไม่ต้องเสียเซกเตอร์ของดิสก์หนึ่งอันในตารางพาร์ติชัน (เย้.)

Pro: ดิสก์สามารถใช้ในระบบปฏิบัติการที่ไม่รองรับพาร์ทิชันสไตล์พีซี (เหมือนคุณกำลังจะใช้)

คอนดิชั่น: นี่เป็นเรื่องผิดปกติและอาจสร้างความสับสนร่วม - ร่วม (ดู?)

คอนดิชั่น: ถ้าคุณติดตั้งระบบปฏิบัติการอื่น, มันอาจคิดว่าดิสก์นั้นมีขยะและทำให้มันง่ายที่จะเขียนทับมันโดยไม่ตั้งใจโดยการเลือกดิสก์ผิด - ในขณะที่ระบบปฏิบัติการมักจะทิ้งพาร์ติชั่นที่ไม่เข้าใจชนิด

ไม่เกี่ยวข้อง: การขยายระบบแฟ้มไม่ใช่เรื่องง่ายถ้ามันอยู่บนดิสก์โดยตรงมากกว่าในพาร์ติชันหรือในทางกลับกัน (การใช้ LVM จะทำให้ง่ายขึ้น)

สรุป: ใช้งานได้ แต่ไม่ใช่ความคิดที่ดี

— Gilles 'หยุดความชั่วร้าย'
แหล่งที่มา

2

ความสับสนอ่า! ขณะนี้เครื่องมือวัดภายในของฉันกำลังโน้มตัวไปยัง "การพยายามเพิ่มประสิทธิภาพที่เข้าใจผิด"

— sysadmin1138

6

con อื่น: ทำให้ยากต่อการแบ่งพาร์ติชันในภายหลัง

— Kim

3

มาข้ามนี้superuser Q & Aซึ่งมีตัวอย่างที่ดีบางอย่างใช้hexdumpและodซึ่งจะแสดงในแง่ที่เป็นรูปธรรมมากสิ่งที่เกิดขึ้นกับ/dev/sdaVS .. /dev/sda1การติดตั้ง

— slm

4

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

— psusi

2

ในสภาพแวดล้อมที่ไม่ใช่เชิงพาณิชย์การติดตั้งระบบปฏิบัติการอื่นอาจมีความเกี่ยวข้อง - แต่ใครที่ multiboots ใน env เชิงพาณิชย์? ฉันถูกรบกวนว่านี่เป็นคำตอบที่ยอมรับได้ ไม่มีอะไรผิดปกติกับมันยกเว้นว่ามันเป็นความเห็น ฉันอยู่ในรั้วเกี่ยวกับการใช้ดิสก์พาร์ติชัน แต่เหตุผลที่ดีบางอย่างได้รับด้านล่าง

— Graham Nicholls

18

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

อีกหลายเหตุผลที่กล่าวถึงที่นี่:

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools

สรุป: มันใช้งานได้และอาจเป็นความคิดที่ดีขึ้นอยู่กับระบบไฟล์

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

ดีแล้วที่รู้. ในกรณีเฉพาะนี้มันอยู่ในคลาวด์! ดังนั้นที่จัดเก็บข้อมูลจึงค่อนข้างเป็นนามธรรมเมื่อถึงเวลาติดตั้งระบบ

— sysadmin1138

1

แคชเขียนดิสก์มีอะไรในโลกนี้เกี่ยวข้องกับการใช้งานตารางพาร์ติชั่นหรือไม่?

— psusi

3

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

— jlliagre

4

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

— jlliagre

1

@psusi ไม่ว่าจะเป็น fsync จะล้างแคชดิสก์หรือไม่นั้นขึ้นอยู่กับระบบไฟล์

— jlliagre

16

ฉันเห็นประโยชน์ที่แท้จริงเมื่อดำเนินการในสภาพแวดล้อมเสมือนจริง เนื่องจาก VMDK ของเราถูกเก็บไว้ใน NAS ของเราเราจึงสามารถเติบโตได้แบบไดนามิก

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

อย่างไรก็ตามหากคุณใช้ทั้งดิสก์แทนพาร์ติชันคุณสามารถบังคับให้สแกนซ้ำบนดิสก์ SCSI ของคุณและใช้ resize2fs เพื่อขยายระบบไฟล์ในขณะที่ออนไลน์ (และใช้งานอยู่!)

— Nick Gasparovich
แหล่งที่มา

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

— pabouk

11

การวางระบบไฟล์บนอุปกรณ์ดิสก์โดยไม่สร้างพาร์ติชันใด ๆ ไม่ใช่เรื่องแปลก

ข้อดี:

เมื่อคุณต้องการใช้พื้นที่ทั้งหมดแล้วคุณไม่ต้องเสียเวลากับเครื่องมือการแบ่งพาร์ติชัน
คุณไม่ต้องกังวลเกี่ยวกับความเข้ากันไม่ได้ของรูปแบบพาร์ติชั่น 'มาตรฐาน' (btw, รูปแบบพาร์ติชั่นใดที่เป็นมาตรฐาน, DOS หนึ่ง, BSD หนึ่ง?), เช่นรูปแบบพาร์ติชัน DOS อนุญาตพาร์ติชันได้สูงสุด 2 TB เท่านั้น ภาคตรรกะ 512 ไบต์!
คุณไม่ต้องกังวลเกี่ยวกับปัญหาการจัดแนวของพาร์ติชันที่เกิดขึ้นกับไดรฟ์ที่มีขนาดเซกเตอร์ที่ผิดปกติ (เช่น 4 k) - แน่นอนว่าการกระจายปัจจุบันควรจัดส่งเครื่องมือการแบ่งพาร์ติชันที่จัดแนวที่ถูกต้อง

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

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

2

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

กรณีการใช้งานอย่างหนึ่งอาจเป็นปริมาณ EC2 EBS ที่คุณเพิ่มลงในโหนดและต้องการเริ่มต้นเมื่อบูตครั้งแรก

หากกระบวนการเริ่มต้นของคุณสร้างพาร์ติชันคุณจะเสี่ยงต่อการรีบูตเคอร์เนลเพื่อดูพาร์ติชันที่สร้างขึ้นใหม่ โดยปกติแล้วคุณจะเห็นข้อความเช่น:

ข้อผิดพลาด: ข้อผิดพลาดแจ้งเคอร์เนลเกี่ยวกับการปรับเปลี่ยนพาร์ติชัน / dev / xvde1 - อุปกรณ์หรือทรัพยากรไม่ว่าง ซึ่งหมายความว่า Linux จะไม่ทราบเกี่ยวกับการเปลี่ยนแปลงใด ๆ ที่คุณทำกับ / dev / xvde1 จนกว่าคุณจะรีบูท - ดังนั้นคุณไม่ควรเมานต์หรือใช้มันก่อนที่จะทำการรีบูต

ในกรณีนี้กระบวนการเริ่มต้นของคุณจะต้องทำการรีบูตจากนั้นดำเนินการต่อเพื่อเพิ่มระบบไฟล์ในพาร์ติชันที่สร้างขึ้นใหม่

หากคุณรู้ว่าคุณต้องการเพียงพาร์ติชันเดียวคุณก็อาจจะข้ามมันไปโดยไม่เสี่ยงต่อการต้องรีบู๊ต

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