Re: XFS soft quota e NFS
Ciao Diego, Il giorno mer, 09/11/2022 alle 12.23 +0100, Diego Zuccato ha scritto: > Tanto per aggiungere qualche altro dato: > > redacted: $ quota -i > Disk quotas for user redacted (uid 2126002096): > Filesystem space quota limit grace files quota limit > grace > 137.204.x.y:/srv/nfs/str957-cluster/home/ > 51288M* 51200M 76800M 6days 70425 0 0 > > redacted: :~$ echo test > testfile > -bash: testfile: Disk quota exceeded [...] Che succede se lo stesso utente scrive direttamente sul server NFS, cioè sul file system XFS? Giusto per essere sicuri che sia un problema di NFS e non di XFS. Ciao, Giuseppe
Re: Failed to start Proxmox VE replication runner
Il 09/11/2022 14:06, Piviul ha scritto: anch'io ero arrivato a quella conclusione cioé che venivano ridirezionati verso l'ultimo mac address che aveva usato il bond (avevo detto ip ma in effetti non è giusto, il bond non sa nulla degli ip...) e se il bond contemporaneamente è utilizzato da più macchine con mac address differenti succedeva che alcuni pacchetti venivano ridirezionati al mac address sbagliato e quindi ignorati e mano a mano che il traffico aumentava i pacchetti persi aumentavano a dismisura... ma in effetti non dovrebbe succedere nulla se il bond viene usato da una macchina sola... mi sa che ci riproverò. Mi sa che ci fosse qualche problema di altro genere. A meno che tu non avessi VM che condividevano l'IP e che fossero in esecuzione su due Proxmox diversi. Se hai un solo Proxmox, anche con tante VM, i MAC address "saltellano" un po' tra le due interfacce ma al limite lo switch a monte inoltra i pacchetti ad entrambe (sprechi metà della banda in ricezione e la VM riceve pacchetti duplicati). Se hai più Proxmox, ma con VM che lavorano su IP diversi, semplicemente si affiancano situazioni del singolo Proxmox, e ancora non dovresti perdere nulla. Se invece hai p.e. 2 OPNSense in VM e usi un singolo VIP, se metti le due VM su due Proxmox gli switch si vedono arrivare un MAC address da 4 interfacce diverse e potrebbero non gradire... la banda è sempre un problema ;) e in assenza di standard legarsi ad una tipologa di switch che immagino siano anche molto costosi... anche no, grazie! Non posso che condividere. Ma magari puoi valutare soluzioni di bonding diverse, con diverse opzioni per l'hashing. -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: Failed to start Proxmox VE replication runner
On 09/11/22 11:41, Diego Zuccato wrote: Il 09/11/2022 08:29, Piviul ha scritto: io perdevo proprio dei pacchetti perché venivano ridirezionati all'ultimo ip che aveva usato il bond. È passato qualche anno ma mi sembra di ricordare proprio così... Uh? Gli switch dovrebbero al limite ridirezionarli all'ultimo MAC che ha usato il bond, e questo non provoca la perdita di pacchetti (a meno di guasti): il bond, in ricezione, dovrebbe essere interface-agnostic. anch'io ero arrivato a quella conclusione cioé che venivano ridirezionati verso l'ultimo mac address che aveva usato il bond (avevo detto ip ma in effetti non è giusto, il bond non sa nulla degli ip...) e se il bond contemporaneamente è utilizzato da più macchine con mac address differenti succedeva che alcuni pacchetti venivano ridirezionati al mac address sbagliato e quindi ignorati e mano a mano che il traffico aumentava i pacchetti persi aumentavano a dismisura... ma in effetti non dovrebbe succedere nulla se il bond viene usato da una macchina sola... mi sa che ci riproverò. Una soluzione ancora migliore sarebbe l'aggregazione con LACP, ma pochi switch permettono di gestire uno "switch virtuale" con bond LACP e connessioni a due switch fisici differenti. questo è molto interessante... Quindi gli switch quale standard dovrebbero seguire per poter gestire uno "switch virtuale" per fare una bond LACP con switch differenti? Non mi risulta esistere uno standard. Mi pare che lo facessero alcuni HP di fascia alta, configurando uno "switch virtuale" che utilizza più switch fisici: a quel punto basta definire un trunk LACP inserendogli porte di due switch fisici diversi. Altrimenti, se la banda non è un problema, basta un semplice failover. la banda è sempre un problema ;) e in assenza di standard legarsi ad una tipologa di switch che immagino siano anche molto costosi... anche no, grazie! Grazie ancora Piviul
Re: XFS soft quota e NFS
Ciao Marco. Da quel che vedo, warnquota funziona solo su filesystem locali (e ho già uno script sul server che ogni domenica mi manda un report di quanto stanno usando), non su NFS. E il problema che ho riscontrato è che appena l'utente raggiunge il soft limit (50G), NFS gli impedisce di scrivere come se avesse raggiunto l'hard limit (75G) :( Se può servire, uso NFS v3. Diego Il 09/11/2022 08:16, Marco Gaiarin ha scritto: Mandi! Diego Zuccato In chel di` si favelave... Quello che volevo ottenere era di ricevere io un avviso con un discreto margine, per segnalare all'utente che sta occupando troppo disco, non impedirgli di lavorare... 'warnquota'? Al superamento della 'soft limit' (su spazio o inode) warnquota dovrebbe iniziare a scassare gli zebedei agli uteti per il tempo stabilito. Solo quando si superano le hard quota, o quando si superano le soft quota per un tempo superiore al stabilito,l'accesso in scrittura al FS è interrotto... -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: XFS soft quota e NFS
Tanto per aggiungere qualche altro dato: redacted: $ quota -i Disk quotas for user redacted (uid 2126002096): Filesystem space quota limit grace files quota limit grace 137.204.x.y:/srv/nfs/str957-cluster/home/ 51288M* 51200M 76800M 6days 70425 0 0 redacted: :~$ echo test > testfile -bash: testfile: Disk quota exceeded Da una parte vede che l'utente ha superato solo la soft quota, ma poi non fa scrivere... Ci sto uscendo pazzo. Diego Il 09/11/2022 12:00, Diego Zuccato ha scritto: Ciao Marco. Da quel che vedo, warnquota funziona solo su filesystem locali (e ho già uno script sul server che ogni domenica mi manda un report di quanto stanno usando), non su NFS. E il problema che ho riscontrato è che appena l'utente raggiunge il soft limit (50G), NFS gli impedisce di scrivere come se avesse raggiunto l'hard limit (75G) :( Se può servire, uso NFS v3. Diego Il 09/11/2022 08:16, Marco Gaiarin ha scritto: Mandi! Diego Zuccato In chel di` si favelave... Quello che volevo ottenere era di ricevere io un avviso con un discreto margine, per segnalare all'utente che sta occupando troppo disco, non impedirgli di lavorare... 'warnquota'? Al superamento della 'soft limit' (su spazio o inode) warnquota dovrebbe iniziare a scassare gli zebedei agli uteti per il tempo stabilito. Solo quando si superano le hard quota, o quando si superano le soft quota per un tempo superiore al stabilito,l'accesso in scrittura al FS è interrotto... -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: Failed to start Proxmox VE replication runner
Il 09/11/2022 08:29, Piviul ha scritto: io perdevo proprio dei pacchetti perché venivano ridirezionati all'ultimo ip che aveva usato il bond. È passato qualche anno ma mi sembra di ricordare proprio così... Uh? Gli switch dovrebbero al limite ridirezionarli all'ultimo MAC che ha usato il bond, e questo non provoca la perdita di pacchetti (a meno di guasti): il bond, in ricezione, dovrebbe essere interface-agnostic. Una soluzione ancora migliore sarebbe l'aggregazione con LACP, ma pochi switch permettono di gestire uno "switch virtuale" con bond LACP e connessioni a due switch fisici differenti. questo è molto interessante... Quindi gli switch quale standard dovrebbero seguire per poter gestire uno "switch virtuale" per fare una bond LACP con switch differenti? Non mi risulta esistere uno standard. Mi pare che lo facessero alcuni HP di fascia alta, configurando uno "switch virtuale" che utilizza più switch fisici: a quel punto basta definire un trunk LACP inserendogli porte di due switch fisici diversi. Altrimenti, se la banda non è un problema, basta un semplice failover. -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: Failed to start Proxmox VE replication runner
On 09/11/22 08:21, Diego Zuccato wrote: [...] Te lo chiedo perché avevo fatto un po' di prove anche con bond alb ma perdevo dei pacchetti. Mi sembra di ricordare però che la causa l'avevo imputata al fatto che avendo messo in bond alb le interfacce dedicate alla lan e siccome più vm le usavano con ip diversi nel caso di traffico contemporaneo di più vm hosts il routing dei pacchetti si incasinava... avevo archiviato quindi il bond alb ma in questo caso tutto il traffico è generato da un solo IP, dovrebbe funzionare... è plausibile no? L'unico "problema" che ho rilevato è stato il flapping segnalato da ArpWatch e OpnSense perché vedono gli IP saltellare da un MAC all'altro. io perdevo proprio dei pacchetti perché venivano ridirezionati all'ultimo ip che aveva usato il bond. È passato qualche anno ma mi sembra di ricordare proprio così... Una soluzione ancora migliore sarebbe l'aggregazione con LACP, ma pochi switch permettono di gestire uno "switch virtuale" con bond LACP e connessioni a due switch fisici differenti. questo è molto interessante... Quindi gli switch quale standard dovrebbero seguire per poter gestire uno "switch virtuale" per fare una bond LACP con switch differenti? mille grazie Piviul
