ใช้เคสสำหรับฮาร์ดลิงก์? [ปิด]

40

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

filesystems hard-link

— Matthew Cline
แหล่งที่มา

4

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

— RichF

16

ฮาร์ดลิงก์แรกไปยังไฟล์นั้นมีประโยชน์มาก

— หยุดทำร้ายโมนิก้า

@OrangeDog: ใช่ แต่คุณต้องการฟิลด์ link-count ใน inode หากคุณต้องการรองรับหลาย ๆ link (คุณอาจต้องตั้งค่าสถานะสำหรับ inode ในหน่วยความจำรุ่นเพื่อจัดการกับกรณีที่ไม่ได้เชื่อมโยง แต่ยังคงเปิดอยู่ fsck หลังจากเกิดความผิดพลาดโดยไม่ต้อง journaling จะยังคงต้องค้นหา inodes โดยไม่มีการเชื่อมโยงทั้งสองวิธี)

— Peter Cordes

1

ความหมายของไดเรกทอรี POSIX จะต้องได้รับการออกแบบที่แตกต่าง: ..อยู่เสมอ inode เดียวกับ.ในไดเรกทอรีหลัก สิ่งต่าง ๆ เช่นfindสามารถตรวจสอบว่า link-count = 2 เพื่อตรวจจับไดเรกทอรีใบไม้และหลีกเลี่ยงการstatไอเอ็นจีรายการจาก readdir เพื่อค้นหาไดเรกทอรีย่อย แต่นั่นเป็นเพียงคุณสมบัติย่อยที่เปิดใช้งานโดยการสนับสนุนสำหรับลิงก์ของไฟล์ที่ไม่ใช่ไดเรกทอรี (ปกติ, symlink, อุปกรณ์, ซ็อกเก็ตและชื่อไปป์) (ใช่ symlink มีไอโหนดของตัวเองและสามารถเชื่อมโยงได้)

— Peter Cordes

1

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

— mathguy

27

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

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

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

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

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

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

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

— Spellweaver ยิปซี
แหล่งที่มา

3

FYI: ภาพรวม btrfs ไม่ใช่ลิงก์ พวกเขามีพฤติกรรมที่แตกต่างกัน (เช่นการแก้ไขหนึ่งสำเนาจะไม่แก้ไขอีก) และstatจะแสดงเพียงลิงค์เดียว

— Derobert

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

— Spellweaver ยิปซี

แต่ละ symlink มีไอโหนดของตัวเองดังนั้นมันจึงใช้ไอเท็ม inode ในระบบไฟล์ ระบบไฟล์ Unix แบบดั้งเดิมต้องการให้คุณเลือกพื้นที่ที่จะสำรองสำหรับ inodes ในเวลาที่สร้าง FS แทนการจัดสรรตามความจำเป็นเช่นเดียวกับ XFS ดังนั้นจึงเป็นเรื่องสำคัญจริง ๆ ที่เวอร์ชัน symlink จะใช้ไอโหนดจำนวนมากขึ้น (นอกเหนือจาก VFS cache footprint นัยสำคัญ)

— Peter Cordes

23

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

touch a
ln -s a b
rm a

ตอนนี้bไร้ประโยชน์ (และขั้นตอนเหล่านี้อาจเกิดขึ้นค่อนข้างห่างกันทำโดยคนอื่น ฯลฯ )

ในขณะที่มีการเชื่อมโยงอย่างหนัก

touch a
ln a b
rm a

b ยังคงอยู่และถูกต้อง

— สตีเฟ่น Kitt
แหล่งที่มา

8

@MatthewCline คุณต้องการพฤติกรรมนี้เมื่อจัดการการสำรองข้อมูลส่วนเพิ่มที่มีประสิทธิภาพ โดยเฉพาะอย่างยิ่งเมื่อการสำรองข้อมูลเก่าถูกลบทิ้งในระบบสำรองข้อมูลแบบ soft-link คุณจะต้องตรวจสอบและเชื่อมโยงไฟล์สำรองลิงค์ / ลิงก์ใหม่ทั้งหมดไปยังฐานที่ถูกต้องอีกครั้ง timeshift / backintime ตัวอย่างเช่นใช้ hardlinks อย่างกว้างขวาง

— orzechow

3

@orzechow ฉันไม่คิดว่าคุณต้องการพฤติกรรมการเชื่อมโยงอย่างหนักทุกที่ใกล้กับระบบสำรองของคุณ github.com/bit-team/backintime/wiki/ .. backintime โง่ ๆ สันนิษฐานว่าการเปลี่ยนแปลงทั้งหมดของไฟล์จะเป็นรอบการลบสร้างแทนที่จะอัปเดต

— DepaniDaniel

10

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

— สตีเฟ่น Kitt

1

นี่ไม่ใช่คำตอบ - โดยเฉพาะมันไม่ใช่กรณีการใช้งาน มันเป็นเพียงการสาธิตพฤติกรรมการเชื่อมโยงอย่างหนัก

— 394

1

@ ThomasPadron-McCarthy นั่นเป็นความเข้าใจผิด BiT ใช้ฮาร์ดลิงก์เพื่อลิงก์ไฟล์ที่เหมือนกันภายในสแน็ปช็อตที่ต่าง พวกเขาจะไม่เชื่อมโยงกับไฟล์ต้นฉบับ! (ฉันคือ BiT Dev)

— Germar

11

โปรแกรมเดียวอาจเปลี่ยนพฤติกรรมของมันขึ้นอยู่กับชื่อที่เปิดตัวเป็น:

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

สิ่งที่เหนือกว่าในแหล่งที่มาจะตัดสินใจผ่านสิ่งที่ชอบ

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

แม้ว่ารายละเอียดที่แน่นอนจะแตกต่างกันไปขึ้นอยู่กับระบบปฏิบัติการและภาษาที่เกี่ยวข้อง

สิ่งนี้อนุญาตให้โค้ดที่เหมือนกัน (ส่วนใหญ่) ไม่จำเป็นต้องคอมไพล์ออกเป็นสองไบนารี (ส่วนใหญ่) ที่เหมือนกัน โปรดจำไว้ว่ายูนิกซ์เป็นแบบวันต่อวันเมื่อพื้นที่ว่างในดิสก์มีราคาแพงมากถึงแม้ว่า Stevens ใน APUE บทที่ 4 symlinks จะถูกนำมาใช้ใน BSD4.2 (1983) เพื่อแทนที่ข้อ จำกัด ต่าง ๆ ของฮาร์ดลิงก์ โปรแกรมทดสอบเพื่อตรวจสอบว่าชื่อ symlink ถูกใช้เป็นชื่อโปรแกรมอาจมีลักษณะดังนี้:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

และทดสอบผ่าน:

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$

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

4

แต่นั่นไม่ใช่เรื่องปกติที่จะจัดการกับซอฟต์ลิงค์?

— Matthew Cline

1

@ MatthewthCline อาจเป็นวันนี้ แต่ไม่มีการเชื่อมโยงสัญลักษณ์ก่อน 4.2BSD (1983) ตาม Stevens ใน APUE

— thrig

4

@thrig คำถามที่ถามถึงกรณีการใช้งานที่ไม่สามารถทำได้โดย symlink หรืออย่างน้อยก็น่าจะดีกว่าการใช้ symlink คำตอบของคุณใช้ได้กับทั้ง HL และ SL

— Marcelo

3

BusyBox ใช้เวลานี้ให้สูงสุด

— Max Ried

8

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

ข้อดี:

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

ประเด็นหลัก:ถ้าฉันรู้ล่วงหน้าว่าฉันจะต้องใช้ไฟล์ไหนrmก่อนฉันจะไปด้วย symlink แต่ฉันไม่เคยรู้

— Kamil Maciorowski
แหล่งที่มา

6

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

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

ดังนั้นที่นี่มีบางกรณีการใช้งานที่เข้าร่วม hardlinksแต่softlinks ไม่ได้ :

ลองนึกภาพคุณมีคอลเลกชันภาพยนตร์หรือเพลงหรือสื่ออื่น ๆ และต้องการใช้เกณฑ์การจำแนกประเภทที่แตกต่างกันเช่นเพลงที่จำแนกตามศิลปินในสาขา (ศิลปินแต่ละคนมีไดเรกทอรีย่อยของตนเอง); ตามประเภทในสาขาอื่น (ในแต่ละไดเรกทอรีย่อยที่แตกต่างกัน) ฯลฯ คุณยังคงไม่ต้องการทำซ้ำไฟล์หรือตัดสินใจว่าจะวาง "ต้นฉบับ" ไว้เพื่อให้คุณมีอิสระในการจัดประเภทใหม่โดยไม่ต้อง " จัดการ "และเชื่อมโยงไฟล์ใหม่เมื่อมีการเคลื่อนย้ายเพื่อหลีกเลี่ยงลิงก์ที่เสียหาย
อีกเหตุผลหนึ่งคือเพื่อหลีกเลี่ยงการเสียพื้นที่เก็บข้อมูลซึ่งจำเป็นสำหรับการมีหลายสำเนาของไฟล์เดียวกันและยังอนุญาตให้chrootsyscall ได้รับประโยชน์จากชุดย่อยของไฟล์ในรูทระบบไฟล์ "master" (ลิงก์สัญลักษณ์ไม่สามารถอ้างอิงไฟล์จากภายนอกได้chrootSandbox แม้ว่าพวกเขาจะมีเส้นทางญาติ)
อีกเหตุผลที่สำคัญมาก แต่ไม่ค่อยกล่าวถึงสำหรับการเชื่อมโยงไปยังมีอยู่เป็น..ไดเรกทอรีย่อย ..ไดเรกทอรีจริง (ในส่วนการใช้งานยูนิกซ์ FS) hardlinks ไปยังไดเรกทอรีผู้ปกครองโดยไม่ต้อง hardlinks นี้จะต้องมีการดำเนินการในทางที่ต่างกันในขณะที่การดำรงอยู่ของ hardlinks นี้จะทำให้ง่ายมากที่จะดำเนินการ

— มาร์เซโล
แหล่งที่มา

1

สำหรับจุดที่ 1 การใช้ uuids เป็นชื่อ 'canonical' สำหรับไฟล์และการสร้างลิงก์สัญลักษณ์สัญลักษณ์ที่มนุษย์สามารถอ่านได้ทั้งหมดไปยัง uuids นั้นเป็นทางเลือกอื่น

— . ..

แม้ว่าข้อเสนอแนะของ uuids จะถูกต้องตามหลักวิชาการ แต่การใช้ uuids สำหรับชื่อไฟล์นั้นไม่ได้มีประโยชน์อะไรมากและอีกครั้งวัตถุประสงค์ก็เพื่อทำให้สิ่งต่าง ๆ ง่ายขึ้นไม่ใช่ทำให้ยากขึ้นหรือ "มนุษย์เข้าใจน้อยลง" นอกจากนี้การมี uudis สำหรับการอ้างอิงไฟล์ "canonical" จะเป็นการเพิ่มทางอ้อมไปยัง inode ของไฟล์จริงดังนั้นจึงไม่มีประเด็นใดที่จะสำเร็จในวิธีการนี้เนื่องจากไม่มีข้อดีข้อเสียเช่น: ผลกระทบต่อประสิทธิภาพการทำงานเพิ่มเติม พื้นที่ว่างในดิสก์เพื่อจัดเก็บรายการไดเรกทอรีมากขึ้นโดยมีกลุ่มไฟล์ที่มีชื่อ "แปลก ๆ " อยู่รอบ ๆ ...

— Marcelo

5

ตัวอย่างที่พบบ่อยมากในโลกแห่งความเป็นจริงที่ต้องการฮาร์ดลิงก์:

git clone --reference <repository>

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

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

git clone --shared <repository>มีรุ่นที่ไม่ใช่ฮาร์ดลิงค์: อย่างไรก็ตามสิ่งนี้ไม่แน่นอนและมีข้อแม้มากมายเนื่องจากทุกคนทำงานในไดเรกทอรีเดียวกัน

— พอลเดรเปอร์
แหล่งที่มา

4

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

ln image.bin backup_image.bin
ln -sf backup_image.bin uImage

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

มันจะไม่ง่ายอย่างนั้น

/ แก้ไข:

ขอบคุณความคิดเห็นตอนนี้ฉันรู้ว่ามันจะดีกว่าที่จะทำ:

ln image.bin backup_image.bin
ln -sf backup_image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage

// replace image.bin

ln -sf image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
rm backup_image.bin

(สิ่งrmนี้อยู่ที่นี่เพื่อให้สามารถหลบหนีจากสภาวะแปลก ๆ ได้ดีขึ้นเช่นหากuImageมีสิ่งที่ไม่คาดคิดซึ่งจะทำให้เกิดความmvล้มเหลว [แต่ไม่จำเป็นต้องln -sfแก้ไขก่อนหน้านี้])

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

2

+1 เพราะนี่เป็นแนวคิดที่ดีมาก แต่น่าเสียดายที่ln -sfไม่ใช่อะตอม มันลบ symlink เก่าและสร้างใหม่ ในการแก้ไขปัญหานี้คุณต้องสร้าง symlink ใหม่ด้วยชื่อชั่วคราวและrename(2)( mv) เพื่อเชื่อมโยงกับชื่อที่คุณต้องการแทนที่

— . ..

@R .. คุณพูดถูก! 😲 stat("uImage", {st_mode=S_IFREG|0777, st_size=0, ...}) unlink("uImage"),symlink("backup_image.bin", "uImage")

— phk

1

BTW ดูที่นี่สำหรับรุ่นของฉันinstall.shที่แก้ปัญหา: git.musl-libc.org/cgit/musl/tree/tools/install.sh

— R ..

@R .. โปรดทราบว่าmvแม้จะมี-fอาจล้มเหลวหากปลายทางมีอยู่แล้วเช่น symlink ที่เป็นส่วนหนึ่งของวง symlink การสาธิต:

ln -sf foo bar; ln -sf bar foo; echo "Before:"; ls -l foo bar; >testfile; mv testfile foo || { echo "Using mv -f"; mv -f testfile foo; }; echo "After:"; ls -l foo bar

— phk

3

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

— โทมัส Padron-McCarthy
แหล่งที่มา

3

BackupPCเป็นระบบสำรองข้อมูลที่ใช้ฮาร์ดลิงก์บนเซิร์ฟเวอร์เพื่อจัดทำไฟล์ซ้ำซ้อนระดับไฟล์

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

ฮาร์ดลิงก์นั้นเหนือกว่าซอฟต์ลิงค์นุ่ม ๆ ที่นี่เพราะมันมีการนับการอ้างอิงอัตโนมัติ งาน cron จะลบไฟล์ใด ๆ ในไดเร็กทอรี pool เป็นระยะที่ไม่มีลิงก์มากกว่าหนึ่งลิงก์

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

กรณีการใช้งานอื่น: เซิร์ฟเวอร์เว็บแอ็พพลิเคชัน tomcat java ใช้ชื่อไฟล์เป็นข้อมูลเมตา ไฟล์ java "war" ต้องตั้งชื่อตามพา ธ บนเว็บเซิร์ฟเวอร์

เช่น: foo.war เป็นรหัส java ที่ให้บริการ URL/foo

น่าเสียดายที่มันสามารถแก้ไข symlink ได้ก่อนตัดสินใจ

ดังนั้นสมมติว่าคุณต้องการปรับใช้แอปพลิเคชั่นบิลด์และตั้งชื่อไฟล์อธิบาย (เช่นด้วยหมายเลขรีลีสหรือวันที่) คุณไม่สามารถสร้าง symlink ไปยังไฟล์ที่มีชื่อ "ของจริง" ได้ - คุณต้องสร้างฮาร์ดลิงก์

foo.warsymlinked to foo-20170129.warไม่ทำงาน

foo.warhardlinked ไปใช้foo-20170129.warงาน

ฉันไม่ชอบพฤติกรรมของแมวตัวผู้ตัวนี้ แต่ตัวเชื่อมก็ให้ทางฉัน

— แดนพริตต์
แหล่งที่มา