Neden dosya ekleme sistem çağrıları yok


11

Anladığım kadarıyla, dosyaları işlemek için Linux'ta yalnızca dosya içeriğinin üzerine yazan (veya sonunda varsa) genişleten sys_write sistem çağrısı vardır.

Linux'ta dosyalara içerik eklemek veya silmek için neden sistem çağrıları yok?

Tüm mevcut dosya sistemleri, dosyanın sürekli bir bellek bloğunda saklanmasını gerektirmediğinden, etkili bir uygulama mümkün olmalıdır. (Dosyalar parçalanır.)

"Yazarken kopyala" veya "saydam dosya sıkıştırması" gibi dosya sistemi özellikleriyle, geçerli içerik eklemenin çok verimsiz olduğu görülmektedir.


4
Tüm süslü dosya işlemlerinde olduğu gibi, böyle bir işlem pratikte göründüğünden çok daha az yararlıdır. Böyle bir şeyin ana kullanımı, veritabanları, emülatörler ve benzeri gibi çok özel uygulamalardır. Genellikle bir dosyayı "düzenleme" şekliniz, yeni bir dosya oluşturmak ve kullanıcının yeni dosyayı eski olarak yeniden adlandırmak için "kaydetme" işlemidir.
19'da mosvy

3
@mosvy, ancak "yeni dosya oluştur, sonra yeniden adlandır" kavramı kendi içinde iyi olduğu için veya tam olarak sistem daha iyi bir yol sağlamadığı için mi kullanılıyor? Özellikle "bu satırı değiştir (uzunluğu değiştir)" veya "bu satırları buraya ekle" gibi metin dosyaları işlemleri oldukça yaygındır, bu yüzden eğer varsa, bu işlevler için dosya sistemi işlemlerinin kullanılacağı varsayılabilir. Tabii ki, onlara sahip olmamak fs uygulamasını daha basit hale getirir ...
ilkkachu

1
@meuh OpenVMS hala RMS (Kayıt Yönetim Hizmetleri) üzerinden yapıyor.
RonJohn

1
UNIX , dosya sistemi içinde kayıt yönetim sistemleri sağlamaktan uzaklaşmaya başladı .
user207421

1
@ilkkachu kendi içinde iyi, kesinlikle şüphesiz ;-) Daha fazla, inotlar değişmez olsaydı, blok paylaşımı, sürüm oluşturma ve neredeyse her şeyi çok daha verimli hale getirecek (ve akıl yürütmek için çok daha basit). Benzetimle, tüm kod dillerinin değişmez dizelere nasıl geçtiğini düşünün - ama burada kısaltacağım; dosya sistemleri hakkında kelepçe konuşmak ve bir quack gibi ses çıkarmak zor ;-)
mosvy

Yanıtlar:


22

Aslında mümkün olan son Linux sistemlerinde, ancak blokla (çoğu zaman 4096), bayt ayrıntı düzeyini değil , sadece bazı dosya sistemlerinde (ext4 ve xfs).

Manpage'den alıntı fallocate(2):

int fallocate(int fd, int mode, off_t offset, off_t len);

[...]

Daralan dosya alanı

FALLOC_FL_COLLAPSE_RANGEBayrağını (Linux 3.15'ten beri kullanılabilir) belirtmek, modebir boşluk bırakmadan dosyadaki bayt aralığını kaldırır. Daraltılacak bayt aralığı bayttan başlar offsetve lenbayt boyunca devam eder . İşlem tamamlandığında, konumdan başlayan dosyanın içeriği konuma offset+leneklenir offsetve dosya lenbayt daha küçük olur.

[...]

Dosya alanını artırma

FALLOC_FL_INSERT_RANGEBayrağı (Linux 4.1'den beri kullanılabilir) belirtmek, modevarolan verilerin üzerine yazmadan dosya boyutuna bir delik ekleyerek dosya alanını artırır. Delik başlar offsetve lenbayt boyunca devam eder . Dosyanın içindeki deliği eklerken, dosyadan başlayan dosyanın içeriği bayt offsettarafından yukarı kaydırılır (yani, daha yüksek bir dosya ofsetine) len. Dosyanın içine bir delik eklemek dosya boyutunu lenbayt artırır .


1
"ancak blok (4096) ile, bayt tanecikliğinden değil" - 4KiB blokları ext4'te çok yaygındır, ancak bu garanti edilmez. Ext4 , 1KiB, 2KiB ve 4KiB blok boyutlarını destekler ; ve ext2 günden itibaren Alpha işlemcilerde 8KiB'in de desteklendiğini hatırlıyorum. Korkarım ki blokların 4KiB olduğunu varsayamazsınız.
marcelm

1
4k (varsayılan) 1k ve 2k'nin katlarıdır, bu nedenle ext4 ile 4k varsaymakta sorun yoktur. Xfs varsayılan olarak 4k'ye sahip olsa da, 4k'dan daha büyük bir bs'yi desteklemesi gerekiyordu - 64k'ye kadar, ancak sadece böyle bir fs oluşturabiliyordum - montaj ENOSYS olmadan başarısız oluyor. Her neyse, hiçbir şey kabul edemezsiniz - bu özellik tüm fs'de desteklenmez, bu yüzden sadece block = 4096 demek daha iyidir, bu nedenle okuyucunun yüzmesine izin vermek ve insanlara bir şey olabilmesine izin vermek yerine bir miktar oranlama hissi vardır, veya daha da kötüsü, 512 bayt veya bir şekilde vm sayfa boyutuyla ilişkili olması.
mosvy

Düzenledikten sonra ( genellikle 4KiB olduğunu söylediğiniz yerde), tamamen katılıyorum! Benim sorunum daha önce "bloklar her zaman 4KiB vardır" olarak kolayca okunmasıydı , bu da insanların bu varsayımı yapmasına ve buggy kodu yazmasına neden olabilir.
marcelm

9

Tüm mevcut dosya sistemleri dosyanın sürekli bir bellek bloğunda saklanmasını gerektirmediğinden,

Dosya sistemleri, dosyaların sürekli bir alanda depolanmasını gerektirmeyebilir (ve bu çok esnek değildir), ancak genellikle dosyalar sabit boyutlu bloklarda (veya bitişik blok dizilerinde) saklanır. Bu şekilde yapılması uygulamayı basitleştirir ve bloklar genellikle alttaki cihazın blok boyutunun katlarıdır.

Bu nedenle, rastgele uzunluktaki blokların eklenmesinin uygulanması, dosya sistemi formatını ve uygulamasını daha karmaşık hale getirecek veya potansiyel olarak büyük miktarda veriyi hareket ettirmeyi gerektirecektir. Bunların hiçbiri gerçekten iyi değildir ve karmaşık veri yapıları dosya sistemi API'sının üstüne kullanıcı alanında oluşturulabilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.