| View previous topic :: View next topic |
| Author |
Message |
drakkan
Apprentice
Joined: 21 Jun 2004
Posts: 232
|
 Posted: Fri Jul 07, 2006 5:41 pm Post subject: Re: [TIP] migliorare le performance di SGI XFS Filesystem |
 |
|
| drakkan wrote: |
da questo mi sembra di capire che la moltiplicazione per due non serva,
|
mi rispondo da solo la moltiplicazione per due serve perchè quando si usa l'opzione sunit=xx il valore xx è un multiplo di 512 byte |
|
| Back to top |
|
 |
cloc3
Advocate
Joined: 13 Jan 2004
Posts: 4809
Location: http://www.gentoo-users.org/user/cloc3/
|
| Posted: Thu Jul 13, 2006 6:55 am Post subject: passo a xfs |
|
|
già il sottotitolo farà brillare gli occhi a k.gothmog  .
Volevo provare xfs, ma mi sono accorto che la cosa è più complessa del previsto.
Leggendo questo e gli altri post in giro, infatti, sembrerebbe che xfs, se mal impostato, sia una vera ciofeca.
Ho un raid0 software di due dischi. Lo so, bisognerebbe fare raid5 con tre dischi, ma non li ho. E il raid contiene già altri dati che non posso spostare.
La prima partizione di prova è piccolina: 2.5G.
Volevo formattarla con l'opzione -sunit, perché se non ho capito male serve proprio a gestire il raid.
Ho fatto così:
| Code: |
mkfs.xfs -bsize=512 -dsunit=2,swidth=4 /dev/raid0/root -f
|
oppure con altri coctail di sunit,swidth.
In ogni caso, appena monto il dispositivo e ci copio dentro dei dati, si verifica questo errore fatale, che forza un reset del sistema (il kill non riesce a sbloccare il processo e nemmeno lo shutdown):
| Code: |
Jul 13 08:50:15 [kernel] raid0_make_request bug: can't convert block across chunks or bigger than 64k 170980093 4
|
Sinceramente non riesco a capire bene la situazione.
Mi sapreste dire qualcosa?
_________________
vu vu vu
gentù
mi piaci tu |
|
| Back to top |
|
|
!equilibrium
Bodhisattva
Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC
|
| Posted: Thu Jul 13, 2006 10:28 am Post subject: Re: passo a xfs |
|
|
/EDIT
| cloc3 wrote: | già il sottotitolo farà brillare gli occhi a k.gothmog .
Volevo provare xfs, ma mi sono accorto che la cosa è più complessa del previsto.
Leggendo questo e gli altri post in giro, infatti, sembrerebbe che xfs, se mal impostato, sia una vera ciofeca. |
come qualsiasi altra cosa mal configurata.
(non è certo un bug di XFS, ma è il noto problema che sta tra la sedia e il monitor  ) <-- faccina che ride, please niente flame o attacchi personali
| cloc3 wrote: |
| Code: |
Jul 13 08:50:15 [kernel] raid0_make_request bug: can't convert block across chunks or bigger than 64k 170980093 4
|
Sinceramente non riesco a capire bene la situazione.
Mi sapreste dire qualcosa? |
se cerchi con google, troverai che il problema non è in XFS, ma è un noto bug che esiste dai tempi del kernel 2.5 (e mai realmente fixato) e generato da LVM2 + Soft RAID0. in parole povere, è un problema di LVM2, non di XFS. c'è una patch in giro da applicare al kernel (non ufficiale), e il filesystem XFS va ri-formattato con una particolare opzione per allineare il journaling con lo stripe size del soft RAID.
p.s.: non ne sono sicuro al 100% ma pare che questo bug sia dovuto al fatto che LVM2 non sia in grado di gestire correttamente un soft raid su HDs non perfettamente identici, quindi basta anche una lieve differenza di pochi MB tra i due HDs e LVM2 non riesce a riallocare correttamente i settori in fase di scrittura. (faccio notare che si stà andando terribilmente OT rispetto al thread originario)
_________________
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 |
|
|
cloc3
Advocate
Joined: 13 Jan 2004
Posts: 4809
Location: http://www.gentoo-users.org/user/cloc3/
|
| Posted: Thu Jul 13, 2006 10:44 am Post subject: Re: passo a xfs |
|
|
| !equilibrium wrote: |
se cerchi con google, |
ci hai azzeccato in tutto. Su google ci sono post del 2003 su questo argomento, ma la "documentazione" è un po' troppo dispersa per le mie capacità di sintetizzare una soluzione. essendo ot qui, credo che ti scriverò in mp.
hai ragione anche a dire chi il mio lvm2 è collocato su due partizioni leggermente diverse. non sono stato capace di farle identiche, perché i due dischi usavano una geometria fisica (cilindri - blocchi -settori ?) differente.
non è ot, invece, chiedere un cenno relativo alla scelta dei valori di sunit e swidth. i miei sono corretti, sono efficienti, per un filesystem che deve contenere il sistema operativo e i programmi principali?
_________________
vu vu vu
gentù
mi piaci tu |
|
| Back to top |
|
|
!equilibrium
Bodhisattva
Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC
|
| Posted: Sat Jul 15, 2006 7:44 pm Post subject: Re: passo a xfs |
|
|
| cloc3 wrote: | | non è ot, invece, chiedere un cenno relativo alla scelta dei valori di sunit e swidth. i miei sono corretti, sono efficienti, per un filesystem che deve contenere il sistema operativo e i programmi principali? |
faccio un esempio concreto così da spiegare per bene questo concetto una volta per tutte; prendo il tuo caso specifico e lo userò come esempio, quindi un RAID0 di 2 unità con uno stripe size di 32K (valore da me inventato visto che non l'hai riportato nei precedenti post).
PREMESSA: in un array RAID, durante i processi di scrittura, un file viene spezzato in blocchi più piccoli, i quali vengono salvati sulle varie unità dell'array; la dimensione di questi blocchi è specificata in /etc/raidtab tramite il parametro chunk-size.
sunit rapprenta la grandezza dei blocchi in cui verrà suddiviso un file durante i processi di I/O (quindi rispecchia il chunk-size dell'array) e deve essere espresso in multipli di 512byte, come dice lo stesso man di mkfs.xfs:
| Code: | The sunit suboption is used to specify the stripe unit for a RAID device or a logical volume. The suboption
value has to be specified in 512-byte block units. Use the su suboption to specify the stripe unit size in
bytes. This suboption ensures that data allocations will be stripe unit aligned when the current end of file is
being extended and the file size is larger than 512KiB. Also inode allocations and the internal log will be
stripe unit aligned.
|
cioè nel caso dell'esempio:
32 * 1204 = 32768 byte (chunk-size espresso in byte)
32768 / 512 = 64 (chunk-sze espresso in multipli di 512byte)
quindi: -d sunit=64
p.s.: per chi non l'avesse notato, l'operazione appena citata si può semplificare prendendo l'intero del valore del chunksize e moltiplicarlo per 2 (determinato da 1024 / 512), come ho riportato nel TIP alla sezione 6- Stripe Size e RAID.
swidth indica la capacità massima dello strip-size dell'array, raggiunto il quale il filesystem torna a scrivere alla prima unità che compone il raid, e deve essere espresso in multipli di 512byte. In parole povere, con questo parametro si specifica in quante parti un file deve essere spezzato, o meglio ancora, su quante unità dell'array un dato file deve essere suddiviso; questo valore si calcola moltiplicando il chunk-size per il numero totale delle unità, fatta eccezione per le unità di parità (che non devono essere conteggiate).
nel caso dell'esempio:
2 * 32K = 64K (stripe-size totale espresso in Kbyte)
64K = 65536 byte (stripe-size totale espresso in byte)
65536 / 512 = 128 (stripe size totale espresso in multipli di 512byte)
quindi: -d sunit=64 swidh=128
p.s.: per chi non l'avesse notato, l'operazione appena citata si può semplificare prendendo il valore di sunit e moltiplicandolo per 2 (determinato da 1024 / 512).
cosa cambia nel filesystem con questi nuovi settaggi?
il filesystem conoscendo la dimensione logica dell'array è in grado di suddividere il file che deve scrivere/leggere in buffer specifici e salvarli in un ordine di unità efficiente, cioè nel caso dell'esempio, prenderebbe i primi 32K del file e li salverebbe nel primo disco, poi il successivo blocco lo salverebbe nel secondo disco, a questo punto il filesystem raggiunge la capacità massima dello stripe e ricomincia da capo, partendo dal primo disco e passando al secondo e così via. Siccome XFS è in gradi eseguire processi di I/O in parallelo entrambi gli HDs verrebbero sfruttati contemporaneamente e non a casaccio (il filesystem potrebbe decidere di copiare i primi 4 blocchi del file nel primo disco, poi i successi 2 nel secondo e un altro blocco nel primo e i successi 20 nel secondo e così via, senza logica alcuna), sfruttando al meglio l'hardware. inoltre i buffer del filesystem e del journaling sarebbero allineani con lo stripe size dell'array e quindi tutti i processi di I/O non sarebbero rallentati dalle operazioni necessarie per adattare i buffers (perchè ovviamente di dimensioni sempre diverse). In soldoni, la lettura/scrittura dei files è molto + fluida e prestante.
(Va da se che un filesystem XFS configurato alla c***o su un RAID, avrà pessime performance )
ultima TIP: per chi ha controllers RAID 3ware, determinate il chunk-size ottimale per il vostro array tramite i valori consigliati dall'utility tw_cli e non spannometricamente tramite Google
_________________
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 |
|
|
Dr.Dran
l33t
Joined: 08 Oct 2004
Posts: 766
Location: Imola - Italy
|
| Posted: Mon Jul 17, 2006 5:29 pm Post subject: Re: passo a xfs |
|
|
| !equilibrium wrote: | | ultima TIP: per chi ha controllers RAID 3ware, determinate il chunk-size ottimale per il vostro array tramite i valori consigliati dall'utility tw_cli e non spannometricamente tramite Google |
Aggiungo che il parametro lo si può ottenere anche entrando al boot nella utility BIOS del controller RAID controllando le informazioni del controller creato o esistente 
_________________
:: [Dr.Dran] Details ::
- Linux User # 286282
- IT FreeLance Consultant
- President of ImoLUG [Imola & Faenza Linux User Group] |
|
| Back to top |
|
|
riverdragon
Veteran
Joined: 14 Sep 2006
Posts: 1269
Location: Verona
|
| Posted: Fri Sep 22, 2006 12:55 pm Post subject: |
|
|
Ad eccezione del filesystem di boot, che è ext2, ho tutti i filesystem di gentoo in xfs (/, /home e una partizione "di salvataggio").
Noto ora questo splendido howto che ho trovato cercando alcuni tweaks per i miei filesystem. Sembra infatti da bootchart che la mia zavorra all'avvio sia proprio il disco.
Chiudendo la parentesi introduttiva, segnalo a equilibrium che in un articolo che ho trovato tramite google si segnala un'ottimizzazione che va in direzione opposta a quanto da lui spiegato, riguarda i gruppi di allocazione: viene detto di diminuire i gruppi di allocazione al momento della formattazione per ridurre l'overhead generato dall'accesso multiplo al disco, consigliando un valore di 4->8 (sempre tenendo conto di avere almeno un ag ogni 4GB); in questo howto invece viene consigliato di aumentarne il numero.
Poco dopo, nello stesso articolo, viene menzionata un'ulteriore opzione da aggiungere a fstab, l'opzione osyncisdsync.
EDIT2: avevo inserito i risultati di bonnie con tre opzioni di mount differenti (rw,barrier; rw,noatime,nodiratime,barrier; rw,noatime,nodiratime,osyncisdsync,barrier) ma l'output è formattato sufficientemente male che non si capiva granché, e il forum non sembra permettere caratteri monospace. Quando sarà leggibile li reinserirò. |
|
| Back to top |
|
|
power83
l33t
Joined: 28 Nov 2004
Posts: 638
|
| Posted: Fri Sep 22, 2006 7:28 pm Post subject: |
|
|
| A che serve nodiratime? |
|
| Back to top |
|
|
.:deadhead:.
Advocate
Joined: 25 Nov 2003
Posts: 2963
Location: Milano, Italy
|
| Posted: Sat Sep 23, 2006 7:39 am Post subject: |
|
|
| riverdragon wrote: | | ma l'output è formattato sufficientemente male che non si capiva granché, e il forum non sembra permettere caratteri monospace. Quando sarà leggibile li reinserirò. |
uppalo da qualche parte e poi linkalo qui
| power83 wrote: | | A che serve nodiratime? |
a non cambiare l'acces time per le directory, è il corrispettivo di noatime
_________________
Proudly member of the Gentoo Documentation Project: the Italian Conspiracy ! |
|
| Back to top |
|
|
riverdragon
Veteran
Joined: 14 Sep 2006
Posts: 1269
Location: Verona
|
| Posted: Sat Sep 23, 2006 10:12 am Post subject: |
|
|
Provate a vedere se da qui si vede qualcosa.
Come appunto, queste sono due righe dal mio /var/log/messages riguardanti l'opzione osyncisdsinc e l'opzione di mount logbsize: | Code: | Sep 22 15:48:40 tomnote XFS: osyncisdsync is now the default, option is deprecated.
Sep 22 15:48:40 tomnote XFS: logbuf size for version 1 logs must be 16K or 32K |
La questione sull'uso della prima opzione sparisce, invece sorge il problema di cosa voglia dire quel "version 1" che mi impedisce di impostare logbsize a 64k. |
|
| Back to top |
|
|
Dr.Dran
l33t
Joined: 08 Oct 2004
Posts: 766
Location: Imola - Italy
|
| Posted: Sat Sep 23, 2006 11:13 am Post subject: |
|
|
Beh la risposta al tuo quesito è facile, devi sapere che xfs ha 2 versioni di logging per il journal del filesystem e quindi ti consiglia con tale versione di impostare un buffer di massimo 32K.
Per utilizzare la versione 2 devi riformattare il filesystem con la apposita istruzione.
Cheers
Franco
_________________
:: [Dr.Dran] Details ::
- Linux User # 286282
- IT FreeLance Consultant
- President of ImoLUG [Imola & Faenza Linux User Group] |
|
| Back to top |
|
|
riverdragon
Veteran
Joined: 14 Sep 2006
Posts: 1269
Location: Verona
|
| Posted: Sat Sep 23, 2006 2:12 pm Post subject: |
|
|
Trovata, l'opzione -l version=2. Grazie!
Alla fine, è meglio aumentare il numero di ag rispetto al default o è meglio aumentarlo? Non mi è ancora chiaro, e vorrei fare un'unica riformattazione. |
|
| Back to top |
|
|
.:deadhead:.
Advocate
Joined: 25 Nov 2003
Posts: 2963
Location: Milano, Italy
|
|
| Back to top |
|
|
mrfree
Veteran
Joined: 15 Mar 2003
Posts: 1303
Location: Europe.Italy.Sulmona
|
| Posted: Wed Jan 31, 2007 8:14 am Post subject: |
|
|
Ho appena terminato la migrazione per la mia home da reiserfs3 a xfs quindi non posso ancora dare pareri da utilizzatore veterano, ho però notato che mentre subito dopo la creazione del filesystem lo spazio libero è maggiore rispetto a reiserfs ora che ho rsync-ato e riempito di nuovo la mia home lo spazio disponibile è parecchio di meno!
df riporta con xfs 2403752 blocchi disponibili mentre con reiserfs erano 3208972
Questi i parametri che ho utilizzato per formattare la partizione | Code: | | mkfs.xfs -f -d unwritten=0 -l size=64m,version=2 /dev/vg/home |
_________________
Please EU, pimp my country!
ICE: /etc/init.d/iptables panic |
|
| Back to top |
|
|
riverdragon
Veteran
Joined: 14 Sep 2006
Posts: 1269
Location: Verona
|
| Posted: Wed Jan 31, 2007 2:37 pm Post subject: |
|
|
In MB quanto sarebbe la differenza? E cosa c'entra la home con il sync (suppongo sia quello di portage)?
Equilibrium, quando aggiorni la guida?  |
|
| Back to top |
|
|
Ic3M4n
Advocate
Joined: 02 Nov 2004
Posts: 3489
Location: Bergamo.
|
| Posted: Wed Jan 31, 2007 11:06 pm Post subject: |
|
|
per spostare i file alcune persone, me compreso, preferiscono rsync a cp.
per quanto riguarda la formattazione io avrei utilizzato anche l'opzione -b size=512 che permette di ridurre spazio sui file molto piccoli. |
|
| Back to top |
|
|
mrfree
Veteran
Joined: 15 Mar 2003
Posts: 1303
Location: Europe.Italy.Sulmona
|
| Posted: Thu Feb 01, 2007 8:18 am Post subject: |
|
|
| riverdragon wrote: | | In MB quanto sarebbe la differenza? |
Purtroppo mi sono segnato solo i blocchi  Però, se non erro, la perdita dovrebbe essere, a memoria, di almeno 1GB
| Ic3M4n wrote: | | per quanto riguarda la formattazione io avrei utilizzato anche l'opzione -b size=512 che permette di ridurre spazio sui file molto piccoli. |
Non è un po' pochino? Anche secondo le linee guida di SGI [pp 7 e seguenti] per filesystem di queste dimensioni (parliamo di 48GB) la dimensione consigliata è 4KB. Comunque si tratta di una home quindi parliamo magari di file di qualche MB (musica, video) un bsize così basso potrebbe influenzare negativamente le performance dell'intero filesystem, o no?
Poi il filesystem precedente era reiserfs3 (partizione formattata con i parametri di default) se anche questo adotta 4KB come dimensione dei blocchi da cosa potrebbe dipendere tale perdita di spazio? Comincio a pensare alle impostazioni del log...
_________________
Please EU, pimp my country!
ICE: /etc/init.d/iptables panic |
|
| Back to top |
|
|
Ic3M4n
Advocate
Joined: 02 Nov 2004
Posts: 3489
Location: Bergamo.
|
| Posted: Thu Feb 01, 2007 4:12 pm Post subject: |
|
|
| reiser utilizza 512 di default che io sappia. |
|
| Back to top |
|
|
riverdragon
Veteran
Joined: 14 Sep 2006
Posts: 1269
Location: Verona
|
| Posted: Thu Feb 01, 2007 5:21 pm Post subject: |
|
|
| Avevo scritto un messaggio, ora non lo vedo... boooh. Comunque, 1 gigabyte è un'enormità, prova (se puoi) a riformattare il filesystem senza opzioni particolari e a vedere che succede. |
|
| Back to top |
|
|
mrfree
Veteran
Joined: 15 Mar 2003
Posts: 1303
Location: Europe.Italy.Sulmona
|
| Posted: Thu Feb 01, 2007 6:27 pm Post subject: |
|
|
| Ic3M4n wrote: | | reiser utilizza 512 di default che io sappia. |
Ho provato su un'altra mia partizione | Code: | # debugreiserfs /dev/vg/usr | grep Blocksize
debugreiserfs 3.6.19 (2003 www.namesys.com)
Blocksize: 4096 |
Credo che appena possibile proverò a riformattare con le impostazioni di default per capire se cambia qualcosa...
_________________
Please EU, pimp my country!
ICE: /etc/init.d/iptables panic |
|
| Back to top |
|
|
Cazzantonio
Bodhisattva
Joined: 20 Mar 2004
Posts: 4514
Location: Somewere around the world
|
| Posted: Tue Feb 27, 2007 8:26 pm Post subject: |
|
|
@!equilibrium:
Volevo chiederti un consiglio...
Ho un notebook e un server in cui volevo iniziare a migrare le partizioni ext3 verso xfs.
Nel notebook ho una partizione root più una /home che attualmente sono in ext3.
Nel server ho una root e una partizione di dati GROSSA (320 giga) in ext3, più un paio di partizioni modeste (ma di frequente utilizzo) dove ho finora sperimentato la resistenza di xfs.
Il mio utilizzo del notebook è assolutamente normale se non fosse che occasionalmente ci lancio sopra dei programmi che occupano per svariate ore il 100% della cpu e mi scrivono giga e giga (anche una ventina, scanditi con contiunazione su tutte le ore del processo) sulla partizione /home.
Il mio utilizzo del server è invece, per ora, solo di storage domestico e di media player (sostanzialmente sta fisso acceso ma non fa un granché).
Le mie priorità sono garantire innanzitutto la sicurezza dei dati (fondamentale soprattutto sulle home e sulle partizioni dati) e secondariamente minimizzare gli accessi a disco; non mi interessano particolarmente le prestazioni velocistiche (se ci sono tanto meglio ma non sacrificherei niente per averle).
Entrambi hanno parecchia ram (più di un giga) purtroppo non ECC (quando sarò ricco provvederò).
Il server è sotto un UPS; il portatile invece, ovviamente, ha una batteria
Volevo chiederti, secondo il tuo giudizio, quale potrebbe essere un valore per logbufs e logbsize per le partizioni sia sul notebook che sul server.
Quello che mi crea dubbi è quali siano le controindicazioni per un valore alto di logbsize, ovvero se ci siano più rischi di perdere dati a scapito di una discutibile riduzione degli accessi a disco.
Inoltre sono curioso di sapere come si faccia a capire se gli hd in mio possesso (tutti dei seagate barracuda) hanno le write-barriers hardware.
P.S. la partizione dati del server temo di non poterla migrare visto che non so bene dove trovare lo spazio per beckuppare tutti i dati che contiene.
_________________
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: Sat Mar 10, 2007 8:03 pm Post subject: |
|
|
| Cazzantonio wrote: | | Volevo chiederti, secondo il tuo giudizio, quale potrebbe essere un valore per logbufs e logbsize per le partizioni sia sul notebook che sul server. Quello che mi crea dubbi è quali siano le controindicazioni per un valore alto di logbsize, ovvero se ci siano più rischi di perdere dati a scapito di una discutibile riduzione degli accessi a disco. |
l'aumento dei buffer di log ha solo lo scopo di ridurre gli accessi al disco e di conseguenza aumentare le prestazioni di scrittura/lettura, quindi dal punto di vista della sicurezza dei dati non perdi nulla e non guadagni nulla. Siccome il tuo scopo ultimo non sono le performance, ma solo una riduzione degli accessi allora ti consiglio di usare i valori che ho riportato nel mio tutorial (cioè il doppio dei valori di default), credo che siano più che sufficienti.
| Cazzantonio wrote: | | Inoltre sono curioso di sapere come si faccia a capire se gli hd in mio possesso (tutti dei seagate barracuda) hanno le write-barriers hardware. |
ehehehehe
sugli SCSI è facile saperlo, ti viene riportato tra le mille e una funzionalità rilevate da sdparm.
sui PATA/SATA non saprei, o meglio, sui SATA dovresti riuscire ad usare sdparm, sui PATA non ho idea.
comunque se usi XFS, e monti una partizione di un HD che non supporta le write barrier hardware, ti viene mostrato a video un messaggio che ti informa:
Filesystem "XXXX": Disabling barriers, not supported by the underlying device
se il messaggio non ti esce a video in fase di mount vuol dire che hai pieno supporto alle write barrier hardware del drive (se maometto non va alla montagna ... )
p.s.: sorry per la lunga attesa alla mia risposta.
_________________
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 |
|
|
Cazzantonio
Bodhisattva
Joined: 20 Mar 2004
Posts: 4514
Location: Somewere around the world
|
| Posted: Sat Mar 10, 2007 8:10 pm Post subject: |
|
|
| !equilibrium wrote: | Filesystem "XXXX": Disabling barriers, not supported by the underlying device
se il messaggio non ti esce a video in fase di mount vuol dire che hai pieno supporto alle write barrier hardware del drive (se maometto non va alla montagna ... ) |
Avevo già controllato e non compare... comunque per sicurezza forzo l'utilizzo delle barriers in fase di mount
| Quote: | | p.s.: sorry per la lunga attesa alla mia risposta. |
Grazie, non ti preoccupare 
_________________
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 Mar 13, 2007 8:44 am Post subject: |
|
|
Domandina, ho provato a modificare il mio fstab per fare delle prove | Quote: | | /dev/md0 /boot xfs barrier,noauto,noatime 1 2 |
ma quando monto /boot mi ritrovo cmq | Code: | # dmesg | tail
nfsd: unexporting all filesystems
eth1: link down
eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
eth1: link down
eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
Filesystem "md0": Disabling barriers, not supported by the underlying device
XFS mounting filesystem md0
Ending clean XFS mount for filesystem: md0
|
Mi sembra di capire che non è proprio una bella cosa ...
Disabilito cmq la write cache o no ?
Scusate le domande stupide ma oggi mi sento più rimbambito del solito ...
_________________
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 |
|
|
!equilibrium
Bodhisattva
Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC
|
| Posted: Wed Mar 14, 2007 3:20 pm Post subject: |
|
|
| Kernel78 wrote: | | Code: | Filesystem "md0": Disabling barriers, not supported by the underlying device
XFS mounting filesystem md0
Ending clean XFS mount for filesystem: md0
|
Mi sembra di capire che non è proprio una bella cosa ...
Disabilito cmq la write cache o no ?
Scusate le domande stupide ma oggi mi sento più rimbambito del solito ... |
no, e' tutto normale.
md0 sicuramente e' un software raid, in tal caso le barrier vengono disabilitate automaticamente dal kernel, perche' md0 non e' una periferica vera ma e' virtuale (sono due partizioni fuse in una) e quindi il kernel non sa come gestire alcuni aspetti della periferica.
per quanto concerne la write cache, disabilita pure, metti -W0 in /etc/conf.d/hdparm per tutti i drive e sei a posto.
/NOTA: prometto che entro oggi aggiorno la presente guida.
_________________
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 |
|
|
|
|
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) 
