Newsgroup: it.comp.os.linux.sys
Titolo: Fare un po' di luce su chattr

Allora, da poco ho conosciuto questo strumento, e già ho qualche dubbio
che non sono riuscito ad eliminare (o forse non so cercare tanto bene):
(da una pagina del man)
[...]
A file with the `c' attribute set is automatically compressed on the
disk by the kernel. A read from this file returns uncompressed data. A
write to this file compresses data before storing them on the disk.
* Da qualche parte ho letto che questa cosa non è ancora implementata.
Ci sono informazioni in merito? Dove le posso trovare? *
[...]
A directory with the 'T' attribute will be deemed to be the top of
directory hierarchies for the purposes of the Orlov block allocator
(which is used in on systems with Linux 2.5.46 or later).
* Da quanto ho capito riguarda la disposizione della directory
fisicamente sul disco, ma è un punto abbastanza oscuro... *
[...]
A file with the 't' attribute will not have a partial block fragment at
the of the file merged with other files (for those filesystems which
support tail-merging). This is necessary for applications such as LILO
which read the filesystem directly, and who don't understand tail-merged
files.
* Una sorta di "non frammentare il file"? *
[...]
When a file with the `u' attribute set is deleted, its contents are
saved. This allows the user to ask for its undeletion.
* Sorge una domanda: dove? E come lo recupero? *
Ultima fatale domanda: è disponibile solo per ext2/ext3 ? Oppure altri
FS supportano il comando (o hanno comandi simili)?
Enrico

 FS supportano il comando (o hanno comandi simili)?
anche ext4, JFS, ReiserFS e XFS 

 non so, non rispondo
Alcuni FS permettono di sfruttare anche lo spazio allocato ma normalmente
non sfruttato nell'ultimo blocco di un file.
P.es. su un FS con blocchi di 4K, un file di 5K occupa 2 blocchi, e 3K sono
inutilizzati. Alcuni FS permettono di utilizzare questi blocchi per
contenere la "coda" (tail) di altri files.
Su un filesystem normale come ext3 per esempio i 4 files di 5K occupano 8
blocchi quindi 32K. Su un filesystem che gestisca il tail merge invece
occupano solo 5 blocchi, quindi 20K, perché un blocco è in comune e contiene
la coda di tutti e 4 i files.
Se non erro reiserfs implementa un sistema così, ma non ricordo se è proprio
tail merging (ci sono diversi approcci al problema)
-- 
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.

 anche ext4, JFS, ReiserFS e XFS 
ReiserFS e JFS non supportano gli attributi estesi impostabili da
chattr, mentre ext4 li supporta in quanto evoluzione di ext3. Per quanto
riguarda il Tail Packing, e` si una strategia per diminuire la
frammentazione dei file, ma comporta una perdita significativa in fatto
di performance. ReiserFS supporta il Tail Packing di default, ma a causa
delle sue performance spesso viene montato con l'opzione notail (anzi,
se usato per la partizione root, l'opzione notail viene praticamente
usata nel 90% dei casi). Per informazioni piu` dettagliate, ovviamente
Wikipedia ne sa piu` di me: 
http://en.wikipedia.org/wiki/Tail_packing
Enrico

 chattr, mentre ext4 li supporta in quanto evoluzione di ext3. 
come no?
monta reiserfs con attrs. jfs non ha bisogno di opzioni.

gt wrote:

Confermo, nella suse viene montato di default con le opzioni:
 acl, user_xattr
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 monta reiserfs con attrs. jfs non ha bisogno di opzioni.
Appena provato. Questo per ReiserFS:
ebianchi@montgomery:/tmp/a$ ls
test
ebianchi@montgomery:/tmp/a$ mount|grep reiser
/tmp/test.img on /tmp/a type reiserfs (rw,loop=/dev/loop0,user_xattr)
ebianchi@montgomery:/tmp/a$ lsattr 
lsattr: Inappropriate ioctl for device While reading flags on ./test
ebianchi@montgomery:/tmp/a$ 
Questo per JFS:
ebianchi@montgomery:/tmp/a$ ls
test
ebianchi@montgomery:/tmp/a$ mount|grep jfs
/tmp/test.img on /tmp/a type jfs (rw,loop=/dev/loop0)
ebianchi@montgomery:/tmp/a$ lsattr 
------------------- ./test
ebianchi@montgomery:/tmp/a$ chattr +i test 
chattr: Permission denied while setting flags on test
ebianchi@montgomery:/tmp/a$ su -c "chattr +i test "
Password: 
ebianchi@montgomery:/tmp/a$ lsattr 
----i-------------- ./test
ebianchi@montgomery:/tmp/a$ su -c "echo prova > test"
Password: 
bash: test: Permission denied
ebianchi@montgomery:/tmp/a$ 
Ora, per quanto riguarda JFS devo ammettere che ricordavo male. PEr
quanto riguarda invece ReiserFS, o user_xattr non funziona, o lsattr ha
problemi (non ho provato un chattr, pero`)
Enrico
P.S. la distribuzione e` Debian Lenny con kernel 2.6.26, e2fsprogs
1.41.0, reiserfsprogs 3.6.19 e jfsutils 1.1.12

 ebianchi@montgomery:/tmp/a$
Mi hai fatto "spaventare" anche da me lo stesso errore ma come aveva giustamente suggerito gt, va montato con l'opzione 'attrs'.
Boh, anche man mount riporta user_xattr come opzione per abilitare gli attibuti estesi..
Il mistero si infittisce :)


 Il mistero si infittisce :)
Sono due cose completamente differenti.
Con attr abiliti il supporto ai normali attributi, ovvero delle flags fisse
associate ai files.
Con user_xattr abiliti il supporto agli attributi estesi, ovvero delle
coppie nome:parametro associate ai files.
I primi li gestisci con (ch|ls)attr i secondi con ([gs]etf)?attr


 I primi li gestisci con (ch|ls)attr i secondi con ([gs]etf)?attr
Ricapitolando ( e semplificando..), abbiamo:
1) ACL - che "estendono" i normali permessi unix, permettendo una maggiore granularità
2) ATTRIBUTI (attr) - flag tipo "immutabile"
3) ATTRIBUTI ESTESI (user_xattr) - una sorta di "tagging" ?!?
Ci siamo ?!?


 Ci siamo ?!?
+ o -
PERM:ACL=ATTR:XATTR
Gli attributi estesi vengono per esempio usati per memorizzare informazioni
da stackable filesystem, da software di sicurezza, ecc.ecc.


 giustamente suggerito gt, va montato con l'opzione 'attrs'.
A questo punto la domanda corretta e`: perche` la man page di mount non
riporta attrs tra i parametri di mount per ReiserFS? Una svista?
Enrico

 Enrico
in realtà in man mount c'è un rimando ad una documentazione più completa:
"The reiserfs mount options are more fully described at
http://www.namesys.com/mount-options.html
"
file che si può trovare nella documentazione di reiserfsprogs.
per quale ragione ci sia questo rimando lo ignoro.

 
le ACL sono degli attributi estesi, così come le policy di SELINUX

 per quale ragione ci sia questo rimando lo ignoro.
La cosa paradossale e` che non e` possibile accedere a quella pagina (o,
almeno io, oggi non ci sono riuscito). L'unica maniera per vederla e`
stato andando su Interne Archive. Tra l'altro, riporta le opzioni attrs
e noattrs, ma non riporta nemmeno uno straccio di descrizione sul loro
funzionamento
Enrico

 che non sono riuscito ad eliminare (o forse non so cercare tanto bene):
Puoi usare l'attributo i quando vuoi evitare che un file venga cancellato,
anche un processo che gira come root (ovviamente tale processo potrebbe poi
dare chattr -i, questa non è infatti una norma di sicurezza ma un modo per
aggirare dei bachi). Il resto non è implementato, non serve o non funziona.
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname
http://bitsandchaos.wordpress.com

 Il resto non č implementato, non serve o non funziona
Oddio, gli attributi A, D, j e forse s (se quest'ultimo fosse
implementato) possono risultare comodi. Di tutti gli altri implementati,
in effetti, non ne vedo una grossa utilita` (seriamente, ma chi e` che
usa ancora dump per il bakcup dei file?)
Enrico

 usa ancora dump per il bakcup dei file?)
Nulla vieta ad altri sw di backup di rispettare quella flag.
