Perché cp --reflink = auto non è il comportamento predefinito?

31

Perché cp --reflink=autonon è il comportamento predefinito? Potrebbe causare danni per abilitarlo?

È possibile abilitarlo in fase di compilazione, quindi viene utilizzato in tutto il sistema, non solo nelle shell interattive?

btrfs coreutils

— Fabian Henze
fonte

4

Sì, bella domanda. IMHO lo farà, poiché solo BTRFS inizia a essere un file system Linux predefinito.

— Adam Ryczkowski il

38

Non è l'impostazione predefinita poiché, per motivi di solidità, è possibile che venga eseguita una copia per proteggere dalla corruzione dei dati. Inoltre, per motivi di prestazioni, è possibile che si verifichino operazioni di scrittura al momento della copia anziché un processo sensibile alla latenza che lavora su un file CoW e che potrebbe essere ritardato dalle scritture su una parte diversa di un disco meccanico. Si noti che da coreutils v8.24 mv si rifletterà per impostazione predefinita, poiché non ha i vincoli di cui sopra.

— Pádraig Brady
fonte

8

(che potrebbe essere considerata una risposta autorevole poiché Pádraig è un manutentore dei coreutils GNU).

— Stéphane Chazelas,

8

Dubito che questa risposta sia corretta, almeno su btrfs. Se il file viene successivamente scritto, i nuovi dati verranno comunque scritti in un diverso settore del disco a causa del CoW di btrfs, quindi non vi è alcun vantaggio di latenza nel non eseguire i reflink. I file che hanno NoDataCoW impostato non possono comunque essere riflessi. E se vuoi proteggerti dalla corruzione dei dati, dovrai copiarli in un'altra partizione e anche i reflink non funzioneranno.

— JanKanis,

3

Esistono problemi di latenza poiché BTRFS deve trovare e allocare spazio al momento della scrittura. Questo potrebbe anche non essere disponibile, generando così errori ENOSPC al momento della scrittura

— Pádraig Brady,

1

A che serve mv per il reflink?

— Macil,

1

cross subvolume renames on btrfs

— Pádraig Brady,

17

Non so perché non è il default, forse in modo che si comporta lo stesso di altre utilità di copiatura ( rsync, cpio, pax, tar...) che non hanno il supporto per esso (o quando i file vengono copiati attraverso un'interfaccia che non permette che (come NFS, samba, livelli dei file system dei fusibili ...).

Ero nella stessa situazione qualche anno fa, e guardando rapidamente il codice cp GNU, è sempre lo stesso, devi correggere il codice per ottenere un comportamento predefinito diverso:

--- coreutils-8.21/src/cp.c~    2013-06-22 21:50:26.265639114 +0100
+++ coreutils-8.21/src/cp.c     2013-06-22 21:51:06.880513924 +0100
@@ -775,7 +775,7 @@ cp_option_init (struct cp_options *x)
   x->interactive = I_UNSPECIFIED;
   x->move_mode = false;
   x->one_file_system = false;
-  x->reflink_mode = REFLINK_NEVER;
+  x->reflink_mode = REFLINK_AUTO;

   x->preserve_ownership = false;
   x->preserve_links = false;

— Stéphane Chazelas
fonte

4

Un grosso problema è il potenziale a corto di spazio per fare la copia quando scrivi.

Con una copia normale, quindi non appena la copia è completa, non dovrai mai preoccuparti di una scrittura su parti esistenti del file che non riescono: lo spazio è interamente allocato e non andrà via fino a quando non elimini il file. Ma con una copia reflink, c'è sempre il rischio che ad un certo punto settimane o mesi lungo la strada, una scrittura su una parte esistente del file fallisca perché non c'era abbastanza spazio per fare una copia.

Scoprire che il tuo sistema stava eseguendo copie reflink alle tue spalle quando un'operazione come quella falliva sarebbe stata una brutta sorpresa.

— gwd
fonte

Almeno su btrfs anche scrivere su parte del file già allocata può fallire con ENOSPC ...

— graywolf

2

alias cp='cp --reflink=auto --sparse=always'

ha più senso che correggere il codice

— Il blog tecnico di James
fonte

6

Sembra che tu abbia ignorato È possibile abilitarlo in fase di compilazione, quindi viene utilizzato in tutto il sistema, non solo nelle shell interattive nella domanda del PO.

— Stéphane Chazelas,

5

@StephaneChazelas Uno potrebbe sempre rinominarlo /bin/cpe sostituirlo con uno script shell simile

— goncalopp

0

Robustezza per cui si potrebbe desiderare una copia per proteggere dalla "perdita" di dati.

Non sappiamo che sia la ragione, ma le cose brutte che possono accadere sono limitate alla distruzione dei media. La maggior parte di tutti i dispositivi a blocchi avrà una qualche forma di identificazione della corruzione (crc), se non inoltra la correzione degli errori (parità).
Non per motivi di prestazioni.

Il CoW si verifica quando solo una parte del? Cancella? il blocco è scritto in. Con il moderno! Disco! dispositivo la dimensione del blocco hardware è un multiplo di 4k. La modifica di parte del 4k fa sì che l'unità legga l'intero 4k e lo riscriva, ma per di più il kernel farà la stessa cosa in modo che non ci siano scritture parziali che raggiungono il dispositivo a blocchi, SSD o altro . Il kernel deve eseguire il CoW per gli stessi motivi, a meno che non abbiamo una copia memorizzata nella cache non possiamo recuperare i dati esistenti nelle altre parti del dispositivo, salvo la fine del racconto di un file ma il punto è discutibile. Ma la memorizzazione nella cache di una copia di un file e la copia di un file sono operazioni diverse, la prima è molto più economica.

L'indirizzo della scrittura è irrilevante, ma fai sapere che "una parte del dispositivo non utilizzata" è più economica da scoprire rispetto a "dove risiedono attualmente i blocchi del file".

Il fatto è che qualsiasi metodo CoW è più economico o uguale al semplice aggiornamento di un dispositivo a blocchi. Ora se non stessimo parlando di dispositivi a blocchi, sarebbe un'altra storia ... Scritta su nastro da qualche parte.

— Mike Mestnik
fonte