Linux sembolik bağlarla nasıl çalışır?

11

Yani bazı süreçler bir sembolik bağ okumak istediğinde neler oluyor? Bir şey bir okuma veya yazma işlemi sırasında bir sembolik bağlantıyı değiştirdiğinde neler oluyor?

Örneğin: 2 büyük, benzer 100G dosyam var /mnt/1ve /mnt/2. /mnt/1symlink aracılığıyla kullanılabilir /home/user/file. Bazı programlar Aokumaya başlar /home/user/file. Ve bir süre sonra bir şey bağlantıyı olarak /mnt/1değiştirir /mnt/2, ancak Adosyayı hala okuyor.

Program mutlak yolu önbelleğe alıyor mu?

Symlink değiştirildiğinden başarısız olur ve hata yapar mı yoksa hiçbir şey olmamış gibi iyi çalışır mı?

/home/user/fileBir blok cihaza (örneğin 2 çoğaltılmış iscsi diskine) bağlı olması durumunda farklılık gösterecek mi?

filesystems symlink

— acele
kaynak

9

Symlink , dosya sistemindeki gerçek dosyanın ( inode ) adını gösterir . Sistem bu symlink'i gerçek dosyayı bulup açtığında çözdüğünde, dosyanın inode'unu bulur ve kullanır. Bu noktada, dosyaya ulaşmak için kullandığınız yolun önemi yoktur. İşletim sisteminin önbelleğe almadığı şey, dosyadan inode ile okur. Anladığım kadarıyla, dosyayı sabit bir bağlantı aracılığıyla okumaya başlayabilir ve bu sabit bağlantıyı kaldırabilirsiniz ~~(dosya hala başka bir yerden bağlı~~ olduğu sürece) ve dosya çözüldüğü sürece sorunlara neden olmaz ( name string-> inode).

— Kevin
kaynak

4

Dosyaya TÜM bağlantıları kaldırabilir ve açtıktan sonra da okumaya devam edebilirsiniz. Bu nedenle, pencerelerde olduğu gibi yeniden başlatmadan paketleri yükseltebilirsiniz; çünkü çalışıyor olsa bile programın yürütülebilir dosyasını rm yapabilirsiniz.

— psusi

1

@psusi Ben veri ve inode hala orada olduğunu biliyorum ve sadece artık işaret değil, ama dosya silindikten sonra, sistem disk üzerinde bu nokta üzerine yazmak için ücretsiz, değil mi? Dosya söz konusu 100 GB dosya gibi dosya önbelleğine sığmayacak kadar büyükse, sonuna gelmeden bir kısmının üzerine yazılırsa ne olur? Bu kritik sistem dosyaları için bir endişe değil çünkü önbelleğe yüklenir ve orada tutulur, ancak 100GB bunun bir endişe olabileceğini düşündüğüm kadar büyük.

— Kevin

2

Kevin, dosya kullanan son süreç ölene kadar dosyalar diskten kaldırılmadı. Şu anda kullanımda olan tüm dosyaları proc'da her zaman bulabilirsiniz. Ama cevabım sorumu açıklıyor gibi görünüyor. Teşekkürler.

— acele

2

Bu yanıt, bir sembolik bağın hedef dosyanın adını içerdiği kritik bir noktayı kaçırır .

— Keith Thompson

6

Bir sembolik bağ içeren küçük bir dosyadır konumu bu bir sembolik olduğunu belirten dizin girişinde bir bayrak, bir hedef dosyasının (yani yol ve dosya adı).

Bir sembolik bağlantısı açtığınızda, işletim sistemi hedef dosyayı bulmak için konumu izler. Hedefin kendisi bir sembolik bağlantı ise, konum sembolik olmayan bir dosyaya işaret edene kadar konumunu (1) (2) de izler (buna FinalFile diyelim ). Sonra işletim sistemi elde düğüm arasında FinalFile (düğüm modifikasyonu zamanlı gibi meta veriler içerir ve ayrıca dosya verileri gösteren bir işaretçi yer alır). Son olarak FinalFile'ın inode'u açılır. Şu andan itibaren süreç dosyayı okumak / yazmak için bu inode'u kullanıyor. Sonuç sembolik link adını veya yolunu değiştirme sembolik silme yolu veya adının değiştirilmesi gibi FinalFile hatta silme FinalFile(3) süreç üzerinde hiçbir etkisi yoktur; hala aynı inode'dan okuyor.

Çoğu durumda, symlink'teki dosya-veri işlemleri FinalFile'ı etkiler (örn . Symlink'e okuma ve yazma FinalFile'dan okunur / yazılır ), ancak istisnalar vardır: readlink()sistem çağrısı , symlink'in içeriğini okur.

Öte yandan, dosya meta veri işlemleri (yeniden adlandırma veya silme gibi) genellikle sembolik bağlantıyı etkiler. Ancak burada da istisnalar vardır: lstat()Sistem çağrısı stat(), ancak FinalFile (2) yerine sembolik bağlantı hakkında bilgi döndürmesi gibidir .

(1) Seviye sayısında bir sınır vardır ve sembolikteki konum göreceli bir yolsa işler biraz daha karmaşık hale gelir.

(2) Symlink'i okuyun (7): daha fazla ayrıntı için sembolik bağlantı kullanımı .man 7 symlink

(3) rmKomut veya unlink()sistem çağrısı bir dosyayı fiziksel olarak kaldırmaz. Dosyanın inode'unu gösteren dizin girişini kaldırır. Dosyanın kendisi yalnızca her ikisi de a) kendi inode'una işaret eden daha fazla dizin girişi (sabit bağlantı) yoksa ve b) hiçbir işlem dosya açık değilse kaldırılır .

— Keith Thompson
kaynak

1

Bu Linux için neredeyse şeffaftır ve kullandığınız dosya sistemiyle işletim sisteminden çok daha fazla ilişkilidir.

Bu, normal bir dosya veya çok küçük bir dosya değildir, çünkü VFAT bölümünde çalışan sembolik bir bağlantı oluşturamazsınız, örneğin doğrudan dosya sistemi tarafından kaydedildiği için sembolik bağlantının kendisini kopyalayarak.

Bir sabit bağlantıya sembolik bağlantıdaki fark, atamanın, sabit bir bağlantı gibi veri sektörlerine poiting yapmak yerine sabit bir bağlantıya olmasıdır.

Misal:

Test 1:

echo 'data' >file.txt

Bu, 10 ila 20 * sektörlerini işaret eden sabit bağlantı file.txt dosyasını oluşturacaktır (* sadece açıklama için numaralar).

Test 2:

Şimdi ne olacak?

ln file.txt file_2.txt

Bu, 10 ila 20 sektörlerini (file.txt ile aynı) gösteren bir sabit bağlantı dosyası_2.txt oluşturdu, bu nedenle file.txt dosyasını silerseniz, 10 ila 20 sektörleri hala saklıdır ve file_2.txt içindeki verileri görebilirsiniz ... . (file.txt ve file_2.txt dosyalarının her ikisi de orijinaller gibidir)

Test 3:

ln -s file.txt file_sym.txt

File_sym.txt dosyasını sabit bağlantı file.txt'ye işaret etti, böylece file_sym.txt dosyasına erişmeye çalıştığınızda file.txt dosyasını göreceksiniz, ancak file.txt dosyasını silerseniz file_sym artık hedefi bulamayacak.

Bunlar dosya sistemi tarafından yönetilir, örneğin linux için ext4 modülleri (veya çekirdekte derlenmişse), Linux veya başka bir Unix kullanıyor olmanız önemli değildir.

— Luciano Andress Martini
kaynak