Sembolik bağların yerine, mount --bind komutunu kullanmanın sakıncaları var mı?

Sembolik gibi nasıl işlevlerde sınırlamaları vardır ls, mvve cpkabuk gibi komutları başlatılan aksine, çünkü onlar üzerinde çalışabilir cd, bu işlevler, kullanıcı mantıksal yola göre dizin erişilen hakkında bilgisi yoktur (ilgili bkz yayını ). Yerine bir mount --bindseçenek bulabilir , seçenek samba ve diğer dosya sunucuları ile daha fazla işlevsellik ve uyumluluk sunar, çünkü monte edilmiş dizin bir link yerine iki bağımsız fiziksel yola sahip olacaktır.

Tüm sembolik bağlarımı bu mount --bindseçeneği kullanarak referanslarla değiştirmek istiyorum ancak bu, fstab'da 150 noktaya monte etmek anlamına geliyor. Bundan veya potansiyel olarak göz önünde bulundurmam gereken herhangi bir sakıncadan kaynaklanabilecek herhangi bir performans sorunu var mı?

İle mount --bindbir dizin ağacı, dizin hiyerarşisindeki iki (veya daha fazla) yerde bulunur. Bu bir takım sorunlara neden olabilir. Yedekler ve diğer dosya kopyaları tüm kopyaları alacaktır. Bir dosya sistemini kopyalamak istediğinizi belirtmek zorlaşır: Bağlanmış dosyaları iki kez kopyalamanız gerekir. İle aramalar find, grep -r, locatevb, bu yüzden tüm kopyaları çapraz ve edecektir.

Bağlantı montajlarıyla hiçbir "artırılmış işlevsellik ve uyumluluk" elde edemezsiniz. Başka bir dizine benziyorlar, ki bu çoğu zaman istenen bir davranış değildir. Örneğin, Samba sembolik bağları varsayılan olarak dizinler olarak gösterir; bağlama montajı kullanarak kazanılacak hiçbir şey yoktur. Öte yandan, bağlanma bağları, dizin hiyerarşilerini NFS üzerinden göstermek için yararlı olabilir.

Bağlantı montajlarıyla ilgili performans sorunlarınız olmaz. Sahip olacağın şey uygulama baş ağrıları. Bağlama bağları, bir dizin ağacını bir chroot'tan erişilebilir kılmak veya bir bağlama noktası tarafından gizlenen bir dizini göstermek gibi kullanımlarına sahiptir (bu, genellikle bir dizin yapısı yeniden yapılandırılırken geçici bir kullanımdır). İhtiyacın yoksa, onları kullanma.

Sadece kök bağ bağlamalarını değiştirebilir. Sıradan yollarla hareket ettirilemezler; konumlarını ve ata dizinlerini kilitlerler.

Genel olarak konuşursak, bir komuta sembolik bir bağlantı iletirseniz, komut dosyalar üzerinde çalışıyorsa ve dosya içeriği üzerinde çalışıyorsa bağlantının hedefi üzerinde bağlantı kurar. Bu da dizinler için de geçerli. Bu genellikle doğru olanıdır. Bazı komutlar örneğin, farklı sembolik bağlantıları tedavi seçenekleri vardır ls -L, cp -d, rsync -l. Yapmaya çalıştığınız şey ne olursa olsun, bağlamaların doğru araç olması yerine, bağlantıların doğru araç olması çok daha olasıdır.

@Gilles’in daha önce yazdıklarına ek olarak , bazı yardımcı programların bağlanmış bir dizini ayrı bir dosya sistemi olarak kabul edebileceğini belirtmekte fayda var . Program artık aynı inode numarasının aynı dosyaya atıfta bulunduğunu varsayamazsa (ki farklı dosya sistemlerinde ise bunu yapmaz), bir hamle bağlantı olarak optimize edilemez. target-then-unlink-source, vb.

Daima yerinde olamayacak bir desteğe (örneğin harici bir disk) güveniyorsanız, örneğin bağlantı noktaları yerine bağlama bağları kullanmak ve desteğin bile orijinal dizin yapısının yerinde olduğundan emin olmak istediğinizde başarısız veya kaldırıldı.

Örneğin, eğer / var / tmp'yi bir sd kartında tutmak istersem, bağlama takma aracını kullanacağım, çünkü bazı programlar / var / tmp kartı çıkarılsa bile geçerli bir dizin olmasını bekleyecektir.

Ben bazı paketleri yüklerken bir sorunu geçmenin montaj bağlama çalıştık pacman(Arch Linux, burada hakkında daha fazla bir sistemde) /var(yanı sıra /homeve /usr/local) idi sembolik bağ (: SSD SATA dosya sistemleri arasında).

İlk başta harika görünüyordu, ama, Gilles belirttiği gibi, locateher zaman rağmen tek bir dosya için birden sonuçlar verdi PRUNE_BIND_MOUNTS = "yes"satır /etc/updatedb.conf.

$ locate \*/findutils-4.4.2 | xargs ls -ldiog
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /SHARED/LOCALS/Manjaro/src/findutils-4.4.2
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /usr/local/src/findutils-4.4.2

Biraz daha kazarak, daha karmaşık bağlama başlıklarının doğru şekilde budanabileceğini gördüm:

$ sudo mount --bind /SHARED/LOCALS/common/ /usr/local/common
$ findmnt | fgrep -n sdb
34:├─/SHARED/LOCALS                  /dev/sdb5           ext4           rw,relatime,data=ordered
35:│ └─/SHARED/LOCALS/Manjaro/common /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
36:├─/usr/local                      /dev/sdb5[/Manjaro] ext4            rw,relatime,data=ordered
37:│ └─/usr/local/common             /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
38:├─/SHARED/HOMES                   /dev/sdb4           ext4            rw,relatime,data=ordered
39:├─/home                           /dev/sdb4[/Manjaro] ext4            rw,relatime,data=ordered
40:├─/SHARED/VARS                    /dev/sdb3           ext4            rw,relatime,data=ordered
41:├─/var                            /dev/sdb3[/Manjaro] ext4            rw,relatime,data=ordered
42:└─/opt                            /dev/sdb5[/opt]     ext4            rw,relatime,data=ordered

$ sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
prune_bind_mounts\000
Rebuilding bind_mount_paths:
Matching bind_mount_paths:
Skipping `/SHARED/LOCALS/Manjaro/common': bind mount
Skipping `/usr/local/common': bind mount

$ locate \*/mmedia
/SHARED/LOCALS/common/mmedia

PRUNE_BIND_MOUNT seçeneği olmasaydı 3 sonuç elde ederdim:

$ sudo sed -i '1 s/yes/no/' /etc/updatedb.conf 
$ sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
prune_bind_mounts\000
$ locate \*/mmedia
/SHARED/LOCALS/Manjaro/common/mmedia
/SHARED/LOCALS/common/mmedia
/usr/local/common/mmedia
$ sudo sed -i '1 s/no/yes/' /etc/updatedb.conf 

Bağlama bağlarıyla ilgili başka bir sorun:

• grub-mkrelpath / boot bağlama bağlayıcısıysa yanlış yollar oluşturur

Tabii ki, bir el ile bağlama bağlar (mounpoint veya hedef) ekleyebilir PRUNEPATHSiçinde /etc/updatedb.conf.

Ayrıca, burada önerildiği gibi dosya sistemi geçişini geliştirmek için araçlarda mountpointçeşitli statkomutlar veya işlevler kullanılabilir.