| View previous topic :: View next topic |
| Author |
Message |
Luca89
Advocate
Joined: 27 Apr 2005
Posts: 2107
Location: Agrigento (Italy)
|
 Posted: Wed Sep 27, 2006 12:54 pm Post subject: |
 |
|
| newred wrote: | Il pc � precisamente un k6-2 a 500Mhz con 512mb di ram e 2 hd seagate da 120
Ora... come � meglio suddividere lo spazio; inizialmente avrei pensato cos�
1-100Mb /boot --Raid1 ext2
2-1Gb swap --Raid0
3-40Gb /home --Raid1 ext3
4-5Gb /root --Raid1
5-2Gb /var --Raid1
6-3Gb /usr --Raid1
7-70GB /amule
|
Io Farei:
8Gb / - root in raid1 xfs o ext3, ti consiglio il primo, leggiti i thread nella documentazione del furum che spiegano come formattarlo al meglio
1Gb swap - niente raid, non credo sia necessario
111 Gb /home - raid1 xfs o ext3, io probabilmente metterei xfs, molto affidabile, se però non vuoi addentrarti in xfs, metti ext3 che è sicuramente più testato
_________________
Running Fast! |
|
| Back to top |
|
 |
newred
n00b
Joined: 24 Aug 2006
Posts: 25
|
| Posted: Wed Sep 27, 2006 1:01 pm Post subject: |
|
|
Sicuramente sotto raid1 ci finirà la home , dato che conterrà tutti i documenti condivisi e personali dei vari utenti ; ma finchè ci sono preferisco metterci anche il s.o. dato chenon credo siano quei pochi giga per il raid che facciano la differenza....Infatti se devo riavviare il pc ,no problema , ma se ci corrompe il so mi romperei un pò ad reinstallarlo..
Mentre per lo spazio di amule ho pensato di non metterlo in raid , dato che ogni cosa che finisco di solito la masterizzo e nel malaugurato caso si corrompa qualcosa...sfiga e si riscarica...
Le partizioni da 70Gb sarebbero 1 per amule e l'altra per la musica o i film che voglio tenere da vedere... anche se nè ho già una copia su hd..
Quindi oltre a home quali dovrei mettere in raid1 per non perdere il s.o. ??
L'area di swap dovrebbe essere messa in raid0 da quello che è scritto nella guida o sbaglio? |
|
| Back to top |
|
|
newred
n00b
Joined: 24 Aug 2006
Posts: 25
|
| Posted: Thu Sep 28, 2006 11:36 am Post subject: |
|
|
| Nessun altra opinione.... |
|
| Back to top |
|
|
newred
n00b
Joined: 24 Aug 2006
Posts: 25
|
| Posted: Thu Sep 28, 2006 2:12 pm Post subject: |
|
|
Mi sono informato leggendo un pò in giro e ho pensato a questa struttura
/dev/hda1 /boot ext2 32Mb raid1
/dev/hda2 swap 1Gb raid0
/dev/hda3 ext 50Gb
/dev/hda4 dati 69Gb
/dev/hda5 root 1Gb raid1
/dev/hda6 home 37Gb raid1
/dev/hda7 usr 6Gb raid1
/dev/hda8 var 3Gb
/dev/hda9 tmp 3Gb
Stavo pensando.. per un server una volta compilato tutto var e tmp vengono usate molto , perchè pensavo che si potrebbe anche evitare di metterle in raid e metterle 1 su hda e l'altra su hdc
Cosa ne dite? |
|
| Back to top |
|
|
Luca89
Advocate
Joined: 27 Apr 2005
Posts: 2107
Location: Agrigento (Italy)
|
| Posted: Thu Sep 28, 2006 5:34 pm Post subject: |
|
|
Un partizionamento molto segmentato (/usr, /var, /boot) te lo sconsiglio se non usi lvm, perché a priori non credo che ti venga facile sapere che spazio occupino tutte queste directory, quindi ti potresti trovare con partizioni sovradimensionate e altre sottodimensionate, per questo motivo io ti ho consigliato di fare un'unica partizione per la / e una per i dati (/home).
_________________
Running Fast! |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Fri Sep 29, 2006 7:58 am Post subject: |
|
|
A costo di ripetermi non vedo ASSOLUTAMENTE la necessità di avere tutte quelle partizioni.
Più partizioni crei più ti leghi le mani, se metti 3 gb per tmp e poi ti accorgi che non se mai riuscito a riempirla oltre i 100 mb significa che hai buttato più di 2,5 gb che magari srabbero stati più comodi sotto da un'parte, per esempio /var che potresti trovare troppo stretta quando vorrai usare ccache e dargli un paio di gb che non hai, oppure il contrario, avrai la var mezza vuota e tmp satura ...
A meno che tu non sia un masochista evita tutte quelle partizioni, eviterai di farti del male da solo !!!
Se poi per qualche strano motivo continui a pensare che più partizioni ci siano migliore diventi il tuo sistema allora buon divertimento ma dubito che ti divertirai molto quando ti accorgerai di aver drasticamente sbagliato il dimensionamento delle partizioni e ti toccherà riformattare 
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Fri Feb 23, 2007 8:56 pm Post subject: discussione sui filesystem |
|
|
@equilibrium:
[MOD]ho splittato la discussione originale del problema di LAj da quella sui filesystem. Chiedo per cortesia che la discussione sui FS venga continuata in questo topic, grazie.[/MOD]
quoto
Però ...
ho la vaga impressione che il partizionamento sia poco usato.
Personalmente non uso jfs perchè preferisco reiser ed xfs od al più ext2
partendo da un qualcosa come
/home
/ xfs
/tmp reiser (appena cambio il disco xfs)
/var xfs
/var/tmp/portage in /tmp
/usr/portage/distfiles reiser
/opt/prg (lo share dell'entratel e delle altre perverse macchinazioni windozziane di stato, ad esempio) in ext3 (con blocco a 512)
etc
non ho mai avuto grossi problemi, persino con un fileserver che si schianta ad intervalli regolari.
E continua a non sembrarmi troppo furbo usare un solo filesystem, sarò all'antica (il mio vecchio server unix aveva cinque partizioni in origine, swap root home tmp e usr) ma...
continuo a trovare molto pratico veloce ed affidabile reiser per contenere la contabilità o i documenti ed assolutamente negativo a lungo termine per portage o per la root e via dicendo.
In realtà il primo modo per evitare di perdere dati è costruire un partizionamento adeguato, dopo si possono maledire i fumatori d'oppio che hanno scritto il filesystem usato.
In più se ci sono diversi filesystem ci sarà pure un motivo oltre alla volontà di potenza dei devel per mantenerli in piedi.
Se vogliamo discutere delle differenze tra xfs, reiser, jfs, ext e via dicendo iniziamo a farlo pensando a quali dati vanno caricati sopra e non solo a sbatterci tutto il sistema, a quasto punto tanto vale usare un file in tmp come swap.
E ci sarebbe anche da pensare che il raid non è una soluzione valida a meno che non si abbia bisogno di un TB e passa di spazio contiguo e che un secondo HD costa poco...
IMHO
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est 
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Fri Feb 23, 2007 9:55 pm Post subject: |
|
|
Figurati che io trovo le 4 partizioni primarie eccessive per un solo sistema operativo ...
/
/boot
/home
Più partizioni significa più limiti auto imposti a priori, uno può anche valutare da usi precedenti quale potrebbe essere il trend e partizionare un nuovo sistema di conseguenza ma questo lo vincolerebbe a fare un uso sempre simile a quello che ha fatto in passato limitando quindi la possibilità di crescere e scoprire cose nuove.
Sovradimensionare tutte le partizioni (per avere spazio a disposizione per la crescita) d'altronde significa sprecare dello spazio a meno di ricorrere a link da una partizione all'altra.
Si potrebbe ricorrere a LVM per avere elasticità sulle dimensioni ma bisogna lasciare dello spazio libero già in partenza e non credo che a questo punto il gioco valga la candela.
Inoltre non tieni conto che tenendo fs diversi ti esponi a tutte le loro possibili debolezze contemporaneamente, aumentando notevolmente il rischio di perdita di dati e vorrei anche ricordare che in realtà il primo modo per evitare di perdere dati è fare backup frequenti. Un elevato numero di partizioni potrebbe proteggere lievemente solo nel caso in cui siano sempre smontate quando non usate comportando quindi molta più manutenzione e meno garanzie rispetto a backup schedulati frequentemente.
Il tutto ovviamente IMHO.
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
Sparker
l33t
Joined: 28 Aug 2003
Posts: 992
|
| Posted: Sat Feb 24, 2007 10:01 am Post subject: |
|
|
| !equilibrium wrote: |
| Sparker wrote: | E' una questione di design del file system. XFS, ad esempio, è progettato per utilizzare caching estremo per migliorare le performance e quindi in caso di
crash la probabilità di perdere dati è molto elevata. |
firulì firulà
orami questa è più una leggenda metropolitana che una realtà.
http://oss.sgi.com/projects/xfs/faq.html#wcache
le perdite di dati dopo uno shutdown forzato (parlo in generale) sono per la quasi totalità dei casi derivate dall'hardware piuttosto che dal FS in sè (vale per tutti i filesystem)
|
Da quel che ne so l'elevata probabilità di perdere i file aperti al momento del crash è dovuta alla scelta di scrivere di metadati nel journal prima della scrittura dei dati, come per i file system ext3 montati con politica writeback, e questo non assicura la consistenza dei dati con i metadati in caso di crash. Di default ext3 utilizza il sistema ordered che scrive dati e metadati in modo transazionale per assicurarne la consistenza. Finché XFS utilizza il writeback non mi puoi dire che la probabilità di perdere i file aperti sia minima. Poi sul fatto che il "problema" può essere accentuato da cattivo hardware sono d'accordo. "Problema" tra virgolette perché l'utilizzo del writeback è una scelta progettuale con motivazioni valide (scelta effettuata anche per JFS) |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Sat Feb 24, 2007 11:35 am Post subject: |
|
|
Iniziamo dalla questione della corruzione degli inode nel caso tipico del crash (non tanto per l'interruzione di corrente):
reiserfs si blocca ma può essere forzato (--rebuildtree con i rischi che comporta),
ext3 va avanti senza troppi problemi (ma sposta tutto in l&f con il conseguente casino e perdita di spazio)
xfs (ma anche jfs mi pare) richiede modifiche manuali.
va da se che contariamente alle solite leggende urbane reiser è quello che teoricamente ti espone di più ai crash mentre ext3 è quello più esposto al rischio di un bel disk full ed anche se non perdi i dati ti ci voglio a capire cosa sia ogni file hadgfhsca.jba che ti ritrovi, nell'uso normale (in cui non stai a controllare tutto).
A questo punto consideri che la root propriamente detta richiede poche modifiche, tutte ben circoscritte nel tempo mentre alcune aree (temporanee, cache etc.) hanno esigenze differenti.
Ed è chiaro che tutte le informazioni in tmp od in swap sono inutili dopo un crash se non ai fini del debugging.
La swap su partizione separata è il tipico esempio, esiste non per tradizione o perchè ci fossero dei particolari limiti all'epoca ma solo perchè è inutile esporre l'intero filesystem a rischi di corruzione per qualcosa di inutile al reboot come la swap. La stessa logica va applicata ad ogni tipo di informazione sul sistema.
Se dopo un crash ti si sputtana una partizione separata /tmp puoi anche pensare di modificare il check in rc di modo che ricrei il filesystem in automatico (prima di gentoo avevo un bel serverino lfs che si comportava così e la riformattava periodicamente) e quindi reiser va benissimo (ed anche con buona pace dei suoi problemi di frammentazione) od ancora meglio sarebbe ext2 in writeback.
Poi c'è la questione delle prestazioni (relative) e della frammentazione (ext3 ha prestazioni più costanti sul lungo termine, reiser degrada con il tempo, xfs richiede manutenzione), della dimensione minima dei file (ad esempio la mia procedura di contabilità ha qualcosa come 30k file di cui una buona metà più piccoli di 1kb, mortacci loro) e non ultima della necessità di limitare alcune aree di lavoro del filesystem al di fuori della gestione di quota o dell'area riservata all'owner di ext2/3 (cosa che apprezzerei molto anche negli altri fs).
Semmai il limite viene dal fatto che con il passare del tempo molte applicazioni hanno iniziato a creare le proprie aree di cache e tmp nella home utente e questo complica di molto la situazione.
Se li analizzi bene vedrai che ogni singolo fs è insuperabile per gestire una parte dell'albero di root ed una ciofeca od al più appena sufficiente per il resto. E che gestire lòa partizione unica è sempre un errore a meno che non usi il sistema per smanettare e provare ma quello è un altro caso, va da se che un disco od una macchina del genere non devono contenere nulla di utile. Ovviamente sono influenzato dal fatto che uso il pc per lavorare ed il tempo di ripristino (ma anche di backup, mica mi posso mettere lo stage 4 nell'rc) è un fattore critico.
Quanto ai limiti la distribuzione dello spazio è più o meno costante, poi se decidi di passare ogni due mesi da kde a gnome e viceversa solo per provare l'ultimo ritrovato la questione è diversa.
L'unica cosa che non ho ancora sperimentato ma mi intiriga è la gestione realtime subvolume di xfs e che ripercussioni può avere su eventuali altri filesystem in loopback, se qualcuno ha provato sare molto curioso di sapere.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
!equilibrium
Bodhisattva
Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC
|
| Posted: Mon Feb 26, 2007 1:29 pm Post subject: |
|
|
| Sparker wrote: | | Da quel che ne so l'elevata probabilità di perdere i file aperti al momento del crash è dovuta alla scelta di scrivere di metadati nel journal prima della scrittura dei dati, come per i file system ext3 montati con politica writeback, e questo non assicura la consistenza dei dati con i metadati in caso di crash. Di default ext3 utilizza il sistema ordered che scrive dati e metadati in modo transazionale per assicurarne la consistenza. |
la probabilità di perdita dei dati al momento del crash vale per tutti i filesystem che effettuano il journaling sui metadatas, ma la questione "writeback" non ha nulla a che vedere con i filesystem perchè non è un implementazione degli stessi, ma è una feature hardware del drive.
| Sparker wrote: | | Finché XFS utilizza il writeback non mi puoi dire che la probabilità di perdere i file aperti sia minima. Poi sul fatto che il "problema" può essere accentuato da cattivo hardware sono d'accordo. "Problema" tra virgolette perché l'utilizzo del writeback è una scelta progettuale con motivazioni valide (scelta effettuata anche per JFS) |
ripeto, il "writeback" è una feature hardware degli HD, non del filesystem. Se un drive ha un algoritmo di caching writeback scritto con il culo, la conseguenza immediata è un'elevata perdita dei dati in caso di crash. Questo però avverrà con TUTTI i filesystem. Faccio un esempio pratico, così è maggiormente chiaro il concetto:
[principio di funzionamento]
0 - l'utente scrive dei dati nel file A, B e C
1- il filesytem fa il flush dei metadata (file A,B e C) al sistema di log (journaling)
2- il loop del journaling manda ogni singolo file (A,B,C) all'HD
3- l'HD riceve il primo "buffer" di dati per il file A, lo scrive e ritorna al filesystem lo status di scrittura avvenuta
4- l'HD riceve il secondo "buffer" di dati per il file B, lo scrive e ritorna al filesystem lo status di scrittura avvenuta
5- l'HD riceve il terzo "buffer" di dati per il file C, lo scrive e ritorna al filesystem lo status di scrittura avvenuta
questo è il principio di funzionamento "utopico" dei filesystem di tipo journaling (tutti, nessuno escluso). Il problema della perdita dei dati in caso di crash si verifica SEMPRE dopo che il loop del journaling ha inviato TUTTI i dati all'HD, questo per colpa della feature "write back caching" degli HD. Perchè? il motivo è presto detto (tra l'altro l'ho già spiegato in altri posts), gli HD che hanno la feature writeback eseguono sì i punti 3,4,5 (vedi sopra), ma non scrivono i buffer sul disco immediatamente (in tempo reale), ma li tengono in "cache" fin quando tutto il buffer di caching è saturo, solo allora la feature di writeback effettuerà la scrittura reale dei dati. Nonostante i dati non siano stati scritti realmente sul disco, al filesystem viene *comunque* ritornato lo status di "scrittura avvenuta", il quale continuerà con il resto delle operazioni di I/O. Questo meccanismo è stato implementato in modo da garantire elevate prestazioni e ridurre al minimo la rotazione (e conseguente usura) del motore elettrico, ma se malauguratamente avviene un crash forzato nel momento in cui i buffer sono ancora nella cache write back, *zap* questi vanno persi irrimediabilmente, generando la fantomatica perdita di dati.
Ora vorrei che qualcuno mi spiegasse in modo semplice e chiaro come mai se la cache "write back" è una funzione hardware del disco rigido si da la colpa al filesystem delle perdite di dati in caso di crash forzato?
Sfatiamo un po di leggende metropolitane:
| Sparker wrote: | | Finché XFS utilizza il writeback non mi puoi dire che la probabilità di perdere i file aperti sia minima. |
il writeback caching è una feature specifica per gli ambienti server (derivata dagli iSCSI/FibreChannel), ha senso sui server perchè questi in genere hanno un'elevata concorrenza di processi I/O e sono costantemente sotto gruppo di continuità; non ha senso usarla su ambienti desktop a meno che non si usi un UPS, ma comunque i benefici riscontrabili in termini di aumento di performance sono minimi.
| djinnz wrote: | | In più se ci sono diversi filesystem ci sarà pure un motivo oltre alla volontà di potenza dei devel per mantenerli in piedi. |
- xfs è sviluppato da SGI per soddisfare le richieste dei suoi prodotti di storage e multimediali.
- jfs è sviluppato da IBM per soddisfare le richieste dei suoi prodotti di storage in ambito server e critical mission.
- zfs è sviluppato da SUN con lo scopo di ottenere scalabilità, sicurezza, performance sia per soluzioni storage (comprese le mission critical) che per quelle multimediali (uso desktop).
- reiserfs3/4 è stato sviluppato dalla namesys per le sue soluzioni basate su database XML e successivamente rilasciato alla community opensource.
- ext2/3/4 è stato sviluppato dalla community opensource per la community opensource; solo dalla versione 4 si può iniziare a considerare ext una valida alternativa a JFS/XFS (attenzione, ho detto "iniziare")
| Quote: | | nonostante tutte le precauzioni, ho avuto delle perdite di dati dopo un crash improvviso |
*NESSUN* filesystem è esente da perdita di dati, e *NESSUN* filesystem è in grado di fare miracoli: se stai scrivendo in un file e non pigi il pulsante "save" e ti capita un crash, non puoi di certo dare la colpa al filesystem se gli ultimi dati NON salvati non sono più presenti nel tuo HD (a dirla tutta, non ci sono mai stati...).
| Quote: | | nonostante tutte le precauzioni, mi si è corrotto XFS/JFS/ext/reiserfs/ecc |
può capitare, è rarissimo, ma può capitare, e nel 99% dei casi è dovuto al fatto che si sono corrotti i metadata del journaling presenti nella RAM e nel momento in cui questi vengono scritti sull'HD viene a crearsi una inconsistenza nel FS che presto o tardi può degenerare in una corruzione totale del FS. XFS/JFS hanno un sistema di protezione che previene il propagarsi della corruzione (rispettivamente modalità "freeze" e modalità "dirty"), limitando la perdita di dati ai soli metadata corrotti in RAM (quindi pochi Kb), ext/reiserfs3 no invece, soprattutto reiserfs3 il quale non ha nessun meccanismo interno di faul-tolerance. La vera domanda a questo problema non è "quale filesystem si corrompe di meno" ma piuttosto: "perchè diavolo i dati in RAM si corrompono!!??". Infatti, se ciò avviene è perchè c'è stato un problema hardware in RAM, tipico delle memorie EC, e non è quindi un problema del filesystem in sè. Il tutto si risolve usando memoria ECC e vedrete che la corruzione dell'intero filesystem sarà solo un brutto ricordo.
/EDIT:
magari a qualcuno può risultare interessante come lettura:
http://oss.sgi.com/projects/xfs/papers/xfs_filesystem_structure.pdf
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
| Back to top |
|
|
Scen
Retired Dev
Joined: 29 Jul 2003
Posts: 2470
Location: Padova, Italy
|
| Posted: Mon Feb 26, 2007 3:08 pm Post subject: |
|
|
Il mio stile di partizionamento su Gentoo è il seguente (adesso faccio innervosire Kernel78 ):
| Code: |
/boot ext2 max 100Mb
/ ext3 o reiserfs 1Gb
/usr ext3 o reiserfs da 5 a 10GB (dipende da cosa installerò e dall'HD)
/usr/portage reiserfs 500Mb
/tmp ext3 1Gb (lo so che sembrerebbe esagerato, ma vorrei pararmi il fondoschiena nel caso ci siano programmi che creano grossi file temporanei in /tmp)
/var ext3 2/3Gb
/opt xfs 5> Gb (se so che devo installare doom3 e quake4 ^_^ )
/var/tmp reiserfs a volontà, ci butto dentro anche /usr/src/tmp tramite symlink e $DISTDIR
/home reiserfs Gb a volontà :)
swap minimo 500Mb
|
Negli ultimi tempi sto notando, con un sistema quasi tutto su FS reiser3, un peggioramento delle prestazioni in lettura/scrittura, e leggendo qua e là mi pare di aver capito dipenda dalla frammentazione di reiserfs3 dopo un certo periodo (il mio è circa 2 anni di intense letture/scritture/cancellazioni).
Sto valutando di passare a ext3 o xfs per le partizioni più importanti dal mio punto di vista delle performance (/usr e /home).
_________________
I was born in a deep forest/I wish I could live here all my life/I am made from stones and roots/My home, these woods and roads
All my life I loved this sound/Of the woods all around/Eagles flies where the winds blows free
Journey is my destiny |
|
| Back to top |
|
|
Cazzantonio
Bodhisattva
Joined: 20 Mar 2004
Posts: 4514
Location: Somewere around the world
|
| Posted: Mon Feb 26, 2007 3:30 pm Post subject: |
|
|
| !equilibrium wrote: | | - ext2/3/4 è stato sviluppato dalla community opensource per la community opensource; solo dalla versione 4 si può iniziare a considerare ext una valida alternativa a JFS/XFS (attenzione, ho detto "iniziare") |
Perche'? Poverino... funziona tanto bene... 
_________________
Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne |
|
| Back to top |
|
|
!equilibrium
Bodhisattva
Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC
|
| Posted: Mon Feb 26, 2007 3:34 pm Post subject: |
|
|
| Cazzantonio wrote: | | Perche'? Poverino... funziona tanto bene... |
ehmmm...  non ho scritto da nessuna parte che non funziona.
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Mon Feb 26, 2007 3:37 pm Post subject: |
|
|
Più che innervosirmi non riesco a spiegarmi cosa spinga la gente ad un tale masochismo
Scherzi a parte, potresti postare anche un df -h ? così potremmo valutare quanto hai sfruttato lo spazio e quanto lo hai sprecato.
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
Scen
Retired Dev
Joined: 29 Jul 2003
Posts: 2470
Location: Padova, Italy
|
| Posted: Mon Feb 26, 2007 4:00 pm Post subject: |
|
|
Ti dò ragione al 100% sul fatto dello spazio sprecato, difatti so che la mia non è una soluzione molto ortodossa, (s)fortunatamente mi ha obbligato una volta sola, nel PC casalingo, ad una ripartizione del disco (fortunatamente avevo un secondo disco di appoggio, e non ho dovuto reinstallare nulla); forse la LVM-way potrebbe tornarmi utile, e sicuramente prossimamente proverò a fare qualche esperimento.
Riguardo al mio masochismo delle partizioni multiple, tendenzialmente lo faccio per evitare perdite di dati in caso di corruzioni di dati: cerco di dividere il partizionamento in modo "logico" (per me ), montando i vari rami della gerarchia del filesystem secondo certi criteri,es.
- /usr/portage tende a frammentarsi in modo pesante, causa continue letture/scritture dovute ai sync del tree
- /var contiene dati che variano spesso, e dati molto importanti (es. DB di Portage)
- /var/tmp qui ci butto dentro tutta la roba non importante, effettivamente potrei unificare /tmp e /var/tmp
 (mi è venuto in mente adesso  )
- /opt venendo qui installati i programmi binari, nel caso di programmoni sostanziosi (nel mio caso giochi come doom3 / quake4, oppure openoffice-bin), preferisco metterli in una partizione a sè
Comunque, esempio da un serverino di un'azienda a cui faccio un pò di assistenza:
| Code: |
# df -h
Filesystem Dimens. Usati Disp. Uso% Montato su
/dev/md/1 957M 127M 831M 14% /
udev 502M 336K 501M 1% /dev
/dev/md/2 9,4G 1,2G 8,2G 12% /usr
/dev/md/3 4,6G 443M 4,0G 10% /var
/dev/md/4 942M 18M 877M 2% /tmp
/dev/md/5 94G 33G 61G 35% /home
/dev/md/6 957M 252M 706M 27% /usr/portage
/dev/md/7 47G 3,2G 44G 7% /var/tmp
/dev/md/8 9,4G 272K 9,4G 1% /opt
shm 502M 0 502M 0% /dev/shm
|
_________________
I was born in a deep forest/I wish I could live here all my life/I am made from stones and roots/My home, these woods and roads
All my life I loved this sound/Of the woods all around/Eagles flies where the winds blows free
Journey is my destiny |
|
| Back to top |
|
|
!equilibrium
Bodhisattva
Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC
|
| Posted: Mon Feb 26, 2007 4:27 pm Post subject: |
|
|
| djinnZ wrote: | | Poi c'è la questione delle prestazioni (relative) e della frammentazione (ext3 ha prestazioni più costanti sul lungo termine, reiser degrada con il tempo, xfs richiede manutenzione) |
esattamente cosa intendi per "xfs richiede manutenzione" ?
| djinnZ wrote: | | L'unica cosa che non ho ancora sperimentato ma mi intiriga è la gestione realtime subvolume di xfs e che ripercussioni può avere su eventuali altri filesystem in loopback, se qualcuno ha provato sare molto curioso di sapere. |
non capisco il senso di "ripercussione su eventuali altri filesystem", non ne vedo proprio il nesso sinceramente.
il realtime subvolume di xfs è molto semplice come funzionamento, tutti i file marcati con l'attributo "realtime" vengono salvati su un driver diverso (appositamente specificato con mkfs.xfs) da quello in cui avvengono solitamente le operazioni di I/O. il barbatrucco sta tutto nel fatto che grazie ai gruppi di lettura/scrittura (chiamati AG) del filesystem, i file marcati realtime, sfruttano appieno il parallelismo di XFS e vengono scritti nel subvolume con priorità maggiori rispetto alle normali operazioni di I/O (leggasi = maggiori performance).
al fine del buon funzionamento dei realtime subvolume di XFS, i subvolume devono risiedere su drive fisici diversi da quello in cui avvengono le normali operazioni di I/O.
| djinnZ wrote: | | E continua a non sembrarmi troppo furbo usare un solo filesystem, sarò all'antica |
io ho delle perplessità nell'uso di molteplici filesystem sulla stesso disco. non tanto sulle scelte dei vari filesystem in sè, ma per il fatto che per ogni filesystem viene allocata un sacco di RAM per i metadata e i buffer di lettura/scrittura (XFS/JFS non sono poi così "parchi" di risorse). Non so quanto sia positiva come cosa, c'è un wasting inutile in memoria e si appesantisce pure lo sheduler del kernel visto che deve trattare con molteplici driver I/O (e quindi deve perdere maggiormente tempo a suddividire i dati nei relativi buffer). Non vorrei che le prestazioni guadagnate dalla suddivisione/ottimizzazione dei dati su molteplici filesystem, venga compensata o addirittura peggiorata dall'aumento della complessità dei processi di I/O introdotta dalla suddivisione stessa.
Detto ciò, resta valido quanto detto da @kernel78, corri il rischio di esporti inutilmente a tutte le loro possibili debolezze/bugs in contemporanea.
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe
all my contents are released under the Creative Commons Licence by-nc-nd 2.5 |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Mon Feb 26, 2007 4:37 pm Post subject: |
|
|
| Scen wrote: | | Riguardo al mio masochismo delle partizioni multiple, tendenzialmente lo faccio per evitare perdite di dati in caso di corruzioni di dati: cerco di dividere il partizionamento in modo "logico" (per me ), montando i vari rami della gerarchia del filesystem secondo certi criteri,es. |
Forse sono ingenuo io ma quale sarebbe la relazione tra più partizioni e minore perdita di di dati ?
Se usi un ups, un fs serio e non giochi con il kernel non rischi di perdere dati (e ripeto che un backup comporta maggior sicurezza e minor inconvenienti), viceversa ti esponi a dei rischi.
| Quote: |
| Code: |
# df -h
Filesystem Dimens. Usati Disp. Uso% Montato su
/dev/md/1 957M 127M 831M 14% /
udev 502M 336K 501M 1% /dev
/dev/md/2 9,4G 1,2G 8,2G 12% /usr
/dev/md/3 4,6G 443M 4,0G 10% /var
/dev/md/4 942M 18M 877M 2% /tmp
/dev/md/5 94G 33G 61G 35% /home
/dev/md/6 957M 252M 706M 27% /usr/portage
/dev/md/7 47G 3,2G 44G 7% /var/tmp
/dev/md/8 9,4G 272K 9,4G 1% /opt
shm 502M 0 502M 0% /dev/shm
|
|
Direi che una situazione del genere non necessiterebbe di commenti, lo spazio sprecato è tantissimo.
Vincoli lo spazio in scatole chiuse che statisticamente parlando si rivelano in parte sovra e in parte sottodimensionate.
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
Scen
Retired Dev
Joined: 29 Jul 2003
Posts: 2470
Location: Padova, Italy
|
| Posted: Tue Feb 27, 2007 9:50 am Post subject: |
|
|
| Kernel78 wrote: | Forse sono ingenuo io ma quale sarebbe la relazione tra più partizioni e minore perdita di di dati ?
Se usi un ups, un fs serio e non giochi con il kernel non rischi di perdere dati (e ripeto che un backup comporta maggior sicurezza e minor inconvenienti), viceversa ti esponi a dei rischi. |
Effettivamente non c'è una correlazione logica, e hai perfettamente ragione riguardo al backup+UPS, è l'unica vera sicurezza
Però quello che penso io è (esempio): in /usr/portage e/o /var/tmp avvengono molte letture/scritture/cancellazioni rispetto ad altre parti del filesystem. Questo comporta un maggiore rischio di corruzione dei dati rispetto ad un filesystem "statico", o sbaglio? A questo punto preferisco isolare queste parti del filesystem, le quali contengono dati non persistenti ed importanti. Isolamento che porta, naturalmente, delle controindicazioni (spazio sprecato, limitazioni, nel partizionamento, ecc.)
| Kernel78 wrote: | Direi che una situazione del genere non necessiterebbe di commenti, lo spazio sprecato è tantissimo.
Vincoli lo spazio in scatole chiuse che statisticamente parlando si rivelano in parte sovra e in parte sottodimensionate. |
Ok anche qua, purtroppo la mia scelta progettuale ha questa controindicazione.
A questo punto rigiro la frittata : secondo te qual'è la soluzione migliore? Un unica partizione? O al massimo quante? Se più partizioni, tutte con lo stesso FS?
Purtroppo non riesco ad accettare l'idea di una partizione unica, perfino nel Manuale Gentoo suggeriscono una /boot separata. Inoltre lessi da qualche parte che è consigliabile, nei sistemi server per esempio, di creare una partizione per /tmp e/o /var/log a parte, per salvaguardarsi il fondoschiena nel caso di malfunzionamenti o compromissioni del sistema (es. log che riempiono il disco, oppure partizione con opzione "noexec" per evitare l'esecuzione di script "malevoli").
Finora pensavo che le mie scelte fossero abbastanza giuste e ponderate, però i vostri ultimi post mi hanno fatto riflettere, penso debba rivedere le mie idee
_________________
I was born in a deep forest/I wish I could live here all my life/I am made from stones and roots/My home, these woods and roads
All my life I loved this sound/Of the woods all around/Eagles flies where the winds blows free
Journey is my destiny |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Tue Feb 27, 2007 10:36 am Post subject: |
|
|
| Scen wrote: | Però quello che penso io è (esempio): in /usr/portage e/o /var/tmp avvengono molte letture/scritture/cancellazioni rispetto ad altre parti del filesystem. Questo comporta un maggiore rischio di corruzione dei dati rispetto ad un filesystem "statico", o sbaglio? A questo punto preferisco isolare queste parti del filesystem, le quali contengono dati non persistenti ed importanti. Isolamento che porta, naturalmente, delle controindicazioni (spazio sprecato, limitazioni, nel partizionamento, ecc.)
|
Se tu hai un kernel stabile, non sei soggetto a blackout improvvisi e usi un fs serio che tu faccia più o meno operazioni di lettura/scrittura tu non sarai soggetto a corruzione di dati a meno di incidenti fisici ma in tal caso e probabile che si rovini fisicamente l'hd a prescindere dalle partizioni e dai fs.
Inoltre come si può leggere qualche post sopra
| !equilibrium wrote: | | XFS/JFS hanno un sistema di protezione che previene il propagarsi della corruzione (rispettivamente modalità "freeze" e modalità "dirty"), limitando la perdita di dati ai soli metadata corrotti in RAM (quindi pochi Kb), ext/reiserfs3 no invece, soprattutto reiserfs3 il quale non ha nessun meccanismo interno di faul-tolerance. |
quindi se tu usassi solo XFS/JFS avresti risolto alla radice il problema dell'isolamento di una potenziale corruzione senza i problemi dovuti all'eccessivo partizionamento.
| Quote: |
A questo punto rigiro la frittata : secondo te qual'è la soluzione migliore? Un unica partizione? O al massimo quante? Se più partizioni, tutte con lo stesso FS?
|
/
/boot
/home
e come ha spiegato !equilibrium sempre qualche post sopra meglio usare un'unico fs, io uso XFS per tutto tranne ext2 per /boot che cmq è quasi sempre smontata e quindi ha un impatto decisamente trascurabile.
| Quote: |
Purtroppo non riesco ad accettare l'idea di una partizione unica, perfino nel Manuale Gentoo suggeriscono una /boot separata. Inoltre lessi da qualche parte che è consigliabile, nei sistemi server per esempio, di creare una partizione per /tmp e/o /var/log a parte, per salvaguardarsi il fondoschiena nel caso di malfunzionamenti o compromissioni del sistema (es. log che riempiono il disco, oppure partizione con opzione "noexec" per evitare l'esecuzione di script "malevoli").
Finora pensavo che le mie scelte fossero abbastanza giuste e ponderate, però i vostri ultimi post mi hanno fatto riflettere, penso debba rivedere le mie idee |
Nessuno nasce imparato  siamo tutti qui per imparare e migliorarci, scommetto che tu potresti insegnarci molto su altri argomenti
Personalmente ritengo che anche se un problema con i log si evita tranquillamente impostando politiche di rotazione non solo temporali ma basate anche sullo spazio occupato dai log.
Personalmente tengo la /boot e la /home separate dal resto come retaggio dal passato in cui tenevo più distro installate con un unico kernel e un'unica home per gli utenti (/home la tengo rigorosamente noexec anche sulla mia macchina a casa), adesso /boot è separata dal resto più per abitudine che per necessità mentre /home la terrei cmq separata per il noexec.
In genere tengo anche /vat/tmp/portage in ram ma è una questione puramente personale.
Se hai dubbi o obiezioni sarò lieto di dibatterle con te
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
Cazzantonio
Bodhisattva
Joined: 20 Mar 2004
Posts: 4514
Location: Somewere around the world
|
| Posted: Tue Feb 27, 2007 11:42 am Post subject: |
|
|
| Kernel78 wrote: | | /home la tengo rigorosamente noexec anche sulla mia macchina a casa |
Si vede che non lanci programmi dalla tua home... io per esempio non potrei.
Secondo me siete tutti un po' troppo drastici. A seconda di quello che serve, dello spazio disponibile e delle risorse hardware può essere più o meno utile organizzare le directory un po' come ci pare. Non c'è una ricetta buona per tutti i gusti.
Per esempio io non posso montare la home in noexec... o meglio... non voglio visto che sarebbe una menata per l'utilizzo che ci faccio. Del resto trovo simpatico, visto che ho tanta ram, montare /tmp e /var/portage_tmp in ram, la prima con noexec,nodev,nsuid, la seconda no ma tanto non è world-writable. /var/tmp è un link a /tmp visto che a cancellarla ad ogni reboot non ho mai avuto problemi (di solito ci scrive qualcosa solo qualche applicazione di kde... e io non uso kde ).
In sostanza questa è la configurazione delle partizioni sul mio portatile:
| Code: | Filesystem Type Dimens. Usati Disp. Uso% Montato su
/dev/hda1 ext3 8,5G 3,7G 4,3G 47% /
udev tmpfs 796M 3,0M 793M 1% /dev
tmpfs tmpfs 796M 13k 796M 1% /tmp
none tmpfs 53M 0 53M 0% /dev/shm
tmpfs tmpfs 1,3G 0 1,3G 0% /var/portage_tmp
/dev/hda2 ext3 54G 3,2G 51G 6% /home
/dev/hda3 ext3 6,5G 38M 6,1G 1% /mnt/ubuntu
/dev/hda4 vfat 11G 7,4G 3,6G 68% /mnt/winxp |
Ho anche un serverino utilizzato per varie cose: storage domestico, server mldonkey, etc... Il suo schema di partizioni è leggermente più complesso per l'utilizzo che ne faccio:
| Code: | Filesystem Type Dimens. Usati Disp. Uso% Montato su
/dev/sda1 ext3 10G 2,7G 6,8G 29% /
udev tmpfs 497M 2,9M 494M 1% /dev
tmpfs tmpfs 497M 0 497M 0% /tmp
none tmpfs 53M 0 53M 0% /dev/shm
tmpfs tmpfs 839M 0 839M 0% /var/portage_tmp
/dev/sdb1 ext3 316G 197G 119G 63% /home/data
/dev/sda5 xfs 96M 37M 59M 39% /home/mldonkey
/dev/sda6 xfs 33G 11G 23G 32% /home/mldonkey/chroot/files |
Più una partizione crittata dove tengo varie cose (per esempio tutte le mie password )
Ho ritenuto saggio usare delle misure precauzionali per mldonkey, ovvero partizioni separate montate con permessi diversi, chroot etc... Ovviamente niente mi impedisce di usare un'unica partizione, tuttavia ho abbastanza risorse hardware da permettermi tale lusso.
Ora non ritengo che in tale schema ci sia qualcosa di giusto o di sbagliato. E' semplicemente così perché mi torna comodo e perché mi va... Sotto alcuni punti di vista sarebbe più efficiente organizzato diversamente, sotto altri no. Sta a noi scegliere quale punto di vista priviliegiare a seconda delle nostre necessità e dei nostri gusti.
_________________
Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Tue Feb 27, 2007 12:54 pm Post subject: |
|
|
| Cazzantonio wrote: | Ovviamente niente mi impedisce di usare un'unica partizione, tuttavia ho abbastanza risorse hardware da permettermi tale lusso.
Ora non ritengo che in tale schema ci sia qualcosa di giusto o di sbagliato. E' semplicemente così perché mi torna comodo e perché mi va... Sotto alcuni punti di vista sarebbe più efficiente organizzato diversamente, sotto altri no. Sta a noi scegliere quale punto di vista priviliegiare a seconda delle nostre necessità e dei nostri gusti. |
Nulla e nessuno ti vieta di prenderti uno storage da 10 petabyte e usare solo una partizione da 10 kilobyte, se vuoi sprecare le tue risorse e sei contento così buon per te.
In questo caso non esiste un giusto e uno sbagliato ma solo un più e meno efficiente e aderente o meno a lsb.
Uno può mettere /bin e /usr/bin come noexec e metterci le proprie configurazione e installare tutti i binari del sistema in /home, se uno è contento così non è certo sbagliato.
Gli eseguibili non dovrebbero stare in /home ma in altre directory, se poi tu vuoi fare l'alternativo e metterli in home non stai sbagliando.
Semplicemente i punti di vista oggettivi che riesco a immaginare (forse a causa di un mio limite) non giustificano tale partizionamento (es. una chroot non necessita di una partizione separata), se tu potessi rendermi partecipe solo di alcuni di questi punti di vista alternativi (ovviamente non soggettivi del tipo:"a me piace così") mi aiuteresti a crescere valutando anche prospettive che al momento non riesco a immaginare.
Per il momento nulla di quanto hai detto fa intravedere un motivo oggettivo per accettare come preferibile il tuo schema di partizionamento.
/EDIT:personalmente i gusti personali li metto dopo la funzionalità oggettiva e non prima.
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
Cazzantonio
Bodhisattva
Joined: 20 Mar 2004
Posts: 4514
Location: Somewere around the world
|
| Posted: Tue Feb 27, 2007 1:24 pm Post subject: |
|
|
| Kernel78 wrote: | | Gli eseguibili non dovrebbero stare in /home ma in altre directory, se poi tu vuoi fare l'alternativo e metterli in home non stai sbagliando. |
Gli eseguibili dei programmi scritti da me staranno un po' dove mi pare no? Non si tratta di fare gli alternativi solo che se ho una home i sorgenti che scrivo li scrivo nella home; quando compilo lancio gfrortran sui sorgenti nella mia home e l'eseguibile viene creato nella mia home; quando lancio il programma gira nella mia home e scrive i dati in una cartella apposita (che sta nella mia home); una volta finito di girare lo cancello, cambio due parametri, lo ricompilo e lo rilancio... e che devo metterlo in /usr/local/bin tutte le volte? faccio "su" tutte le volte per copiarcelo? Divento scemo...
Dovrei anche copiare i /usr/local/bin tutti i micro programmi di prova giusto per testare una routine? Maddai... Anche un bash script??
Ovviamente questa è solo una mia necessità... per esempio ho anche un account sui pc di facoltà dove tengo i binari di alcuni programmi nella mia home visto che non ho i permessi per installarli dove mi pare (in ~/programmi/bin per l'esattezza)... questa è un'altra esigenza ancora e non si tratta di scelte alternative ma obbligate. Posso immaginarmente decine e tuttavia se tu non hai tali esigenze fai benissimo a montarla con noexec
| Code: | | se tu potessi rendermi partecipe solo di alcuni di questi punti di vista alternativi (ovviamente non soggettivi del tipo:"a me piace così") |
Ad esempio quello di limitare le dimensioni di una partizione, di montare directory condivise con noexec,nodev,nosuid, di usare filesystem diversi per scopi diversi, stabilire quote solo per certe directory. Certo ciascuna di queste cose potrebbe anche essere non desiderabile o dannosa... dipende...
| Code: | | mi aiuteresti a crescere valutando anche prospettive che al momento non riesco a immaginare |
Stai cercando di fare il sarcastico? Su una discussione sul partizionamento? Mah... Cresci un po' come ti pare, basta crescere...
| Quote: | | Per il momento nulla di quanto hai detto fa intravedere un motivo oggettivo per accettare come preferibile il tuo schema di partizionamento |
Ma leggi quello che scrivo? Stai dicendo esattamente quello che dico io. Ovvero ognuno ha esigenze diverse quindi partiziona come gli pare. Non hai nessun motivo per accettare come migliore il mio perché NON E' MIGLIORE ma solo adatto alle mie esigenze. Tu, avendo esigenze diverse, partizionerai come ti pare. Idem Scen e tutti gli altri. Per questo una discussione di questo tipo può solo dare suggerimenti e non affermazioni categoriche.
Ave atque vale
_________________
Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Tue Feb 27, 2007 1:55 pm Post subject: |
|
|
| Cazzantonio wrote: | | Non hai nessun motivo per accettare come migliore il mio perché NON E' MIGLIORE ma solo adatto alle mie esigenze. Tu, avendo esigenze diverse, partizionerai come ti pare. Idem Scen e tutti gli altri. Per questo una discussione di questo tipo può solo dare suggerimenti e non affermazioni categoriche. |
Premetto che cerco di non inkazzarmi
Perdonami ma TU puoi limitarti a dare suggerimenti che stando a quanto dici tu valgono soltanto per te (quindi mi spieghi cose che suggerimento è uno che vale solo per te ?), IO faccio affermazioni categoriche sostenute da:
- logica e razionalità
- dati oggetti
- supporto degli standard
Non mi sono inventato io LSB, tutto il lavoro per unificare la FHS non è frutto di mie idee, io mi ci attengo soltanto, se tu per gusti personali tuoi o per pigrizia o per qualsiasi altro motivo SOGGETTIVO vuoi tenere gli eseguibili (anche solo temporaneamente) dove non dovrebbero stare è una tua insindacabile scelta personale e può anche starmi bene o meno (non sono in discussione i reciproci gusti personali).
Se finisci su un sistema gestito da me ti scordi gli eseguibili lanciati nella home, ti lascio una cartella altrove e non ho paura che tu possa sforare i limiti perchè imposto le quote, non perchè devo usare un'altra partizione (e siamo matti, se devo darti più spazio devo ripartizionare l'hd ???).
Non hai portato nemmeno un motivo OGGETTIVO che possa giustificare più di TRE partizioni (/ /boot e /home), hai solo accennato a motivi che anche tu valuti SOGGETTIVI (e che per loro natura non possono essere sottoposti a giudizio di merito).
Se uno pone una domanda sul forum è ovvio che io gli porto solo risposte oggettive, se ognuno di noi si mettesse a riportare esperienze soggettive, che come giustamente dici tu:"NON E' MIGLIORE ma solo adatto alle mie esigenze", non aiutiamo nessuno e generiamo solo confusione perchè magari chi non sa come stanno oggettivamente le cose segue il tuo consiglio, senza rendersi conto che è valido solo per chi l'ha postato, e va in contro a problemi e inconvenienti che avrebbe potuto tranquillamente evitare se correttamente informato.
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Tue Feb 27, 2007 6:40 pm Post subject: |
|
|
| !equilibrium wrote: | | esattamente cosa intendi per "xfs richiede manutenzione" ? |
In caso del tipico crash (per la mia esperienza di poi alla cottura del disco di tmp) al riavvio xfs richiede la modifica manuale (mi pare che la discussione sia partita proprio da questo, che non è possibile su jfs invece, se non erro) mentre reiser al riavvio si limita a perdersi i file (mi è capitato che qualcuno sia improvvisamente scomparso al reboot), ext2/3 si limita ad intasare lost+found di immondizia finchè non finisce lo spazio ed il sistema si blocca (e mi è capitato, anche perchè non sono sempre allo studio a guardare se il server è in perfetto ordine e spesso lo avviano senza neppure fare caso alle sue rimostranze e senza dirmi niente, i crash periodici di cui parlo in un mio post precedente li ho scoperti io quando mi si è bloccato lanciando il sync ma la cosa andava avanti da almeno un mese, si erano solo dimenticati di dirmelo).
nel caso stiamo parlando della home o di /opt (dove c'è la contabilità) è un disastro cui non voglio neppure pensare e sono contento se il sistema si blocca in caso di problemi anche minimi richiedendo un intervento di manutenzione manuale ma se capita in /tmp (che non posso mettere in ram perchè la usa lo script rc di backup, del tipo o gli dai i cd da masterizzare o si spegne da solo ovviamente, quindi ha un suo disco dedicato) detto francamente non me ne può fregare di meno anzi sono molto contento perchè così è più difficile che il sistema si blocchi ed allo studio, non potendomi contattare, si rivolgono a qualche coglioncino (detto comunemente tecnico da me... meglio soprassedere, è troppo volgare e non ho il tempo per scrivere tanto) per cercare aiuto ed io sia costretto a tornare a rotta di collo dalle ferie per consentirgli di lavorare (il fidiputt windozziano riciclato in questione era già pronto a piallare il disco di sistema con un lfs per metterci una "ottima" rh dei mortacci suoi e meno male che quando sono arrivato non me lo sono trovato davanti o finivo in galera per omicidio.
Prima o poi mi decido a mettere mano all'rc di modo che se in boot-runlevel di default trova tmp danneggiata la riformatta e tanti saluti, così completo il sistema e riesco ad andare in ferie (sempre se e quando ci riesco ma questa è un'altra questione) con un minimo di tranquillità in più.
da un punto di vista delle prestazioni, avendo più controller(4) e dischi( , reiser da qualcosina in più sulle aree temporanee od assimilabili a tali rispetto ad xfs e come ho già detto il suo principale punto debole non solo non crea troppi problemi ma è persino utile.
Quanto ad ext3 beh... quando xfs sarà un pò più maturo (o quando mi decido a fare un poco più di ordine) gli darò l'addio definitivo, più che altro me lo ritrovo perchè il supporto ad selinux (che tra l'altro non uso più) era migliore quando partizionai il server ma sto provvedendo, mi rimane ext2 per i loopback criptati (che prima o poi dovrò attivare) dove non mi pare che xfs sia ancora del tutto consigliabile.
Poi c'è la partizione del programma di contabilità (circa un paio di migliaia di file di uno o due kb distribuiti in un albero di directory allucinante) dove uso ext3 perchè è quello che mi ha consentito di ridurre al minimo l'occupazione di spazio (circa 4GB contro i 16 di reiser ed i 5 di xfs).
Per esempio sul portatile (scheda video ati, accidenti a loro, quindi decisamente esposto ai crash) ho "solo" e per il momento (la fat visti i risultati di ntfs3g non mi serve più):
hda1 swap 1GB
hda2 /var e /tmp reiserfs 3GB
hda3 /windozzC ntfs 15GB
hda5 / xfs 20 GB
hda6 /windozzD ntfs (D&S) 5GB
hda7 /home xfs 3GB
hda8 /home/documenti e /opt/prg fat 30GB
hda9 swap (dedicata x suspend) 2GB
va da se che se potessi fare a meno di windozz (ma per causa dello stato imbecille più che ladro e delle banche dati del piffero non se ne parla) avrei
hda1 swap 1GB
hda2 /var/tmp e tmp reiserfs 3GB
hda3 /var xfs 2GB
hda5 / xfs 20 GB
hda6 /home xfs 3GB
hda7 /home/documenti e /opt xfs 50GB
hda8 swap (dedicata x suspend) 2GB
/opt/prg è la directory per tutta l'immondizia tipo entratel ed emens, immagini dei cd delle banche dati, contabilità, elaborazione vertenze etc.
per avere un poco più di prestazioni si può pensare di sbattere la cache di firefox in tmp e la dir di thunderbird in var tanto il pc è sostanzialmente monoutente (in multiuenza vera e propria ci sono delle implicazioni per la sicurezza) etc.
di /var/pkg e / in realtà mi frega relativamente poco e potrei pure pensare di sbatterle insieme (perchè il mio portatile è un clone del server e se si skianta lo ripristino in fretta) e via dicendo.
qualcosa che potrei spostare insieme a tmp è var/cache e var/www (quando mi deciderò ad usarla seriamente) che va insieme alla home etc.
sul server è un poco più complicata ma ho anche 7 dischi + 1 per il backup e voglio tenere costantemente separate alcune aree a livello fisico (anche per poter staccare gli hd e collegarli ad un altro computer singolarmente).
hdb1 /var 20 GB (uso minimo 2 massimo riscontrato 19, solito intasamento per portage_tmp non montata) ext3 causa supporto migliore security label
hdb2 / 20 GB (uso variabile da 12 a 14 restano sei GB più che sufficienti nel caso tmp vada in gloria) ext3 come sopra
hdb3 40 portage (solo package e distfiles) e installer windozz condivisi in rete reiser tanto per usarne uno ma era meglio xfs
hdd1 /tmp ovviamente reiserfs
hdc1 80 /var/backup (normalmente smontata) ora reiser penso poi xfs, faccio notare che i backup vengono creati nel disco di tmp e poi copiati quindi il rischio di perdita di dati è minimo.
hde1 /home/share ovvero area di accesso libero (alias discarica degli altri pc) sempre reiser tanto quello che ci metto mi interessa molto poco, in genere la uso come archivio per le immagini dei cd delle banche dati e simili (di cui c'è copia negli altri pc e tutto sommato posso sempre prendere gli orginali se solo fossi un poco più ordinato nel tenerli)
hdf1 /home/prints (/var/spool/fax, /var/spool/pdf, /var/spool/log) sempre reiser quel che contiene mi interessa ma se una stampa è importante va da se che la archivio altrove. Più che altro è per non scemunirmi con le farragini del programma di contabilità e, soprattutto, non fare fotocopie quando serve.
hdg /backup a lungo termine.
sda1 home condivise 20GB sempre ext3 per i problemi di selinux
sda4 /home/documenti 60 GB condivisi sempre in ext3
sda3 /opt/prg reiserfs visto che sono tutti programmi cui accedo spesso ma la cui sopravvivenza mi interessa relativamente
sda2 /opt/mitos 20 con la dannata contabilità ext3
sdb1 /home/waste reiserfs 500GB dove piazzo tutta l'immondizia che mi ritrovo di troppo tipo le immagini delle live etc.
Sui pc uso due dischi da 80 e da 20 quindi /var, windozz sistema, root e metà circa riservata ad immagini CD etc su uno e tmp, D&S e home sull'altro. Le home sono una copia giusto nel caso mi faccia comodo avviare solo i client senza server ma è ovvio che quel che c'è mi interessa molto relativamente e periodicamente li azzero, quindi reiser ed ntfs con la sola eccezione di fat per l'area delle immagini cd (con file di dai 350 ai 2 GB non spreco molto spazio).
| !equilibrium wrote: | | non capisco il senso di "ripercussione su eventuali altri filesystem", non ne vedo proprio il nesso sinceramente. |
pensavo di mettere dei loopback criptati (uno per ogni utente) su xfs (/home ovviamente) e pensavo a come trovare un modo per isolarli da eventuali corruzioni del filesystem che gli sta attorno.
avevo letto qualcosa a tal proposito ma come al solito non trovo mai il tempo di approfondire la questione. Messa come dici tu però mi pare che sia inutile.
| !equilibrium & Kernel78 wrote: | | corri il rischio di esporti inutilmente a tutte le loro possibili debolezze/bugs in contemporanea. |
Il principio non è usare i punti di forza alla ricerca delle prestazioni ma utilizzare ogni fs (ma più che altro è un xfs vs reiser) dove le sue debolezze note portano il minor danno possibile, è l'esatto contrario.
| Kernel78 wrote: | | Del resto trovo simpatico, visto che ho tanta ram, montare /tmp e /var/portage_tmp in ram |
t'ho beccato! tiri fuori le peggiori fonti di guai... ma non lo avevi detto prima.
In ogni caso il problema che volevo evidenziare è che a parte lo starter di questo thread in genere chi è alle prime armi (ma anche chi è più esperto) non affronta mai la questione del partizionamento che è basato, lo ripeto, sull'individuare i fattori di rischio e fare la scelta più adeguata guardando all'impatto delle debolezze da minimizzare più e non alle fature da utilizzare per le prestazioni (si va nel paradosso del diavoletto di maxwell in questo modo).
Dimenticavo che il problema di tmp è anche nella possibilità di intasarla (oltre alla scarsa praticità di applicare la quota su di essa), per questo "storicamente" la si tiene separata.
Ai tempi di ultrix (oltre al trucco sull'eseguibile passwd per cambiare le password agli altri ed alla finta schrmata di login) lo sport preferito degli imbecilli docg era lanciare un dd if=/dev/null of=/tmp/miofile così al riavvio il tecnico del laboratorio (grande sostenitore della partizione unica a tutti i costi, anche se con i limiti dei dischi di quindici anni fa) diventatava matto.
va da se che un'area sottoposta a riscrittura continua deve essere separata dai dati critici da archiviare. Se poi il pc lo si usa solo per provare, lo ripeto si fa quel che capita e la partizione unica è la soluzione migliore (l'esigenza della /boot separata era dettata più che altro da limiti di lilo che non sussistono più).
Il problema non è la soluzione che non potrà mai essere la stessa ma quale sia il metodo di analisi (che spesso manca) e le considerazioni da fare che invece sono sempre uguali:
1) cosa ci faccio con il pc
2) quali sono i dati che devo cercare di salvare ad ogni costo e che quindi vanno separati
3) quali sono le aree critiche che possono portare rogne e che vanno separate
4) quali rogne mi possono capitare e che succede con i vari filesystem secondo le loro debolezze
5) come posso affrontare i vari fault (azzeramento automatico di tmp, backup automatico di var/pkg etc) per cercare di mantenere nelle peggiori ipotesi tutto funzionante
6) quali aree devo separare per sicurezza (ozioni noexec etc)
7) quali sono le variazioni nell'occupazione di spazio delle aree precedente individuate che posso prevedere
a questo punto inizio a pensare al filesystem più adatto per ognuna e le accorpo. Poi posso partizionare di conseguenza. Questo è ilo metodo classico del quale possiamo discutere.
Poi c'è il metodo dei fessi che è vedere qual è il filesystem più performante per le varie aree, fregarsene delle considerazioni di sicurezza e delle rispettive debolezze e partizionare alla ricerca della massima ottimizzazione. Come ha detto giustamente kernel78 e ribadito !equilibrum, in questo modo invece di avere a che fare solo con i difettacci di uno le probabilità di un disastro totale saranno relazionate alla somma delle vulnerabilità dei vari fs (e quindi per la legge di murpy lo schianto è assicurato).
@scen
In ogni caso ti consiglio /tmp in /var/tmp e non viceversa, soprattutto se pensi di usare l'autocleaning al boot di tmp (che non è un'idea malvagia).
Tra l'altro una soluzione interessante può essere copiare /var/tmp (ma non la /tmp inclusa) su disco allo spegnimento, se possibile.
Poi c'e anche da valutare quale uso fare del mount --bind e dei link per distribuire diversamente i log (se non possibile da configurazione) ed opzioni particolari di mount. A esempio sul tipico pc per uso personale, in ambito lavorativo, i log dello smart e dei sensori hanno maggiore importanza rispetto a quelli di sicurezza per capire cosa è successo mentre i log di squid possono andare in /var/tmp (ovvero file temporanei da conservare tra le sessioni) mentre su un server sono fondamentali per capire chi fa la bestia su internet e vanno conservati separatamente e via dicendo.
edit:
dimenticavo che l'uso di /home/user/bin non è una novità, anzi è normale e più sicuro se usi il sistema per sviluppare applicativi quando li vuoi testare (la stronzata comune invece è compilarli nella home ed PATH=$PATH:$HOME, non ridete, ne conosco parecchi che fanno cose del genere) al più è utile per i paranoici che /home/user/bin sia un remount o un link simbolico ad un'area "exec" appositamente individuata (più corretto). Al tempo dei terminali si lavorava così, unix era un ambiente mainframe in origine, nemmeno workstation.
il FHS non è un vangelo cui attenersi pedissequamente pena la dannazione eterna e maledizione sino alla terza generezione a venire per gli utenti ma un riferimento assoluto . Ovvero serve a capire dove trovare le cose per iniziare a modificarle sempre se strettamente necessario e seguendone la logica ma nulla vieta di scostarsene per particolari esigenze tipo sbattere i log di squid direttamente nella home dell'amministratore o var/www in /home/www (tipico) e simili.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Forum italiano (Italian) 
