Newsgroup: it.comp.os.linux.sys
Titolo: Cancellare contenuto cartella sotto  punto di montaggio...

Il titolo e' la cosa meno chiara che mi e' venuta in mente...........
Se io monto il tmpfs su /var/log esiste un metodo per cancellare (senza fare l'umount e quindi a caldo) l'originale /var/log sul 
disco che contiene ancora i vecchi log ?
E' un esercizio di stile, ovviamente potrei riavviare anche da cd/usb e farlo con una live.
Se non si e' capito vi capisco e spiegero'.................
Giulia

 E' un esercizio di stile, ...
No, è una delle cose fondamentali da sapere.

 contiene ancora i vecchi log ?
No perche' il "vecchio" filesystem e' a quel punto "nascosto".
Davide
-- 
That's when you must acquire the skill to fart at whim... doing so will
protect the Holy Personal Space. -- Stephen S. Edwards II

Peccato sprecare una cosi bella occasione per tacere...........
Giulia
PS:log era un esempio vale anche per /tmp  ecc ecc.....


 
Secondo me da qualche parte qualcosa si puo' ancora fare poiche' al livello di reiserfs(nel mio caso) ad esempio la cartella esiste 
(ed occupa spazio).
Per capirci e' come se cancellassi un file in una fat montata scrivendo i settori di fd0 invece di scrivere rm nomefile.
con fdo = reiserfs
     rm nomefile = astrazione file system(con tutti i punti di montaggio)
Dovrei riuscire a parlare con reiserfs senza passare il filesystem.
Giulia

 disco che contiene ancora i vecchi log ?
No, bisogna pensarci prima montando in bind l'originale da qualche altra parte.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.


Guarda che se Davide ti dice che nun se pò fà, al 100% _nun_se_pò_fà_.
Non che lui abbia bisogno di me per difenderlo...
'Però se sei così convinta, provaci, forse ci riesci'.
--
Saludos,
Adriano

 Dovrei riuscire a parlare con reiserfs senza passare il filesystem.
Eeeeehhh.. no. Qualunque cosa tu faccia, tu passi _sempre_ per il
filesystem, che tu lo veda "direttamente" tramite il device node o meno,
passi sempre per il driver.
Ma perche' non spieghi il tuo problema invece della tua soluzione?
Davide
-- 
. <- the point                                your article -> .
|------------------------- a long way ------------------------|
-- Christophe Rhodes, ucam.chat

 ...
Ammetto che ho interpretato male la domanda; vediamo se 
ora ho capito bene:
Tu vuoi montare un filesystem su una directory non vuota.
Non è una cosa da farsi anche se tutto quello che succede 
è che non puoi accedere ai file nella gerarchia sotto la
directory vecchia, anche se erano già aperti prima del 
montaggio (rischiando di corrompere il filesytem se 
stai scrivendo quel file). 
Davide Bianchi è stato categorico: non puoi accedere a 
quei file, punto e basta, ed io condivido.
In teoria tu prospetti una possibilità: accedere al 
filesystem tramite il device del dispositivo fisico.
Sì, certo si potrebbe fare ma:
1) Accedi un filesystem a mano e non con gli strumenti 
   appropriati offerti dal sistema operativo.
2) Accedi ad un device mentre è montato.
E torniamo a quanto detto precedentemente: 
Stiamo su .sys e non su .cazzate

 parli sono molto alte 
Io direi che la probabilità del contrario è zero.

 occupa spazio).
Ma certo che occupa spazio e la cartella (che si chiama directory)
esiste.
Però devi fare l'umount del file system che ci hai montato sopra, per
arrivarci.
Oppure debuggare in profondità reiser per scoprire come accedervi lo
stesso, fregandosene della struttura del file system attivo in quel
momento.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 momento.
Smontando prima il filesystem, se non vuoi creare dei danni irreparabili. 


Semplicissimo, fai il mount del filesystem che contiene
"/var/log" originale da qualche altra parte e cancelli i file.
Esempio, supponiamo che /var/log/ appartenga a /, montata da
/dev/sda2, allora basta creare una directory dummy, tipo
"mkdir /tmp/dummy_root" e poi "mount /dev/sda2 /tmp/dummy_root".
Dentro "/tmp/dummy_root" ci trovi "/var/log", senza l'overlay
mount fatto in precedenza, cancelli i file, smonti "/tmp/dummy_root"
e la cancelli...
bye,
-- 
piergiorgio

 e la cancelli...
Quando l'hai provato dimmi come è andata...


 Quando l'hai provato dimmi come è andata...
Lo ho appena provato, prima di postare, e
funziona benissimo, non vedo perche` non
dovrebbe...
bye,
-- 
piergiorgio

 "/var/log" originale da qualche altra parte e cancelli i file.
A questo punto, non credo sia neppure necessario rimontare tutto il
filesystem, ma solo bindare altrove la directory parente
(nell'esempio, /var) di quella a cui si vuole accedere. Infatti --
bind, a differenza di --rbind, NON si porta dietro i submount.
--
Bye, Lem

 dovrebbe...
Penso che i timori siano dovuti per lo piu` ad eventuali corruzioni
derivate, ad esempio, da un sync contemporaneo per i due mount point (da
questo punto di vista non so come si comporta il kernel)
Enrico

 dovrebbe...
Per un motivo banalissimo, ovvero che uno stesso filesystem montato R/W su 
due mountpoint differenti se acceduto dai due percorsi (immancabilmente) si 
corrompe.
Se lo hai fatto ti consiglio seriamente di spegnere la macchina e fare 
immediatamente un fsck, incrociando le dita di non aver sputtanato tutto; 
fino ad oggi non mi è MAI successo che un filesystem acceduto r/w da due 
mountpoint distinti non si corrompesse in modo più o meno serio.
L'ultima volta che ho fatto questa cosa per un banale errore (al posto della 
chiavetta sdc1 ho montato in /mnt la sdb1 che era la home) ho dovuto 
ripristinare tutto da backup.
Questo avviene banalmente perché le strutture dati del filesystem vengono 
tenute in cache, ma montando in due posti distinti lo stesso device le 
entries della cache sono separate per i due mountpoint e se le modifichi da 
una parte non vengono aggiornate dall'altra.
Ti ritrovi nella situazione che il S.O. ritiene valide le informazioni in 
cache ma queste non corrispondono alle informazioni sul disco, e alla prima 
scrittura di quelle info il FS si corrompe. Considera che una semplice 
lettura di un file comporta comunque un'operazione di scrittura se non hai 
montato il FS come noatime, quindi la corruzione è "garantita".
Per questo esistono filesystem appositi, come GFS, che gestiscono la 
concorrenza.


mallin.shetland ha scritto:

Beh, per leggere, nemmeno tanti danni, imho.
Leggere un device non impatta più di tanto.
Ma trovare dove reiser mette via i dati, ed arrivarci _nonostante_ il
filesystem, lo vedo dannoso per la pressione arteriosa. ;-)


 ...
Se hai letto bene si parla di cancellare dei file e non so come ci 
si possa riuscire limitandosi a leggere senza scrivere un bel niente
nei metadati e nelle directory del disco.
Io penso, quindi, che tu voglia fare così (vado di fantasia, non è  
una cosa che suggerisco):
1) Montare il filesystem in sola lettura
2) Accedere alle strutture dei metadati e della directory tramite
   i device scavalcando i driver del filesystem.
3) Fare le modifiche necessarie
4) Rimontare il filesystem in lettura/scrittura.
È difficile ma possibile. SOLO CHE A QUESTO PUNTO HAI CREATO UNA
INCONSISTENZA TRA I DATI SCRITTI SUL DISCO E QUELLI DELLA CACHE;
quando rimonti o fai un sync sputtani tutto il filesystem.
Ma hai letto i post di Enrico Bianchi e The Zipman?

 Se hai letto bene si parla di cancellare dei file e non so come ci 
Certo. Ero salito nel thread solo nel punto in cui giulia affermava,
come stupita, che i file "nascosti" c'erano e occupavano spazio, non
ho tenuto conto che non voleva solo trovarli, ma cancellarli.
Non so perchè, ad un certo punto del thread mi sono convinto che giulia
volesse accorpare i log precedenti e gli attuali. Errore mio.


 una parte non vengono aggiornate dall'altra.
Credo che la soluzione giusta sia usare bind.
Con --bind, appunto, il kernel mantiene coerenza e consistenza dei
dati.
Prendo un abbaglio?
--
Bye, Lem

 dati.
Esatto. Peraltro avevo scordato che bind si puņ usare anche dopo aver gią 
montato altri FS, come in effetti a posteriori ho riscontrato avvenire anche 
in flashybrid.


 concorrenza.
In generale, per design, il FS non si deve poter
corrompere con operazioni sul FS.
Se succede, vuol dire che c'e` un bug.
bye,
-- 
piergiorgio

 da due mountpoint distinti non si corrompesse in modo piů o meno serio.
Allora, giusto per precauzione ho fatto l'fsck,
che non ha riscontrato nulla di errato.
C'e` da dire, come fatto notare da Ghost, che la
directory sottostante non viene modificata da
nessuno ed il "ramo" in questione era montato
con "noatime", quindi leggervi non comporta
scritture.
A mio avviso, il VFS deve, o dovrebbe, tener
conto degli accessi tramite inode & puntatori.
Se vi e` una duplicazione di qualche mount
point dovrebbe accedervi sempre allo stesso
modo, garantendo cosi` la consistenza, ma
non la coerenza (dei dati).
Allo stesso modo per cui due processi che
scrivono nello stesso file non devono poter
causare danni al FS, al file magari si.
Oppure, cancellare un file mentre un altro
processo vi sta scrivendo dentro non deve
comunque portare a problemi con il FS.
Comunque, oltre questo, credo anche io che la
soluzione "bind" sia migliore.
bye,
-- 
piergiorgio

 causare danni al FS, al file magari si.
La corruzione si evita gestendo il lock dei file, che funziona perché il 
file è accedibile in modo univoco tramite il suo inode che è *unico* per 
ciascun file. Se tu avessi un'area dati puntata da due inode il locking non 
avrebbe effetto e il file potrebbe corrompersi in caso di doppia scrittura.
L'uso di mount -o bind è come fare un link al file, quindi un unico inode 
puntato da due entries di directory che permette la gestione del lock.
Il doppio mount invece è come avere due inode che puntano alla stessa area 
dati, e in tale caso non c'è nulla che si possa fare se non è previsto dal FS.


 ...
Credo sia meglio non parlare cose di cui non si conosce. 
Le mie conoscenze non entrano così a fondo nel kernel 
per cui non posso affermare che queste tue parole siano 
campate in aria oppure siano solo una analogia.
Per il momento sto approfondendo la questione in attesa
che qualche guru del kernel possa illuminarci.

 oppure siano solo una analogia.
Sono un'analogia.


 Secondo me
Secondo te?
Non mi pare particolarmente autorevole e rilevante.
Adoro coloro che cercano risposte dagli altri purchè siano
compatibili con l'ipotesi precostituita.

 ...
Qui fai un esempio che non calza.
Tu monti in loopback un file e poi fai hacking scrivendo
sul file con dd mentre il file è montato. 
In pratica stai aggirando il kernel. Non lamentarti se corrompi 
il file perchè stai facendo una cosa che non si fa. 
Lo ho detto prima in altri post: non è  una cosa molto intelligente.
Concludendo, penso che stiamo facendo due discorsi diversi.

 Lo ho detto prima in altri post: non è  una cosa molto intelligente.
Ho creato un file, gli ho creato sopra un filesystem, ho fatto un link 
fisico del file (test2) che quindi punta alla stessa area dati di test1, ho 
montato i due file (che sono poi lo stesso in realtà) su due mountpoint 
diversi (senza che il kernel se ne rendesse conto) e vi ho acceduto rw da 
entrambi. Ovvero quel che dicevo sopra e che si può fare in diversi casi.


 l'esempio.
Hai ragione, ho letto troppo frettolosamente.
Mi scuso.
Purtroppo non riesco a replicare la cosa sul mio sistema:
ottengo un errore in fase di creazione del filesystem.
Rimando la cosa ad un'altro giorno, quando svrò un po di 
tempo libero.

 previsto dal FS.
Mah, l'inode e` lo stesso, non sono due.
Secondo un mio collega, il problema sarebbe invece
piu` in basso, nel device driver, piu` che nel FS.
Puramente accademico, a questo punto.
bye,
-- 
piergiorgio

 piu` in basso, nel device driver, piu` che nel FS.
Non penso possa essere così in basso perché è qualcosa di indipendente dal 
tipo di device cui accedi, avviene su qualsiasi tipo di device a blocchi, 
che sia scsi, usb, ide, loop, FC, aoe, ecc.ecc.


 blocchi, che sia scsi, usb, ide, loop, FC, aoe, ecc.ecc.
Appunto, sono tutti block device, hanno lo stesso framework.
Comunque sia, come gia` detto, e` puramente accademico, dato
che la soluzione "ufficiale" e` con "bind".
Infatti pare che sia proprio documentato di usare il bind
mount per risolvere il problema del OP.
bye,
-- 
piergiorgio

 Non lo prenderei a riferimento.
E' l'unico caso che tratta situazioni analoghe che mi è venuto in mente


 E' l'unico caso che tratta situazioni analoghe che mi è venuto in mente
AFS? OCFS2? Lustre?
Enrico