ใน UDF ความแตกต่างระหว่างตัวระบุปริมาณตัวระบุชุดปริมาณตัวระบุปริมาณตรรกะและตัวระบุชุดไฟล์คืออะไร?

ฉันเห็นว่าmkudffsมีตัวเลือกสำหรับตัวระบุที่แตกต่างกันสี่ตัว: โลจิคัลวอลุ่ม ( --lvid), โวลุ่ม ( --vid), ชุดโวลุ่ม ( --vsid) และตัวระบุชุดไฟล์ ( --fsid) อย่างไรก็ตามมันไม่ได้ให้คำแนะนำแก่สิ่งเหล่านั้น

ดังนั้นฉันไปที่ข้อกำหนดของ UDF เริ่มต้นด้วย ISO / IEC 13346 aka ECMA-167ฉันพบว่า:

10.1.4 ตัวบ่งชี้ปริมาณ (BP 24)

ฟิลด์นี้จะต้องระบุตัวตนของปริมาณ

14.1.10 ตัวบ่งชี้เชิงตรรกะ (BP 112)

ฟิลด์นี้จะต้องระบุตัวตนของโลจิคัลวอลุ่มที่บันทึกไฟล์ไว้

14.1.12 ตัวระบุชุดไฟล์ (BP 304)

ฟิลด์นี้จะต้องระบุตัวตนของชุดไฟล์ที่อธิบายโดยตัวอธิบายชุดไฟล์นี้

นั่นมันมีประโยชน์

ดังนั้นฉันลองOSTA UDF Spec 1.02เหมือนที่เป็นรุ่น UDF ที่ฉันพยายามจะสร้าง มันไม่ได้ช่วยอะไรมากนัก (แม้ว่าจะเตือนฉันเกี่ยวกับ "ค่าคงที่หรือค่าเล็กน้อย")

ฉันลองใช้ข้อกำหนด UDF 1.50ซึ่งบอกฉันต่อไป - ใน§4.1 - ว่าก่อนแสดงค่าเหล่านั้นต้องใช้การแปลงเฉพาะระบบปฏิบัติการโดยใช้อัลกอริทึมที่อธิบายใน§4.1.2.1 แน่นอนส่วนถัดไปหลังจาก§4.1คือ§4.2โชคดีมาก นอกจากนี้ LogicalVolumeIdentifier เป็น "สำคัญอย่างยิ่งในการระบุปริมาณตรรกะเมื่อหลายสื่ออยู่ในตู้เพลงชื่อโดยทั่วไปคือสิ่งที่จะแสดงให้ผู้ใช้"

ดังนั้นฉันจึงลองใช้ข้อกำหนด UDF 2.01และตอนนี้ฉันรู้แล้วว่าอย่างน้อยตอนนี้พวกเขาก็รู้ว่ามันคือ 4 2 .2.1 ซึ่งมีอยู่แล้ว แต่ก็ไม่ได้ช่วยอะไร (มันเกี่ยวข้องกับชุดอักขระ)

ดังนั้นเท่าที่ฉันสามารถบอกได้:

• Logical Volume Identifier คือสิ่งที่แสดงต่อผู้ใช้ (อาจเป็นตู้เพลงเท่านั้น) ดังนั้นควรตั้งสิ่งที่มีความหมายเช่นชื่อแผ่นดิสก์ ฉันถือว่านี่เป็นชื่อแผ่นดิสก์ที่ Windows, Mac OS หรือ Nautilus จะแสดง
• คนอื่นมีอยู่เพียงเพื่อให้เปลืองเนื้อที่บนแผ่นดิสก์โดยไม่มีคำอธิบายที่แท้จริงสำหรับสิ่งที่พวกเขาทำ แม้จะเป็นอย่างนั้นก็ตามฉันควรตั้งค่าเป็นค่าที่ไม่คงที่และไม่สำคัญ อาจเป็นไปได้ว่าฉันควรตั้งให้เป็นแบบสุ่ม (เช่นไม่คงที่) จากเชคสเปียร์ (เช่นไม่ใช่เล็กน้อย)

หรือยังดีกว่า: ฟิลด์อื่นมีไว้เพื่ออะไร

เหล่านี้เป็นพวงของสตริงไม่เป็นประโยชน์ยกเว้นLVID

แบบฟอร์ม mkudffs:

• --lvidระบุตัวบ่งชี้ปริมาณตรรกะ มันตั้งค่าสตริงที่กำหนดให้กับฟิลด์ต่อไปนี้:
  • Logical Volume Identifier ใน Logical Volume Descriptor (ดูรูปที่ 15 ในECMA-167 )
  • Logical Volume Identifier ในการใช้งาน (ดู 2.2.7.2 ในUDF 2.01 )
  • Logical Volume Identifier ใน File Set Descriptor (ดูรูปที่ 9 ในECMA-167 ) ตัวอธิบายชุดไฟล์ (ดูรูปที่ 9 ใน [ECMA-167] [5])
    Logical Volume Identifier ที่แสดงใน windows เป็นฉลากดิสก์
• --vid ระบุตัวระบุปริมาณ มันตั้งค่าสตริง givend เป็นเขตข้อมูลตัวระบุปริมาณในตัวบ่งชี้ปริมาณหลัก (ดูรูปที่ 6 ในECMA-167 ) ความยาวสูงสุด 31 ไบต์ ค่าเริ่มต้น "Linux UDF"
• --vsidระบุตัวระบุชุดปริมาณ มันตั้งค่าสตริงที่กำหนดให้กับเขตข้อมูลตัวระบุชุดปริมาณใน Primary Volume Desriptor (ดูรูปที่ 6 ในECMA-167 ) ความยาวสูงสุด 127 ไบต์ ค่าเริ่มต้น "Linux UDF"
  Volume Set Identifier สามารถแก้ไขได้โดยโปรแกรมเขียนดิสก์บางโปรแกรมเช่น ImgBurn, MagicISO มันระบุการระบุของชุดปริมาณที่ปริมาณเป็นสมาชิก
• --fsidระบุตัวระบุชุดไฟล์ มันตั้งค่าฟิลด์ตัวระบุชุดไฟล์ในตัวอธิบายชุดไฟล์ (ดูรูปที่ 9 ในECMA-167 ) ความยาวสูงสุด 31 ไบต์ ค่าเริ่มต้น "Linux UDF"

ฉันคิดว่าสิ่งเหล่านี้ขึ้นอยู่กับคุณอย่างสมบูรณ์ ฉันว่าเขตข้อมูลนั้นมีไว้เพื่อสนับสนุนกระบวนการขององค์กร การใช้งานอย่างหนึ่งที่นึกถึงคือการใช้ตัวระบุชุดไดรฟ์สำหรับสิ่งต่าง ๆ เช่น "การสำรองข้อมูลเต็มรูปแบบรายเดือนของ FOO, 2015-12" และตัวระบุไดรฟ์อาจเป็นสิ่งที่เหมือนกับ "ดิสก์ 1 จาก 42" หรือบางทีคุณอาจมีตัวระบุจริงเช่นบาร์โค้ดที่พิมพ์บนดิสก์และตัวระบุปริมาณสามารถเก็บไว้ได้ (เพื่อให้คุณสามารถระบุดิสก์ได้โดยการอ่านในไดรฟ์หรือโดยการอ่านบาร์โค้ดที่จุดนั้น )

ฉันจินตนาการว่าตัวระบุชุดไฟล์อาจมีประโยชน์เมื่อคุณใส่ไฟล์จำนวนมากในระบบไฟล์ที่สร้างหน่วยตรรกะ ("set") บางอย่าง แต่พวกมันไม่ได้สร้าง "โวลุ่ม" โดยสังหรณ์ใจ ตัวอย่างเช่น "Mariah Carey .gifs 1994-1998" หรือ "เรียงความโรงเรียนมัธยมของ Bob"

การพูดอย่างมีเหตุผลทุกสาขาจะมีข้อมูลที่สมาชิก (หรือสมาชิก) ของคณะกรรมการผู้พัฒนาและ / หรือแก้ไขมาตรฐานเห็นว่าจำเป็น เพียงเพราะมีคนคิดว่ามันเป็นการสิ้นเปลืองเนื้อที่บนดิสก์ไม่ได้หมายความว่าไม่มีความคิดเห็นอย่างน้อยหนึ่งเรื่องเมื่อตกลงตามมาตรฐาน ในความเป็นจริงสมาชิกบางคนหรือสมาชิกของคณะกรรมการคิดว่าพวกเขามีประโยชน์เพียงพอสำหรับวัตถุประสงค์หนึ่งหรืออื่นที่พวกเขาทำให้มีวิธีในมาตรฐาน ฉันพูดว่าสิ่งใดที่ไม่ได้กำหนดไว้อย่างชัดเจนในมาตรฐานเปิดให้ตีความและดังนั้นจึงสามารถนำมาใช้เพื่อวัตถุประสงค์ใดก็ตามที่คุณต้องการหรือละเว้นได้อย่างปลอดภัยจนกว่าจะถึงเวลาที่กำหนดไว้อย่างชัดเจนโดยมาตรฐาน จากมุมมองการเขียนซอฟต์แวร์ 'mkudffs' ไม่จำเป็นต้องกำหนดสิ่งที่คุณควรใช้ฟิลด์เหล่านี้เพื่อ

ฉันคิดว่าค่าเหล่านี้ปรับทิศทางตามรายละเอียดอื่น ๆ ซึ่งพวกเขาพยายามที่จะพูดคุยสื่อ mngt ในตัวอย่างของฉันฉันจะอ้างถึง Linux แต่นี่ไม่ได้หมายความว่ามันจะไม่ใช้กับ Windows รายละเอียดเหล่านั้น ถูกซ่อนอยู่ที่นั่น

รัน cmd ต่อไปนี้บน Linux และดูที่เอาต์พุต: blkid

/ dev / x: LABEL = "Windows" UUID = "?" TYPE = "ntfs" PARTLABEL = "พาร์ติชันข้อมูลพื้นฐาน" PARTUUID = "?"

/ dev / y: LABEL = "Linux" UUID = "?" TYPE = "ext4" PARTLABEL = "storage" PARTUUID = "?"

อย่างที่คุณเห็นมี 2 ช่องคำอธิบายสำหรับทุก ๆ :

• กั้น
• FileSystem บนพาร์ติชั่นนั้น

ในทั้งสองกรณีคำแรกคือคำอธิบายที่มนุษย์สามารถอ่านได้และคำอธิบายหลังของเครื่อง เช่นเดียวกับใน Domain Name System (DNS) เนื่องจากคำอธิบายเครื่อง - UUID - จะต้องไม่ซ้ำกัน ดังนั้นเราสามารถพูดคุยเกี่ยวกับเขตข้อมูล nx 2 x 2 สำหรับพาร์ติชัน แต่เนื่องจากสื่อออพติคัลไม่ได้รับการแบ่งพาร์ติชันสื่อบันทึกดิบจึงนับเป็นพาร์ติชันเอง ซึ่งหมายความว่ามีแอตทริบิวต์ 2 x 2 = 4 เสมอ ให้ลองใส่คุณสมบัติ UDF ให้พอดีกับตัวอย่างด้านบน:

/ dev / x: LABEL = "LVID" UUID = "VID" TYPE = "UDF" PARTLABEL = "VSID" PARTUUID = "FSID"

ฉันค้นหาชั่วโมงและอ่านบทความจำนวนมาก แต่ไม่สามารถตรวจสอบได้ นี่เป็นเพียงข้อสมมุติ แต่สำหรับ LVID นั้นสามารถมั่นใจได้โดยนิยามของคำศัพท์และจากการทดลอง Linux และ Windows ซึ่งเป็นรุ่นหลังของ WinCDemu ใช้คุณสมบัตินี้เป็นป้ายกำกับสำหรับพาร์ติชัน สำหรับสื่อออพติคอลนั้นเป็นสื่อกลาง

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