ทำไมจึงมีฮาร์ดลิงก์


คำตอบ:


56

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

วิธีที่ดีที่สุดที่ฉันรู้ที่จะเห็นคือ:

$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../

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

สิ่งนี้บอกว่าเป็นว่าเมื่อเราไปลงในไดเรกทอรีย่อยและมองที่แตกต่างกันเข้าระบบแฟ้มที่เรียกว่า..มันมีหมายเลขไอโหนดเดียวกันกับที่เรามีก่อน สิ่งนี้ไม่ได้เกิดขึ้นเพราะเชลล์แปลภาษา..ให้คุณเช่นเดียวกับที่เกิดขึ้นกับ MS-DOS และ Windows บนระบบไฟล์ Unix ..เป็นรายการไดเรกทอรีจริง เป็นฮาร์ดลิงก์ที่ชี้กลับไปยังไดเรกทอรีก่อนหน้า

ฮาร์ดลิงก์คือเอ็นที่เชื่อมโยงไดเร็กทอรีของระบบไฟล์เข้าด้วยกัน กาลครั้งหนึ่งยูนิกซ์ไม่มีการเชื่อมโยงอย่างหนัก พวกเขาถูกเพิ่มเข้ามาเพื่อเปลี่ยนระบบไฟล์ดั้งเดิมของ Unix ให้เป็นระบบไฟล์แบบลำดับชั้น

(สำหรับข้อมูลเพิ่มเติมเกี่ยวกับสิ่งนี้ให้ดูที่เหตุใดรายการ '/' มีรายการ '.. '? )

มันค่อนข้างทั่วไปในระบบ Unix สำหรับคำสั่งต่าง ๆ ที่จะใช้งานโดยปฏิบัติการเดียวกัน มันไม่ได้ดูเหมือนจะเป็นกรณีที่เกี่ยวกับลินุกซ์ใด ๆ มากขึ้น แต่ในระบบที่ผมใช้ในอดีตที่ผ่านมาcp, mvและrmทุกคนที่ปฏิบัติการเดียวกัน มันสมเหตุสมผลถ้าคุณคิดเกี่ยวกับมัน: เมื่อคุณย้ายไฟล์ระหว่างโวลุ่มมันเป็นสำเนาที่มีประสิทธิภาพตามด้วยการลบดังนั้นจึงmvต้องใช้ฟังก์ชั่นอีกสองคำสั่งของ ปฏิบัติการสามารถคิดออกว่าการดำเนินการที่จะให้เพราะมันได้รับชื่อที่ถูกเรียกโดย

อีกตัวอย่างหนึ่งที่พบบ่อยใน Linuxes ฝังตัวเป็นBusyBoxเป็นปฏิบัติการเดียวที่ดำเนินการหลายสิบของคำสั่ง

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


4
เกี่ยวกับ "ลิงก์ยังใช้พื้นที่จำนวนเล็กน้อยบนดิสก์เพื่อเก็บข้อความของลิงก์" บนระบบไฟล์ที่ทันสมัยจะไม่มีการใช้พื้นที่พิเศษเพื่อจัดเก็บลิงก์พา ธ เนื่องจากรายการไดเร็กทอรีเองถูกใช้เพื่อจัดเก็บอย่างน้อยถ้าชื่อไม่ยาวเกินไป สิ่งนี้เรียกว่า "การ
เชื่อมโยง

ฉันจะเพิ่มว่าบางแอปพลิเคชันไม่ทราบวิธีจัดการกับลิงก์ soft (sym) และลิงก์ฮาร์ดอาจเป็นประโยชน์ในการหลีกเลี่ยงความซ้ำซ้อนเมื่อทำการตั้งค่าโดยอ้างอิงจากไฟล์ data / config เดียวกัน ตัวอย่างคือ ioquake3 ซึ่งไม่สามารถติดตามไฟล์ pk3 แบบลิงก์ได้ แต่สามารถติดตามไฟล์ pk3 ที่ลิงก์ได้
gaborous

3
นอกจากนี้หากคุณลบเป้าหมายของ symlink ไฟล์นั้นจะหายไปและ symlink ก็จะใช้งานไม่ได้ ปัญหาที่ไม่มีอยู่ในฮาร์ดลิงก์
สเปกตรัม

1
แต่ฮาร์ดลิงก์มีข้อมูลบางส่วนเช่นกัน - ชื่อของมัน ดังนั้นจึงควรใช้พื้นที่
Josef Klimuk

39

การใช้งานฮาร์ดลิงก์หนึ่งครั้งซึ่งมีประโยชน์อย่างยิ่งคือในการสำรองข้อมูลแบบเพิ่มหน่วยรวมกับ rsync ช่วยประหยัดพื้นที่ได้มากและทำให้ขั้นตอนการฟื้นฟูนั้นง่ายมาก ฉันใช้วิธีการนั้นในการสำรองข้อมูลในเซิร์ฟเวอร์ของฉัน

ใช้เวลาสักครู่เพื่ออ่านคำอธิบายนี้


12

หากหลังจากอ่านหน้าวิกิพีเดียแล้วคำถามของคุณคือ "ทำไมฉันถึงต้องใช้พวกเขา" คุณจะไม่เข้าใจว่าฮาร์ดลิงก์คืออะไร

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

คุณเองอาจไม่เคยใช้ฮาร์ดลิงก์ แต่มันอยู่ในระบบของคุณ ตัวอย่างเช่น:

$ ls -li /bin | grep 53119771
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bunzip2
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bzcat
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bzip2

คุณจะเห็นว่าbunzip2, bzcatและbzipทั้งหมดใช้ไอโหนดเดียวกัน ในสาระสำคัญมันเป็นหนึ่งไฟล์ที่มีสามชื่อ คุณสามารถมีสามสำเนาของแฟ้ม แต่ทำไม? มันจะใช้พื้นที่ดิสก์โดยไม่จำเป็นเท่านั้น


12
แต่ก็มีจำนวนของการเชื่อมโยงใน/binฉันเดาว่าเป็นหนึ่งในแหล่งที่มาของความสับสน ทำไมบางครั้ง executables จะถูก symlinked และบางครั้ง - hardlinked?
Dmitry Pashkevich

16
คำตอบนี้ไม่สามารถให้เหตุผลใด ๆ เลยสำหรับการใช้ฮาร์ดลิงก์ผ่านซอฟต์ลิงค์
Mark Amery

8

มีการใช้งานไม่ จำกัด จำนวน ฉันใช้มันเพื่อสร้างล็อคไฟล์ การเชื่อมโยงของระบบ (2) คืออะตอมมิกซึ่งแตกต่างจากการโทรของระบบส่วนใหญ่

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

ฉันยังใช้มันเพื่อแลกเปลี่ยนไฟล์กำหนดค่าบนเซิร์ฟเวอร์: rm file.cfg && ln ~/tmp/file.cfg file.cfgจากนั้นไฟล์ ~ / tmp / * สามารถลบได้อย่างปลอดภัย


1
ทำไมแยกlnและrmแทนที่จะเป็นเพียงmv?
Tommiie

6

หากต้องการเพิ่มการสนทนาที่ดีหลายรายการที่มีอยู่แล้ว

  • วิธีการเข้าถึงทรัพยากรสำหรับโปรแกรมนั้นมีการใช้งานในระบบปฏิบัติการยูนิกซ์ (เช่น"ทุกอย่างคือไฟล์" ) หมายความว่าโครงสร้างพื้นฐานสำหรับการจัดการการอ้างอิงหลาย ๆ ไฟล์เป็นสิ่งจำเป็นสำหรับระบบปฏิบัติการที่จะทำงานได้ทั้งหมดดังนั้นจึงไม่มีค่าใช้จ่ายเพิ่มเติม
  • ไดเรกทอรีวิธีที่ถูกนำมาใช้ในระบบไฟล์ยูนิกซ์เดิม (เช่นรายการรูปแบบคงที่ของ(inode, name)คู่หมายความว่าไม่มีค่าใช้จ่ายเพิ่มเติมในระบบแฟ้มที่จะมี hardlinks (ดีตราบใดที่เราป้องกันไม่ให้รอบโดยไม่อนุญาตให้ hardlinke ไดเรกทอรี (นอกเหนือ.และ..(สิ่งนี้จะเริ่มรู้สึกเหมือนเสียงกระเพื่อมกับคนอื่นหรือไม่)))

ดังนั้นเราได้รับฟรี


2

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

สมมติว่าคุณสร้าง Hardlink เชื่อมโยงไปยัง/foo/myfile /repo/myfileทั้งคู่เป็นตัวชี้ไปยังข้อมูลไฟล์เดียวกัน เปลี่ยนหนึ่งการเปลี่ยนแปลงอื่น ๆ แต่สมมติว่า/repoเกิดขึ้นเพื่อเก็บที่เก็บ Git หากคุณตรวจสอบสาขาที่ไม่มีmyfileในนั้น/repo/myfileจะถูกลบ ในขณะนี้/foo/myfileกลายเป็นสำเนาง่ายๆ/repo/myfileเหมือนเดิมในขณะที่อีกคู่ไม่ได้เชื่อมโยง เป็นเรื่องง่ายที่จะไม่สังเกตเห็นแม้แต่ตอนที่คุณพลิกระหว่างกิ่งที่ไฟล์มีการเปลี่ยนแปลง แต่เมื่อคุณชำระเงินสาขาดั้งเดิมเป็นไฟล์ใหม่/repo/myfileถูกสร้างโดย Git หากคุณไม่ได้สนใจคุณจะสงสัยว่าทำไมทั้งสองไฟล์จึงมีเนื้อหาที่แตกต่างกันถึงแม้ว่ามันจะเป็นเรื่องง่ายเพราะความสัมพันธ์ฮาร์ดลิงก์ระหว่างไฟล์นั้นไม่มีความคิดเกี่ยวกับชื่อของพวกเขา ซอฟต์ลิงก์จะอยู่รอดผ่านวงจรลบ - สร้างนี้

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

ข้อดีอีกประการของฮาร์ดลิงก์คือสามารถย้ายลิงก์ใด ๆ โดยไม่หยุดการเข้าถึงเนื้อหาไฟล์ ด้วยซอฟต์ลิงค์การย้ายไฟล์ดั้งเดิมจะทำให้ซอฟท์ลิงค์นั้นห้อยไปมา

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

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

นอกจากนี้ฉันต้องชี้ว่าการเรียกไลบรารี่ที่ลบไฟล์นั้นถูกเรียกunlink()ด้วยเหตุผล! ทุกรายการไดเรกทอรีเป็นเพียงการเชื่อมโยงอย่างหนักเอกพจน์เริ่มต้นไปที่ไอโหนด

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.