Hardlinks için durumlarda kullanın? [kapalı]

Hangi durumlarda soft-link yerine hard link kullanmak istersiniz? Kişisel olarak, bir soft-link üzerinden hard-link kullanmak istediğim bir durumla karşılaşmadım ve internette arama yaparken karşılaştığım tek kullanımlık özdeş dosyaları tekilleştirmek .

Bir BTRFS birimindeki anlık görüntüleri de içerdiğine inandığım başka bir yorumda belirtilen yedekleme kullanımının yanı sıra, yumuşak bağlantılar üzerinden sabit bağlantılar için bir kullanım örneği, etiket sıralamalı bir dosya koleksiyonudur. (Bir koleksiyon oluşturmak için mutlaka en iyi yöntem değil, veritabanı tabanlı bir yöntem potansiyel olarak daha iyidir, ancak oldukça kararlı olan basit bir koleksiyon için çok da kötü değildir.)

Tüm dosyaların bir, düz, dizinde saklandığı ve çeşitli ölçütlere göre diğer dizinlere ayrıldığı bir medya koleksiyonu, örneğin: yıl, konu, sanatçı, tür, vs. Eserleri. Temelde bittiğinde, dosya büyük olasılıkla linklerle birden fazla yere kaydedilmiş, değiştirilmemiş ve sıralanmamış.

Ayı "orijinal" ve "kopya" kavramı sabit bağlantılar için geçerli değildir akılda: dosyaya her bağlantı olduğunu normal anlamda hayır "kopya" var, orijinal. Bununla birlikte, kullanım durumunun tanımı için, terimler davranışın mantığını taklit etmektedir.

"Orijinal", "katalog" dizinine kaydedilir ve sıralanan "kopyalar" bu dosyalara bağlanır. Sıralama dizinlerindeki dosya öznitelikleri, dosya adlarında ve sıralanan yapıda yanlışlıkla yapılan değişiklikleri önleyerek r / o olarak ayarlanabilirken, katalog dizinindeki öznitelikler de gerektiğinde değiştirilebilir. (Bunun için, bazı oyuncuların medya dosyasına gömülü etiketleri temel alan, kullanıcı girişinden veya internet erişiminden aldıkları dosyaları yeniden adlandırmaya ve yeniden düzenlemeye çalıştıkları müzik dosyaları olabilir.) Ayrıca, "kopya" dizinlerinin özellikleri farklı olabilir. "orijinal" dizini, sınıflandırılmış yapı gruba veya dünyaya kısıtlı erişime sahip olurken, ana "katalog" yalnızca asıl kullanıcı tarafından erişilebilir duruma getirilebilir. tam erişim ile. Bununla birlikte, dosyaların kendileri her zaman bu inode'a bağlanan tüm bağlantılarda aynı özelliklere sahip olacaktır. (ACL bunu geliştirmek için araştırılabilir, ancak bilgi alanımı değil.)

Orijinal yeniden adlandırılırsa veya taşınırsa (tek bir "katalog" dizini, örneğin yönetmek için çok büyük hale gelirse), sert bağlantılar geçerli kalır, yumuşak bağlantılar kopar. "Kopyalar" taşınırsa ve yumuşak linkler göreceli ise, yumuşak linkler tekrar kırılır ve hard linkler olmaz.

Not: Yazılım bağlantıları söz konusu olduğunda, farklı araçların disk kullanımını nasıl bildirdiği konusunda bir tutarsızlık var gibi görünmektedir. Ancak, hard linklerle tutarlı görünüyor. Bu nedenle, bir katalogdaki "etiket" koleksiyonuna ayrılmış 100 dosya ile kolayca bağlantılı 500 kopya olabilir. (Fotoğraf koleksiyonu için tarih, fotoğrafçı ve ortalama 3 "konu" etiketini söyleyin.) Örneğin, Dolphin, hard linkler için 100, soft linkler kullanılıyorsa 600 dosya olduğunu bildirir. İlginçtir ki, aynı disk alanı kullanımını her iki şekilde de rapor eder, bu nedenle yumuşak bağlantılar için küçük bir dosya koleksiyonu ve sabit bağlantılar için küçük bir büyük dosya koleksiyonu gibi görünür.

Bu tür bir kullanım durumunun bir uyarısı, COW kullanan dosya sistemlerinde, "orijinalin" değiştirilmesi, sabit bağlantıları kırabileceği, ancak yumuşak bağlantıları kıramadığıdır. Ancak, asıl kopyaya sahip olmak niyetindeyse, düzenleme, kaydetme ve sıralama sonrasında COW senaryoya girmez.

Sabit bağlantılar, her iki dosyanın varlığını bağlamak istemediğiniz durumlar için kullanışlıdır. Bunu düşün:

touch a
ln -s a b
rm a

Şimdi bişe yaramaz. (Ve bu adımlar birbirinden oldukça uzak olabilir, farklı insanlar tarafından yapılabilir, vb.)

Oysa sert bir bağlantı ile

touch a
ln a b
rm a

b hala mevcut ve doğru.

Tek bir program, hangi adla başlatıldığına bağlı olarak davranışını değiştirebilir:

$ 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

Kaynağında hangi gibi bir şey ile karar verilir

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

Yine de kesin ayrıntılar, işletim sistemine ve ilgili dile bağlı olarak değişecektir.

Bu, (çoğunlukla) özdeş kodun, iki (çoğunlukla) özdeş ikili dosyaya derlenmesi gerekmemesini sağlar. Unix, unix'in disk alanının süper pahalı olduğu günlere dayanmasına rağmen, APUE bölüm 4'teki Stevens'a göre, çeşitli hardlinks sınırlamalarının yerine geçmek için BSD4.2'de (1983) 4 linkler uygulanmıştır. Sembolik bağlantı adının program adı olarak kullanılıp kullanılmadığını kontrol eden bir test programı şöyle görünebilir:

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

Ve şu şekilde test edildi:

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

P2P yazılımım belirli bir dosyayı indirmeyi tamamladığında, dosya belirli bir dizine yerleştirilir. İndirilen dosyaların düzenlenmesi gerekmez. Yaygın durum, dosyanın olması gereken yere farklı bir dizinde bağlantı oluşturmamdır.

Avantajları:

• Hala P2P ağında dosya paylaşırken ben bile yapayım rmya mv"kopyası".
• Dosya aynı zamanda ihtiyacım olan yolda; bu tür konumların çoğu paylaşılmıyor.
• rmDosya paylaşımını durdurmak için "orijinal" olabilir ; bu işlem istenen yerde "kopya" yı etkilemez.
• Disk alanım sadece bir kez kullanılıyor.

Asıl nokta: önceden hangi dosyayı rmilk önce seçeceğimi bilseydim, sembolik bağlantıya geçebilirim. Ama ben asla bilmiyorum.

Dosya sistemleri, dosyaları düzenlemek ve sınıflandırmak için basit ama etkili bir yoldur (bu onların varoluş nedenidir). Hardlinks bu konuda daha fazla esneklik sağlar.

Belirtildiği gibi, hardlinks ile uğraşırken orjinal ve kopya kavramı yoktur, tüm dizin girişleri (hardlinks) basitçe dosyanın varlığına atıfta bulunur (inode'u işaret eder), öncelikli olarak yoktur, dolayısıyla kırılmış hardlinksler yoktur. .

İşte burada, hardlinklerin katıldığı bazı kullanım durumları var ancak softlinkler :

1. Film, müzik veya başka bir medya koleksiyonunuz olduğunu ve bir daldaki sanatçı tarafından sınıflandırılan şarkılar gibi farklı sınıflandırma kriterlerinin uygulanmasını istediğinizi düşünün (her sanatçının kendi alt dizini vardır); başka bir daldaki türe göre (her biri farklı bir alt dizinde), vb. Yine de, dosyaları çoğaltmak ya da "orijinalini" nereye koyacağınıza karar vermek istemezsiniz, böylece yeniden düzenlemek zorunda kalmazsınız " kırık bağlantılardan kaçınmak için dosyaları yönetin ve yeniden bağlayın.

2. Diğer bir neden, aynı dosyanın birden fazla kopyasına sahip olmak için gerekli olacak depolama alanı israfını önlemek ve yine de chrootsistem çağrısının "ana" dosya sistemi kökündeki bir dosya alt kümesinden faydalanmasına izin vermesidir (sembolik bağlantılar asla dışarıdan dosyalara başvuru yapamazlar) chrootsandbox, onlar) göreli yolları olsa bile.

3. Sabit bağlantıların var olmasının çok önemli, ancak nadiren dile getirilen bir diğer nedeni de ..alt dizinlerdir. ..Dizinleri aslında sabit bağlantılarını varlığı çok kolay uygulanacak bu yapar iken sabit bağlantılarını olmadan bu, tamamen farklı bir şekilde uygulanmasının sağlanması gerekmektedir, (çoğu unix uygulamaları fs) ana dizinine sabit bağlarının vardır.

Sabit bağlantılara ihtiyaç duyan çok yaygın, gerçek dünya örneği:

git clone --reference <repository>

Bu, neredeyse sıfır kopyalamayla yerel bir Git deposundan klonlanır. Nesne dosyalarını kopyalamak yerine (Git'in "veritabanı" için kullandığı değişken dosyalar) kopyalamak istiyor.

Herhangi bir repo bir nesneyi kaldırabilir, ancak inode depoların geri kalanı için geçerli kalır. Bir nesne tüm depolardan kaldırılırsa, diskten silinir. Sert bağlantılar, oldukça sağlam ve hızlı bir çözüm sunar. CI sunucularında çok yaygındır.

Olmayan bir sert bağlantı sürümü var: git clone --shared <repository>. Ancak, bu kararsız ve herkes aynı dizinde çalıştığı için çok daha fazla uyarıya sahip.

Kısa bir süre önce U-Boot tabanlı sistemler için güvenli bir güncelleme prosedürü için bir kullanım davası uImageaçmıştım; buradaki görüntü, önyüklemeye işaret eden yumuşak bir bağlantıydı; İşlemin gerçekleşmesi (dosya sisteminin birlikte çalıştığını varsayarak)

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

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

Hardlinks olmadan bu kadar basit olmazdı.

/Düzenle:

Yorumlar sayesinde şimdi yapmanın daha iyi olacağını biliyorum:

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

( rmGarip bir durumdan daha iyi bir şekilde kaçabilmek için burada, örneğin uImagebeklenmedik bir şey olursa , mvbaşarısızlığa neden olacak bir şey varsa (ancak önceki ln -sfçözüm gerekli değil ).)

Sabit bağlantılar için sahip olduğum tek kullanım kırık bir dosyayı indirirken veya açarken elde etmektir. İndirme veya açma işlemini yapan program (örneğin, unzip veya unrar gibi), bir hatayla karşılaştığında eksik dosyayı otomatik olarak kaldırır ve genellikle tutma seçeneği yoktur. Dosyayı saklamak istersem, dosyaya sert bir bağlantı yapabilirim.

BackupPC , dosya düzeyinde veri tekilleştirme sağlamak için sunuculardaki sabit bağlantıları kullanan bir yedekleme sistemidir.

Dosyalar ilk önce md5 karma değerlerine göre "pool" dizin ağacında saklanır. Bu dosyayı kullanan herhangi bir yedekleme, havuz dosyasına zor bir bağlantı yapar. Yedeklemeler sona erdiğinde / silindiğinde, sabit bağlantıları dosya sisteminden kaldırılır.

Sabit bağlantılar burada otomatik bağlantı sayımı sağladıklarından, yumuşak bağlantılardan daha üstündür. Bir cron işi, havuz dizinindeki birden fazla bağlantıya sahip olmayan dosyaları periyodik olarak siler.

Bu yöntemin bazı dezavantajları vardır (temel olarak, yedekleme deposunu çoğaltmak için dosya sistemi tabanlı araçları kullanmak zordur), ancak pratikte oldukça sağlam olduğu kanıtlanmıştır.

Başka bir kullanım durumu: tomcat java web uygulama sunucusu, dosya adlarını meta veri olarak kabul eder. Bir java "savaş" dosyasının web sunucusundaki yoluna bağlı olarak adlandırılması gerekir.

örneğin: foo.war URL’yi sunan java kodudur./foo

Ne yazık ki, bu kararı vermeden önce sembolik noktaları çözer.

Bu nedenle, bir uygulama derlemesi dağıtmak istediğinizi ve açıklayıcı bir dosya adı (örneğin, bir sürüm numarası veya tarihi ile) vermek istediğinizi söyleyin. Sen olamaz "gerçek" adıyla dosyaya link edin - Eğer hardlink yapmak zorunda.

foo.warbağlantılı foo-20170129.wardeğil çalışmıyor

foo.warfoo-20170129.warişlere hardlinked .

Bu tomcat davranışını sevmiyorum, ama hardlinks bana bir yol göster.