Newsgroup: it.comp.os.linux.sys
Titolo: Qmail, problema con Dir. stracolma, limite ext3 ? ..

Ciao, devo trasferire un server di Posta basato su Qmail.
Nella Maildir di un utente, ho la dir "cur" stracolma di messaggi.
da un ls mi da questo:
drwx------ 2 vpopmail vchkpw 156643328 16 apr 00:54 cur
se ci entro naturalmente il comando ls non va ..
Mi è stato concesso di tenere i messaggi del 2010 ..
quindi ho provato a sfoltire con un
find /home/vpopmail/domains/xxxxx.cxm/postmaster/Maildir/cur/ -mtime
+110 -type f -exec rm -f {} \;
dopo circa 9 ore di attesa, il risultato è che ora la dir risulta
vuota,
ma ls da il medesimo valore
drwx------ 2 vpopmail vchkpw 156643328 16 apr 00:54 cur
df è ok e anche df -ai
Limite di ext3 ? FS sminchiato ?
Cosa consigliate di bello ?
Grazie 1000
dimenticavo, questo è il tune2fs -l
tune2fs 1.39 (29-May-2006)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          ac6a3c86-c5af-4109-8b80-0c427d785af2
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype
needs_recovery sparse_super large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              60948480
Block count:              121893179
Reserved block count:     6094658
Free blocks:              119853968
Free inodes:              60945240
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      994
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Wed Mar 19 17:25:49 2008
Last mount time:          Wed Apr  9 18:43:35 2008
Last write time:          Wed Apr  9 18:43:35 2008
Mount count:              13
Maximum mount count:      20
Last checked:             Wed Mar 19 17:25:49 2008
Check interval:           15552000 (6 months)
Next check after:         Mon Sep 15 18:25:49 2008
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      d2068142-3213-40f3-b9d7-a7286fb6b135
Journal backup:           inode blocks
-- Yena --

 ...
Ed allora? Non sai che devi compattare la directory?
È una cosa da .iniziare, crea una nuova directory e 
sposta tutti file dalla vecchia alla nuova.

 drwx------ 2 vpopmail vchkpw 156643328 16 apr 00:54 cur
]zac[
Grossolanamente la dimensione della directory è lo spazio allocato per 
contenere la lista dei file presenti nella directory.
In vari file system, compreso ext3, lo spazio allocato per la lista dei file 
della directory viene solo ingrandito, mai ridotto.
Nota che nel tuo caso, al massimo puoi considerarlo uno spreco di spazio di 
156Mb, e che man mano che la directory torna ad avere file al suo interno, 
lo spreco si riduce.
In ogni caso se proprio vuoi recuperare quello spazio l'unica soluzione è 
creare una nuova directory ed eliminare l'attuale.
Ci sono anche dei programmi di defrag del filesysten ma non ho idea se 
funzioni o diano problemi.

 drwx------ 2 vpopmail vchkpw 156643328 16 apr 00:54 cur
a parte il consiglio che ti hanno dato (creare nuovamente la directory) 
questo succede perché non usi vxfs e xfs che hanno dei tool di defrag.
Con questo non ti sto invogliando a usare tali filesystem.
E fra l'altro (ti do i miei due centesimi) ho dovuto constatare che xfs:
1. ciuccia tantissima CPU e un computer con CPU scarsa ne risente.
2. è lento in maniera assurda nella cancellazione di piccoli file
3. è lento nella sovrascrittura di un file (conviene cancellare un file 
e crearlo nuovamente)
4. xfs è robusto, ma se hai minimi problemi con il driver del 
controller, il risultato con xfs può essere anche disastroso.
5. dopo aver montato directory con l'opzione "-o bind" diverse volte mi 
sono ritrovato strani casini.
6. ho avuto l'impressione che la delayed allocation in xfs fosse molto 
più spinta di quella di ext4. Oltre ad essere un fattore di rischio, il 
sync a volte prendeva tanto tempo.
Quindi adesso mi trovo benone con ext4.
Pazienza per il tool di defrag per ext4, che è ancora in stato beta, ma 
presto arriverà. E pazienza per xfsdump che è impareggiabile. E di 
xfs_freeze non me ne frega niente perché il campo di utilizzo era 
veramente ristretto.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo