Newsgroup: it.comp.os.linux.sys
Titolo: Cancellazione sicura di _file_? Ma quando mai!?

Ho testé ripetuto su ext4 un esperimento tentato un anno e mezzo
fa su ext3, ed il risultato è lo stesso.
 
lem@biggy:/media/IBOX$ echo se mi leggi sei nei guai > indelebile
 
lem@biggy:/media/IBOX$ cat indelebile
se mi leggi sei nei guai
 
lem@biggy:/media/IBOX$ sync
 
lem@biggy:/media/IBOX$ sudo debugfs /dev/mapper/VGDATA-LVIBOX
debugfs 1.41.14 (22-Dec-2010)
debugfs:  stat indelebile
 
Inode: 12   Type: regular    Mode:  0664   Flags: 0x80000
Generation: 1470193940    Version: 0x00000000:00000001
User:  1000   Group:  1000   Size: 25
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x4eadb1c1:ab160cbc -- Sun Oct 30 21:21:21 2011
 atime: 0x4eadb1c1:ab160cbc -- Sun Oct 30 21:21:21 2011
 mtime: 0x4eadb1c1:ab160cbc -- Sun Oct 30 21:21:21 2011
crtime: 0x4eadb1c1:ab160cbc -- Sun Oct 30 21:21:21 2011
Size of extra inode fields: 28
EXTENTS:
(0):32894
(END)
Q
debugfs:  quit
 
So già che il blocksize del fs è 4kB, quindi ho quel che mi
serve per leggere i dati dal raw device.
 
lem@biggy:/media/IBOX$ sudo dd if=/dev/mapper/VGDATA-LVIBOX bs=4096 skip=32894 count=1
se mi leggi sei nei guai
1+0 record dentro
1+0 record fuori
4096 byte (4,1 kB) copiati, 0,0540127 s, 75,8 kB/s
 
Ora la cancellazione "sicura".
 
lem@biggy:/media/IBOX$ srm indelebile
 
Sincronizzo (e poi ho pure letto e scritto qualche GB di altra
roba dal fs).
 
lem@biggy:/media/IBOX$ sync
 
lem@biggy:/media/IBOX$ cat indelebile
cat: indelebile: File o directory non esistente
 
Quindi srm sullo specifico file funziona? Ma no! Infatti i
dati sono sempre lì, puliti puliti:
 
lem@biggy:/media/IBOX$ sudo dd if=/dev/mapper/VGDATA-LVIBOX bs=4096 skip=32894 count=1
se mi leggi sei nei guai
1+0 record dentro
1+0 record fuori
4096 byte (4,1 kB) copiati, 1,9774e-05 s, 207 MB/s
 
È stato solo liberato l'inode: secure delete un fico secco,
almeno per quanto riguarda i file (diverso sarebbe stato,
ovviamente, dare una passata al device intero).
 
Ma quel che mi chiedo è: allora srm *dove* diavolo ha scritto e
sovrascritto? Dove? Perché le sue trenta e più passate le ha date,
eh! Mi ha fatto aspettare due secondi.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_________________________________________________________________
Non sprecare i cicli idle della tua CPU, né quelli della tua GPU.
http://cleanenergy.harvard.edu/
 
http://spin.fh-bielefeld.de/
 
 
http://www.gpugrid.net/
 

 4096 byte (4,1 kB) copiati, 1,9774e-05 s, 207 MB/s
 
Mmmmhhh...
 
Sono un coglione. È bastato smontare e rimontare il fs.
Tutto a posto, chiedo scusa.


 ovviamente, dare una passata al device intero).
 
Non so nulla di srm ma mi piacerebbe sapere se riavviando il pc il file 
risulta ancora li?
 
Nicola.
 
-- 
chi va pian va san e va lontan

Il 30/10/11 22:53, NicoKid ha scritto:

Beh quando rebooti Linux smonta (e rimonta) i vari fs, quindi 
teoricamente si.
 
Cmq io sto pensando che srm se usato su un server di produzione (che 
hanno uptime anche lunghetti), magari sotto un fs di quelli che non è 
che puoi smontare cosi per cosi come /usr /var /opt... non è che sia 
proprio efficace efficace...
 
P.S. Considero gia rm un comando da vietare su server in 
produzione...figurarsi srm...ho visto piu restore essere invocate da rm 
asteriscati che da disastri naturali...

 risulta ancora li?
 
No, come ho scritto nel mio secondo messaggio è bastato smontare
e rimontare il fs per veder sparire i dati. Quindi srm *ha*
funzionato, e gli spettano le mie scuse.
 
L'altissima velocità di lettura dei dati del secondo dd - che prima
non avevo notato - mi ha fatto capire che i dati venivano fuori dalla
cache - nonostante i sync e il fatto d'aver letto e scritto diversi
GB di altre cose nel frattempo.
 
 
Mi sa che dovrei documentarmi con un po' di serietà su come funziona
nei dettagli 'sta cache del disco, perché quanto successo mi suggerisce
alcune ipotesi e alcuni interrogativi interessanti su come sia
mappata questa cache rispetto al disco. Io - senza averlo mai saputo
davvero - m'immaginavo fosse mappata sui settori, per la serie: la
chiamata al fs porta il SO ad individuare i settori, che poi vengono
letti o dalla cache - se ci sono - o dal disco. Ma pare non possa
essere così: la cache del disco è quindi, in realtà, la cache del fs?
Sta sopra il fs, e non sotto?
 
BTW: sto scrivendo un sacco di boiate, mi sa. Che dite? Meglio se
smetto di scrivere, e invece comincio a leggere? ;-p


 Sta sopra il fs, e non sotto?
 
Immagino sopra, per fare il caching dei file, non dei settori.
 
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
 
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 
 
 

 GB di altre cose nel frattempo.
 
Penso che tutti noi avessimo intuito che c'era una cache di mezzo. Però mi 
piacerebbe sapere se con smem o sswap (gli altri tools citati con srm) si 
riesce a rasare la cache senza dover smontare la partizione: es. server in 
produzione.


 teoricamente si.
 
Chiaro, ma non ero sicuro che bastasse l'umount. Non so nulla di filesystem 
:O


 es. server in produzione.
 
Provato ora: sì, sdmem -ll ha avuto lo stesso effetto che smontare e 
rimontare il fs. Ha quindi fatto fuori la cache.


 Immagino sopra, per fare il caching dei file, non dei settori.
 
Eppure ora vedo che anche quello che leggo con dd, direttamente
dal raw device, va in cache. E ci resta finché non smonto/rimonto
il fs.
 
Dettaglio.
 
Cancello il file con srm. Finché non smonto/rimonto il fs, riesco a 
recuperarne il contenuto con dd.
 
Smonto/rimonto il fs: ora con dd vedo la roba casuale scritta da srm.
 
Ora ricreo il file, sempre con:
 
$ echo se mi leggi sei nei guai > indelebile
 
Il file finisce nello stesso blocco di prima.
 
Con dd continuo a leggere la roba casuale scritta prima da srm! :-o
Smonto/rimonto il fs, ed ecco che con dd leggo "se mi leggi sei nei guai".
