Newsgroup: it.comp.os.linux.iniziare
Titolo: reiserfs opzione -j

leggo dal man:
-j | --journal-device FILE
               FILE is the name of the block device on which is  to  be 
  places
               the filesystem journal.
cioè se voglio che il journal di sda1 venga messo in sdb2dovrei fare qlc 
tipo
mkfs.reiserfs --journal-device /dev/sdb2 -B /dev/sda1
è giusto?
e che succede se non trova sdb2?
il semplice
mkfs.reiserfs -B /dev/sda1
mi crea un fs senza journaling?
r
-- 
Abruzzo 2009: dopo 162 giorni consegnati 47 chalet per 200 persone.
Irpinia 1981: dopo 122 giorni consegnati 150 chalet per 450 persone.
Un Minuto Per Favore:
Home Page, The Pentangle, I Salon di Baudelaire: 
http://www.umpf.net

 mi crea un fs senza journaling?
No, se non specifichi diversamente il journal vien messo sullo stesso
device del filesystem.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________________________
Non sprecare i cicli idle della tua CPU: 
http://boinc.berkeley.edu/index.php

 device del filesystem.
ok, ma la riga
mkfs.reiserfs --journal-device /dev/sdb2 -B /dev/sda1
è corretta?
oppure dev'essere
mkfs.reiserfs -j --journal-device /dev/sdb2 -B /dev/sda1
?


 mkfs.reiserfs --journal-device /dev/sdb2 -B /dev/sda1 è corretta?
Sì.
Puoi scrivere
-j /dev/sdb2
oppure
--journal-device /dev/sdb2
(sono equivalenti).


 (sono equivalenti).
ok, non appena arriva la nuova macchina provo e ti saprò dire i danni 
cusati ;-P
r


 cusati ;-P
Siccome son curioso, ti chiedo come hai deciso di organizzare il fs su
dischi e partizioni.
Te lo chiedo anche perché, per esempio, secondo me ha senso separare un
journal dal suo fs solo se lo si vuol mettere su un disco diverso: così si
guadagna in prestazioni.


 guadagna in prestazioni.
più che per le prestazioni è per cercare di scrivere il meno possibile 
nella partizione di / che sarà su SSD;
metterò su HD anche /var e /tmp;
a quanto ho capito sto esagerando, ma ritrovandomi con due HD e un SSD 
tanto vale sfruttarli;
a tal proposito: posso trasformare da primaria in estesa una partizione 
qls oppure dev'essere l'ultima?


 mkfs.reiserfs --journal-device /dev/sdb2 -B /dev/sda1
Scusa, manca qualcosa dopo -B: il file che contiene la lista dei
badblocks:
mkfs.reiserfs --journal-device /dev/sdb2 -B listabadblocks /dev/sda1
Il file che contiene la lista dei badblocks lo generi così:
/sbin/badblocks -b 4096 -o listabadblocks /dev/sda1


 dev'essere l'ultima?
Una qualsiasi partizione primaria può essere estesa, non è necessario che
sia l'ultima.


 /sbin/badblocks -b 4096 -o listabadblocks /dev/sda1
Anche se ho parecchi dubbi che sia una bella cosa usare
badblocks su uno SSD.


 badblocks su uno SSD.
ma i badblocks non sono i blocchi segnati come inusabili?
una volta segnati, amen, no?
oppure sono altro?
r


 badblocks su uno SSD.
Perchè, se è lecito?
bye!

 Perchè, se è lecito?
Perché:
a) usandolo in modalità di default - solo lettura - direi che serve a poco
o niente su un SSD (che magari ti dà una lettura sbagliata se le celle di
memoria son scassate, ma qualcosa ti restituisce comunque - anche i test
sulla ram, che abbiano qualche significato, son tutti a scrittura-lettura,
no?, mica solo a lettura);
b) usandolo in modalità read-write, distruttiva o meno, deve cancellare
e riscrivere ogni blocco. Ma sappiamo che il processo di cancellazione,
sugli SSD, è una cosa tutta particolare: non si cancella veramente, si
scrive altrove fino a necessità o fino al trim, e l'unità minima di
cancellazione è un multiplo del settore (che invece è l'unità minima di
scrittura)... Il che mi pare creare qualche problema a badblocks.
Piglia con amplissimo beneficio d'inventario quel che ho scritto, eh!


 scrittura)... Il che mi pare creare qualche problema a badblocks.
Hm, questo è plausibile. Mi devo informare meglio, che tanto prima o
poi gli SSD diventeranno comuni...
bye!

 dischi e partizioni.
a quanto pare non potrò usare il reiserfs, come pensavo:
Because ReiserFS still uses the Big Kernel Lock (BKL) --- a global 
kernel-wide lock --- in some places, it does not scale very well[3] for 
systems with multiple cores, as the critical code parts are only ever 
executed by one core at a time.
a questo punto che fo? uso ext2 o ext4 senza journal?


 a questo punto che fo? uso ext2 o ext4 senza journal?
Poiché in lettura i fs non si scassano, direi che per l'uso che ne vuoi
fare anche il recente ext4 è perfettamente sicuro. E ha i suoi vantaggi,
naturalmente. :)


 naturalmente. :)
ho trovato qlc pagina in rete che consiglia di usarlo;
ok, metto questo, inoltre /var e /tmp su disco normale e partiziono 
l'ssd lasciando 3 giga d'avanzo: a quanto pare è un buon trucco per 
ritardare il degrado delle prestazioni;


 Poiché in lettura i fs non si scassano, direi che per l'uso che ne vuoi
]zac[
Uh! .. io la mano sul fuoco non ce la metterei ....

 Uh! .. io la mano sul fuoco non ce la metterei ...
Io do per scontato che lo si monti con noatime.
Se eliminiamo del tutto le scritture, il fs non cambia. Se non cambia,
non può rovinarsi. Dici che non torna?


 non puÃ² rovinarsi. Dici che non torna?
be', l'OS può far casini nel montare la partizione, credo;
r
-- 
per snellire i processi non servirebbe annullare la prescrizione una 
volta iniziati? gli imputati non avrebbero interesse a tirarla per le 
lunghe;


  
dimenticavo: tmp e var saranno su disco normale, è vero, ma anche così 
qlc deve pur scrivere all'avvio, tipo mtab e /dev;
cmq stiamo postillando, a quanto pare anche usandolo come un HD solito 
un SSD dovrebbe durare di più, se quello che leggo in giro ha un po' di 
fondamento;


 e anche nodiratime ;-P
Yep, ma è implicato da noatime. :)


 fondamento;
Non ci piove: riscrivere mtab&C non compromette l'SSD per almeno qualche
miliardo di anni. ;)


 La Slack non monta un tmpfs su /dev? Mi pare di sÃ¬.
forse sì:
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       defaults         0   0


 non può rovinarsi. Dici che non torna?
Torna torna, ma il fatto è che ci sono anche i crash, i bugs, gli
spegnimenti brutali, ecc., e in questo casi non è per niente impossibile
che possa succedere qualche disastro ..

 che possa succedere qualche disastro ..
Lei non mi è ottimista, mi consenta... ;)))


 ok, metto questo [ext4]
Allora, per il controllo dei badblocks, è sufficiente usare l'opzione -c
direttamente quando crei il filesystem.
mkfs.ext4 -c ... (controllo read-only)
mkfs.ext4 -cc ... (controllo read-write, eviterei su SSD).
