Perché non ci sono syscall per l'inserimento di file

Per quanto ne so, per manipolare i file c'è solo il syscall sys_write in Linux, che sovrascrive il contenuto del file (o lo estende, se alla fine).

Perché non ci sono syscall per l'inserimento o l'eliminazione di contenuti nei file in Linux?

Poiché tutti i file system attuali non richiedono che il file sia archiviato in un blocco di memoria continuo, dovrebbe essere possibile un'implementazione efficiente. (I file verrebbero frammentati.)

Con le funzionalità del file system come "copia in scrittura" o "compressione file trasparente", l'attuale modo di inserire il contenuto sembra essere molto inefficiente.

files file-copy system-calls

— dercolamann
fonte

Come con tutte le operazioni di file di fantasia, tale operazione è molto meno utile in pratica di quanto sembri. L'uso principale di una cosa del genere sono applicazioni molto specializzate, come database, emulatori e simili. Il modo in cui di solito "modifica" un file è creando un nuovo file e facendo eseguire un'operazione di "salvataggio" da parte dell'utente, rinominare il nuovo file con il vecchio.

— mosvy,

@mosvy, ma viene utilizzato il concetto "crea nuovo file, quindi rinomina" perché è buono in sé o esattamente perché il sistema non fornisce alcun modo migliore? Soprattutto nelle operazioni sui file di testo come "modifica questa riga (cambiando la lunghezza)" o "inserisci queste righe" sono piuttosto comuni, quindi si potrebbe presumere che le operazioni del filesystem per quelle esatte funzioni sarebbero usate se fossero lì. Naturalmente, non averli rende l'implementazione di fs molto più semplice ...

— ilkkachu,

@meuh OpenVMS lo fa ancora, tramite RMS (Record Management Services).

— RonJohn,

UNIX ha iniziato ad allontanarsi dal fornire sistemi di gestione dei record all'interno del file system.

— user207421

@ilkkachu è buono in sé, assolutamente senza dubbio ;-) Ancora di più, se gli inode fossero immutabili, questo renderebbe più efficiente la condivisione dei blocchi, il controllo delle versioni e quasi tutto ciò (e molto più semplice da ragionare). Pensa per analogia a come tutti i linguaggi di script sono passati a stringhe immutabili - ma lo taglierò qui; è difficile parlare a

— crepapelle dei

Risposte:

Sui recenti sistemi Linux ciò è effettivamente possibile, ma con blocco (4096 la maggior parte delle volte), non granularità di byte , e solo su alcuni filesystem (ext4 e xfs).

Citando dalla fallocate(2)manpage:

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

[...]

Comprimere lo spazio file

Specificando il FALLOC_FL_COLLAPSE_RANGEflag (disponibile da Linux 3.15) si moderimuove un intervallo di byte da un file, senza lasciare un buco. L'intervallo di byte da comprimere inizia offsete continua per i len byte. Al completamento dell'operazione, il contenuto del file che inizia nella posizione offset+lenverrà aggiunto nella posizione offsete il file sarà lenpiù piccolo di byte.

[...]

Aumento dello spazio per i file

Specificare il FALLOC_FL_INSERT_RANGEflag (disponibile da Linux 4.1) in modeaumenta lo spazio per i file inserendo un buco nella dimensione del file senza sovrascrivere i dati esistenti. Il buco inizierà a offsete continuerà per i lenbyte. Quando si inserisce il foro all'interno del file, il contenuto del file a partire da offsetviene spostato verso l'alto (ovvero in un offset del file più elevato) di lenbyte. L'inserimento di un foro all'interno di un file aumenta la dimensione del file di lenbyte.

— mosvy
fonte

"ma con blocco (4096), non granularità di byte" - I blocchi 4KiB sono molto comuni in ext4, ma ciò non è garantito. Ext4 supporta blocchi da 1 KiB, 2 KiB e 4KiB ; e ricordo dai giorni ext2 che sui processori Alpha era supportato anche 8 KiB. Non puoi solo supporre che i blocchi siano 4KiB, temo.

— marcelm,

4k (che è l'impostazione predefinita) è un multiplo di 1k e 2k, quindi non ci sono problemi ad assumere 4k con ext4. Anche se xfs per impostazione predefinita è 4k, si suppone che supporti un bs più grande di 4k - fino a 64k, ma sono stato solo in grado di creare un tale fs - il montaggio fallisce senza ENOSYS. E comunque, non puoi assumere nulla: questa funzione non è supportata su tutte le fs, quindi è meglio dire solo block = 4096, quindi il lettore ha un certo senso delle proporzioni, piuttosto che lasciarlo fluttuare e lasciare che la gente possa essere qualsiasi cosa, o peggio, che è di 512 byte o è in qualche modo correlato alla dimensione della pagina vm.

— mosvy,

Dopo aver modificato (dove dici che di solito è 4KiB), sono pienamente d'accordo! Il mio problema era che in precedenza veniva facilmente letto come "i blocchi sono sempre 4KiB" , il che potrebbe indurre le persone a fare questo presupposto e scrivere codice errato.

— marzo

Poiché tutti i file system correnti non richiedono che il file sia archiviato in un blocco di memoria continuo,

I filesystem potrebbero non richiedere che i file siano archiviati in un'area continua (e questo sarebbe davvero molto poco flessibile), ma di solito i file sono memorizzati in blocchi di dimensioni fisse (o sequenze di blocchi contigui). Farlo in questo modo semplifica l'implementazione e i blocchi sono generalmente multipli della dimensione del blocco del dispositivo sottostante.

Pertanto, l'implementazione di inserti di blocchi di lunghezza arbitraria renderebbe il formato e l'implementazione del file system piuttosto più complessi o richiederebbe lo spostamento di grandi quantità di dati in giro. Nessuno di questi è veramente buono, e strutture di dati complessi possono essere costruite nello spazio utente sopra l'API del filesystem.

— ilkkachu
fonte