[Linux-Biella] Cron log

PaulTT paultt a bilug.it
Ven 26 Ago 2016 11:48:08 CEST


On 23/08/2016 13:22, Jumping Jack wrote:
> On 23/08/2016 10:37, vallini.daniele a bilug.it wrote:
>> Sun, Aug 21, 2016 at 09:55:43PM +0200 Jumping Jack ha scritto:
>>
>>> Potrebbero esserci errori non ho potuto verificare tutte le condizioni
>>> ovviamente.
>> Ho letto lo script e sono rimasto un po' perplesso, ti funziona e 
>> proprio
>> come desideri?
> Per quel che riguarda l'output no, scrive su un file di log e non 
> proprio quello che volevo.
> Però lo ottengo con due comandi attivando il log e la lettura su 
> terminale, solo se il file è già presente.
> Insomma è un accrocchio che può andare bene, in fondo ho aggiunto più 
> informazioni per cui potrei lasciare il log sempre attivo (anche se un 
> server lo fa su ssd e non mi va).
> Cosa fa invece inizia a deframmentare specificando il target (quindi 
> fa solo una passata su tutti i file, come ho scritto sull'altra email) 
> se la frammentazione è dal 6% in su poi controlla se è oltre il 20%, 
> in quel caso considera il disco molto frammentato e inizia a fare più 
> passaggi fino a che non scende a 20% o meno (o al massimo 9 volte) e 
> poi fa ancora una passata finale. Questo per ogni partizione xfs.

boh io mai deframmentato un piffero ;)
a parte che non ho mai il computer fermo, per cui non ha senso...

>
>>
>> Circa il confronto fra xfs ed ext3 o 4 hai rilevato differenza nella
>> ricostruzione dopo crash?
> Con xfs il disco deve essere offline e il recupero è stato totale. Con 
> ext4 invece non ho capito come funziona e una volta sembrava tutto 
> andato, poi ad un certo punto ha ricominciato a funzionare (dopo il 
> secondo o terzo boot durato una infinità di ore)
> Con btrfs invece 0 problemi.
si', xfs ci mette un nanosecondo, in confronto a ext, a ritirarsi su, e 
scannare il disco
ext millemila anni, e in piu' te lo forza ogni N riavvii, xfs no

con btrfs io invece avuto qualche grana, il driver nel kernel mi e' 
crashato alcune volte, ma lo ho usato su dischi esterni

>>
>> Il journaling mi pare confrontabile e l'esistenza di inode inutilizzati
>> in ext che cambia?
> Non lo so non ho solo valutato prestazioni in lettura/scrittura con 
> disco pieno o pienissimo e disconnessioni elettriche.
>
>>
>> Puo' essere che occupino un po' piu' di spazio e rallentino e2fsck ma 
>> non
>> vedo come inode non connessi a dati possano creare problemi nella
>> ricostruzione dopo crash.
> Infatti non ci sono problemi di non fattibilità, la differenza è avere 
> una macchina che non funziona per una vita (ext), che non funziona per 
> poco tempo anche se il recupero va fatto a mano (xfs), che funziona 
> sempre (btrfs)
> In ogni caso non userei xfs per /, ma proprio da specifiche è 
> sconsigliato, quindi il problema non si pone :)
> Potrei definire ext una via di mezzo tra prestazioni e sicurezza tra 
> xfs e btrfs.

io voto xfs :D

-- 
It is a good day to die. But the day is not yet over.

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <https://list.bilug.it/pipermail/linux/attachments/20160826/878b5ec2/attachment.html>


Maggiori informazioni sulla lista Linux