Halfgaar's questions

Eu tenho um roteador Ubuntu 20.04 que usa seu próprio IP como servidor DNS obtido dos anúncios do roteador, criando loops DNS. Não consigo descobrir como ignorar o RDNSS (servidor DNS recursivo) dos anúncios do roteador.

Ciclo:

Jan 19 17:26:28 myrouter dnsmasq[1074014]: query[AAAA] mobile.events.data.trafficmanager.net from fe80::21b:21ff:fee0:a6b3
Jan 19 17:26:28 myrouter dnsmasq[1074014]: forwarded mobile.events.data.trafficmanager.net to 127.0.0.53
Jan 19 17:26:28 myrouter dnsmasq[1074014]: query[AAAA] mobile.events.data.trafficmanager.net from fe80::21b:21ff:fee0:a6b3
Jan 19 17:26:28 myrouter dnsmasq[1074014]: forwarded mobile.events.data.trafficmanager.net to 127.0.0.53

Configuração de rede:

• eth0 = não usado.
• eth1 = WAN. 99.99.99.162/24,2a01:xx:xx:xx::2/126
• eth2 = LAN1. 10.50.0.1/16,2a01:xx:xx:1337:10:50:0:1/64
• mais LANs, não relevante

network:
  version: 2
  renderer: networkd
  ethernets:
    eth1:
      match:
        macaddress: "00:1b:21:e0:a6:b2" <-- non-obfuscated
      set-name: eth1
      addresses:
        - 99.99.99.162/24
        - 2a01:xx:xx:xx::2/126
      gateway4: 99.99.99.161
      gateway6: 2a01:xx:xx:xx::1
      nameservers:
        addresses:
          - 33.33.33.10
          - 44.44.44.10
        search: [ company, company.nl ]
    eth2:
      match:
        macaddress: "00:1b:21:e0:a6:b3" <-- non-obfuscated; will appear as IPv6 fe80
      set-name: eth2
      addresses:
        - 10.50.0.1/16
        - 2a01:xx:xx:1337:10:50:0:1/64
      nameservers:
        addresses:
          - 33.33.33.10
          - 44.44.44.10

Dnsmasq liga em todos, exceto eth1e lo. Radvdumpmostra que após a reinicialização de dnsmasq, ele envia um anúncio de roteador com fe80::21b:21ff:fee0:a6b3RDNSS (servidor DNS recursivo). Nossos clientes parecem não entender, e usam apenas o IPv4. Mas, o próprio roteador faz:

Link 5 (eth2)
      Current Scopes: DNS                     
DefaultRoute setting: yes                     
       LLMNR setting: yes                     
MulticastDNS setting: no                      
  DNSOverTLS setting: no                      
      DNSSEC setting: no                      
    DNSSEC supported: no                      
  Current DNS Server: 33.33.33.10           
         DNS Servers: 44.44.44.10             
                      33.33.33.10           
                      fe80::21b:21ff:fee0:a6b3 <- appears a short while after 'netplan try'

Tentei desabilitar:

net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.lo.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0

Mas sem sorte. Alguma ideia?

Não deve ser tão difícil, mas não consigo descobrir como monitorar o status do RAID com o HPE Smart Array E208i-p SR Gen10, em um HP ProLiant DL360 Gen10 no Linux.

• Não consigo encontrar um arquivo em /procou /sys.
• arcconfdiz: Controllers found: 0.
• ssacli controller all showdiz:Error: No controllers detected.
• O mesmo para HP SSA CLI :Error: No controllers detected.

Edit: ficou um pouco confuso porque este servidor possui dois controladores RAID, mas nenhum deles funciona até agora, então a pergunta é a mesma.

Esta é a lspci -vsaída do E208i-p:

  11:00.0 Serial Attached SCSI controller: Adaptec Smart Storage PQI 12G SAS/PCIe 3 (rev 01)
  Subsystem: Hewlett-Packard Company Smart Array E208i-p SR Gen10
  Physical Slot: 1
  Flags: bus master, fast devsel, latency 0, IRQ 26, NUMA node 0
  Memory at e2800000 (64-bit, non-prefetchable) [size=32K]
  I/O ports at 4000 [size=256]
  Capabilities: [80] Power Management version 3
  Capabilities: [b0] MSI-X: Enable+ Count=64 Masked-
  Capabilities: [c0] Express Endpoint, MSI 00
  Capabilities: [100] Advanced Error Reporting
  Capabilities: [300] #19
  Kernel driver in use: smartpqi
  Kernel modules: smartpqi

Este do P408i-a:

    b1:00.0 Serial Attached SCSI controller: Adaptec Smart Storage PQI 12G SAS/PCIe 3 (rev 01)
    Subsystem: Hewlett-Packard Company Smart Array P408i-a SR Gen10
    Flags: bus master, fast devsel, latency 0, IRQ 32, NUMA node 0
    Memory at f3800000 (64-bit, non-prefetchable) [size=32K]
    I/O ports at c000 [size=256]
    Capabilities: [80] Power Management version 3
    Capabilities: [b0] MSI-X: Enable+ Count=64 Masked-
    Capabilities: [c0] Express Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [300] #19
    Kernel driver in use: smartpqi
    Kernel modules: smartpqi

Versão Linux:

cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"

Edit: em um servidor de ordem ligeiramente, com 'Controladores Hewlett-Packard Company Smart Array Gen9 (rev 01) / Hewlett-Packard Company P440', a hpssacliferramenta funciona.

Um servidor virtual de 48 GB de RAM mantendo cerca de 25 mil conexões TCP (dispositivos em campo fazendo login para configurar um túnel SSH) ficou sem RAM e começou a trocar, ficando lento etc. Atualizamos e reinicializamos. Mesmo depois que as 25k conexões foram restauradas e a tempestade inicial de DDOS foi resolvida, o servidor agora mostrava uma enorme quantidade de uso do softirq. Como encontro a causa?

Aqui você pode ver os eventos:

É impressionante que não costumava haver muito softirq. Agora, existem 8 threads do kernel fazendo cerca de 60% da CPU ( ksoftirqdthreads).

Olhando para os gráficos de Munin, vejo que as interrupções de PCI-MSI 49153-edge virtio0-input.0aumentaram muito (cuidado com a escala log y):

A quantidade de tráfego de rede com a qual a máquina tem que lidar realmente não mudou.

Eu escrevi um script python rápido que mostra as interrupções por segundo, a cada segundo, /proc/interruptsde PCI-MSI 49153-edge virtio0-input.0, e geralmente é cerca de 50 a 100 por segundo, mas de vez em quando, há uma rajada de 5000 a 10000.

Porque no processo de atualização, o painel de controle do hoster da VM anunciou que precisava migrar a VM para outro servidor. Eu teorizei que esse servidor tem um controlador Ethernet diferente, controlador de interrupção emulado de maneira diferente ou qualquer outra coisa, mas eles até migraram a VM de volta e não há diferença.

Outra diferença é que a VM passou de vmlinuz-4.15.0-45-genericpara /boot/vmlinuz-4.15.0-72-generic. Com todos os patches de CPU da Intel ultimamente, posso imaginar algo escondido lá.

A grande questão é: como chegar à causa raiz ou obter mais informações de onde vêm essas interrupções? A reinicialização do servidor para o kernel antigo é possível, mas não desejável.

Entendo como o SPF está envolvido no alinhamento do DMARC, mas uma coisa não consigo esclarecer: a política do SPF ( -allou ~all) é usada no DMARC? Ou o DMARC apenas usa os intervalos de IP?

A questão é que, como todos sabemos, o SPF quebra o encaminhamento . DKIM é muito melhor quando se trata de encaminhamento. Então, agora que implementei o DKIM+DMARC, posso relaxar minha política de SPF porque o DMARC cuidará da verificação do alinhamento do SPF?

Fizemos a infeliz descoberta de que nossos servidores em nossa sala de servidores no escritório estão enferrujando. Isso veio à tona depois que o primeiro falhou.

Um candidato óbvio é a unidade AC, que algo está errado com sua regulação de umidade. Então, eu plotei a temperatura e a umidade. Muito a dizer, mas isso ilustra bem minha pergunta:

Em uma sala relativamente selada (1,5 por 2,5 metros ou mais), o fato de a umidade permanecer tão alta após cada ciclo do termostato é suspeito para mim. Também o fato de desligar o AC deu uma supressão tão óbvia dos picos de umidade.

Este é o comportamento normal do AC? Eu não esperava que a umidade voltasse sempre a um nível tão alto. Mesmo no lado direito do gráfico, ele não fica apenas baixo, ele 'quer' estabilizar bem alto.

Também examinei outras questões, como enxofre contendo partículas finas causando corrosão, mas, como está, é mais um pensamento abstrato. Não tenho ideia de como avaliar e/ou testar isso.

Eu também tive uma empresa de manutenção de ar condicionado / qualidade do ar olhando para isso, mas eles pareciam pensar em termos de qualidade do ar do escritório, e não conseguiam me acompanhar que os servidores têm requisitos diferentes das pessoas. Por um lado, a sugestão deles era bombear ar fresco para a sala continuamente. Parece-me ilógico.

Edit: um nível de zoom mais alto, veja também a correlação entre aumento/queda de temperatura e aumento/queda de umidade:

Isso e isso dizem que reject_rbl_clienté um arquivo smtpd_recipient_restriction. No entanto, os documentos do Postfix mostram que é apenas um smtpd_client_restriction, o que faz sentido para mim. Então, qual é?

Além disso, por que quando eu configuro um absurdo postfix checke service postfix reloadapenas aceito?

smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_client_hostname, reject_rbl_cliena bl.spamcop.net

E:

root@server: /etc/postfix # postfix check
root@server: /etc/postfix # echo $?
0
root@server: /etc/postfix #

E:

# service postfix reload
Reloading Postfix configuration...done.

Versão: 2.9.6-2 Debian 7 (Wheezy)

Percebi um problema de roteamento com IPv6 em nossa LAN. A maioria dos PCs clientes são thin clients LTSP. Eles obtêm um endereço por meio do SLAAC. Tracepath6para hosts na mesma sub-rede mostra que todo o tráfego é direto. Mas, o laptop em que estou trabalhando (Linux Mint 17, gerenciador de rede padrão), fornece a si mesmo dois endereços IPv6 e configura rotas para que todo o tráfego vá para o roteador primeiro, incluindo o tráfego na mesma sub-rede:

tracepath6 xxxx:1b0:5256:1337:10:50:0:8
 1?: [LOCALHOST]                        0.183ms pmtu 1500
 1:  xxxx:1b0:5256:1337:10:50:0:1                          1.217ms

Perguntas:

1) Por que alguns hosts obtêm um e alguns hosts mais endereços? Tenho visto isso acontecer com mais frequência.

2) Por que esta máquina está optando por rotear todo o tráfego pelo roteador?

O roteador é dnsmasq, e de fato só tem SLAAC:

Jan 22 11:34:36 gatekeeper dnsmasq-dhcp[9796]: IPv6 router advertisement enabled
Jan 22 11:34:36 gatekeeper dnsmasq-dhcp[9796]: DHCP, IP range 10.102.20.1 -- 10.102.20.254, lease time 12h
Jan 22 11:34:36 gatekeeper dnsmasq-dhcp[9796]: DHCP, IP range 10.101.20.1 -- 10.101.20.254, lease time 12h
Jan 22 11:34:36 gatekeeper dnsmasq-dhcp[9796]: DHCP, IP range 10.100.0.100 -- 10.100.0.254, lease time 12h
Jan 22 11:34:36 gatekeeper dnsmasq-dhcp[9796]: DHCP, IP range 10.50.20.1 -- 10.50.20.254, lease time 12h
Jan 22 11:34:36 gatekeeper dnsmasq-dhcp[9796]: SLAAC on xxxx:1b0:5256:1337:: prefix valid 2h

Este é o meu eth0:

eth0      Link encap:Ethernet  HWaddr 18:67:b0:34:2d:dd
          inet addr:10.50.20.158  Bcast:10.50.255.255  Mask:255.255.0.0
          inet6 addr: fe80::1a67:b0ff:fe34:2ddd/64 Scope:Link
          inet6 addr: xxxx:1b0:5256:1337:2532:eb1a:1151:d2f0/64 Scope:Global
          inet6 addr: xxxx:1b0:5256:1337:1a67:b0ff:fe34:2ddd/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12094 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17250 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2848542 (2.8 MB)  TX bytes:3002689 (3.0 MB)

Estas são as rotas IPv4:

> route -n 
Kernel IP routing table Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.50.0.1       0.0.0.0         UG    0      0        0 eth0
10.50.0.0       0.0.0.0         255.255.0.0     U     1      0        0 eth0

Estas são as rotas IPv6:

Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
fe80::/64                      ::                         U    256 1     0 eth0
::/0                           fe80::213:3bff:fe0f:c02c   UG   1   0     0 eth0
::/0                           fe80::213:3bff:fe0f:c02c   UGDAe 1024 0     0 eth0
::/0                           ::                         !n   -1  1   261 lo
::1/128                        ::                         Un   0   3   243 lo
xxxx:1b0:5256:1337:1a67:b0ff:fe34:2ddd/128 ::                         Un   0   1     0 lo
xxxx:1b0:5256:1337:2532:eb1a:1151:d2f0/128 ::                         Un   0   1    86 lo
fe80::1a67:b0ff:fe34:2ddd/128  ::                         Un   0   1   178 lo
ff00::/8                       ::                         U    256 1     0 eth0
::/0                           ::                         !n   -1  1   261 lo

A linha a seguir não está presente em hosts que acessam outros hosts diretamente:

::/0                           fe80::213:3bff:fe0f:c02c   UG   1   2     0 eth0

fe80::213:3bff:fe0f:c02cde fato, é o endereço de link local do roteador, do lado da LAN.

Editar: o comportamento que tenho visto pode ser aleatório. Reiniciei um dos thin clients várias vezes e um tracepath6 às vezes mostra o tráfego passando pelo roteador, às vezes diretamente para os hosts. É diferente quase a cada reinicialização, ao que parece. A tabela de roteamento é exatamente a mesma todas as vezes, também se eu ativar/desativar a opção dnsmasq off-link.

Edit2: O IPv4 sempre tem uma rota que indica que, para sua própria sub-rede, ele deve enviar apenas eth0, por exemplo. Então, quando adiciono essa rota no IPv6, o tráfego não passa mais pelo roteador:

/sbin/route -A inet6 add xxxx:1b0:5256:1337::/64 dev eth0

Então, por que xxxx:1b0:5256:1337::/64não está incluído por padrão (em qualquer máquina aqui)? Não deveria estar presente uma rota que diga ao kernel que, para a sub-rede atual, basta enviar pela Ethernet (ou wlan, qualquer que seja)?

Edit3: Acabei de olhar com tcpdump+wireshark e vi que o Lsinalizador, On-Link, não está definido no anúncio do roteador, apesar de off-link não estar definido:

dhcp-range=xxxx:1b0:5256:1337::, ra-only, inifite

Eu tenho um servidor Debian com MD raid (2 ativos, um sobressalente):

Personalities : [raid1] 
md1 : active raid1 sdc2[0] sdb2[1] sda2[2](S)
      1068224 blocks [2/2] [UU]

md0 : active raid1 sdc1[2](S) sdb1[1] sda1[0]
      487315584 blocks [2/2] [UU]
      bitmap: 5/233 pages [20KB], 1024KB chunk

unused devices: <none>

Sempre que inicializo este servidor, a matriz se degrada e começa a sincronizar o disco sobressalente. O problema é que parece ser porque há um disco USB conectado a ele, que atualmente é /dev/sdd. Ele inicializa bem quando este disco não está presente. /dev/sdd1, a única partição, não possui superbloco md e o tipo de partição é Linux, não raid autodetect.

Este é o detalhe do dispositivo espelho para md0:

mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Sun Jun  8 04:10:39 2008
     Raid Level : raid1
     Array Size : 487315584 (464.74 GiB 499.01 GB)
  Used Dev Size : 487315584 (464.74 GiB 499.01 GB)
   Raid Devices : 2
  Total Devices : 3
Preferred Minor : 0
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Sep 15 09:23:33 2015
          State : active 
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1

           UUID : 9e408fbb:563a5459:f999b789:24d3b44e
         Events : 0.83145

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1

       2       8       33        -      spare   /dev/sdc1

Os detalhes de /dev/sdc1realmente mostram que é sobressalente:

mdadm --examine /dev/sdc1
/dev/sdc1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 9e408fbb:563a5459:f999b789:24d3b44e
  Creation Time : Sun Jun  8 04:10:39 2008
     Raid Level : raid1
  Used Dev Size : 487315584 (464.74 GiB 499.01 GB)
     Array Size : 487315584 (464.74 GiB 499.01 GB)
   Raid Devices : 2
  Total Devices : 3
Preferred Minor : 0

    Update Time : Sat Sep 12 21:09:59 2015
          State : clean
Internal Bitmap : present
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1
       Checksum : 7761bb13 - correct
         Events : 83145


      Number   Major   Minor   RaidDevice State
this     2       8       33        2      spare   /dev/sdc1

   0     0       8        1        0      active sync   /dev/sda1
   1     1       8       17        1      active sync   /dev/sdb1
   2     2       8       33        2      spare   /dev/sdc1

Realmente nada fora do comum.

Qualquer ideia?

Editar:

O conteúdo relevante de /etc/mdadm/mdadm.conf:

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=9e408fbb:563a5459:f999b789:24d3b44e
   spares=1
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=e4578e57:9e0fd9e9:c7736f30:0e251564
   spares=1

Este tipo de correspondência com a saída de mdadm --detail --scan:

ARRAY /dev/md0 metadata=0.90 spares=1 UUID=9e408fbb:563a5459:f999b789:24d3b44e
ARRAY /dev/md1 metadata=0.90 spares=1 UUID=e4578e57:9e0fd9e9:c7736f30:0e251564

É talvez a nova linha?

• Kernel 3.2.0-4-686-pae.
• Debian 7.8
• mdadm - v3.2.5 - 18 de maio de 2012

Quando você tem LVM, você tem uma entrada para um agendador /sys/blockpara seus volumes físicos, mas também para cada volume lógico individual e o dispositivo bruto.

Temos um sistema Debian 6 LTS x64, kernel 2.6.32 rodando Xen hypervisor 4.0 (3Ware 9650 SE hardware RAID1). Ao executar máquinas virtuais em cada volume lógico, em qual delas você precisa definir o agendador se quiser influenciar como elas são agendadas pelo sistema operacional? Se você definir o volume lógico como deadline, isso fará alguma coisa quando o volume físico estiver definido como cfq? E se você definir o prazo final no volume lógico, esses prazos serão honrados mesmo quando o disco estiver lento devido a E/S em outros LVs definidos como cfq?

A pergunta está relacionada a E/S em VMs que desaceleram demais as outras VMs. Todos os convidados usam o noop como agendador internamente.

Edit: de acordo com isso , em um ambiente multipath, apenas o agendador do DM entrará em vigor. Portanto, se eu quiser lidar com o IO entre as máquinas virtuais de uma deadlinemaneira, tenho que definir o caminho DM do volume físico (dm-1 no meu caso) como deadline. Isso está certo? Há também um agendador para sdc, que é o dispositivo de bloco original do meu dm-1. Por que não deveria ser feito nisso?

edit2: mas alguém diz nos comentários que dm-0/1 não possui um agendador em kernels mais recentes:

famzah@VBox:~$ cat /sys/block/dm-0/queue/scheduler
none

No meu sistema (Debian 6, kernel 2.6.32), tenho:

cat /sys/block/dm-1/queue/scheduler 
noop anticipatory [deadline] cfq

A pergunta também é: eu tenho uma configuração de caminhos múltiplos? pvsmostra:

# pvs
PV         VG                 Fmt  Attr PSize PFree
/dev/dm-0  universe           lvm2 a-   5,41t 3,98t
/dev/dm-1  alternate-universe lvm2 a-   1,82t 1,18t

Mas eles foram criados com /dev/sd[bc]. Isso significa que tenho multipath, mesmo que seja uma configuração LVM padrão?

A questão principal, eu acho, é se devo definir o agendador em sdc ou dm-1? Se eu fizer iostat, vejo muito acesso em ambos:

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sdc               0,00     0,00   13,02   25,36   902,71   735,56    42,68     0,08    2,17   0,73   2,79
dm-1             82,25    57,26   12,97   25,36   902,31   735,56    42,72     0,18    4,73   0,84   3,23

Então, o que é o quê e quem é o chefe? Se for sdc, posso dizer que defini-lo como deadline não afeta o desempenho de minhas VMs. Olhando para a diferença nas colunas 'requests merged' (as duas primeiras), eu diria que é dm-1 que controla o agendamento.

Eu tenho um servidor (Debian 6 LTS) com um controlador RAID 3Ware 9650 SE. Existem dois arrays, um RAID1, um RAID6. Ele roda Xen 4.0, com cerca de 18 DomUs. O problema é que eu percebi que as tarefas de IO facilmente matam umas às outras. Acontece quando um DomU gera muitos IO, bloqueando os outros por alguns minutos, mas também aconteceu durante ddo 'ing.

Para mover um DomU de uma matriz RAID ocupada, usei dd. Ao fazer isso, meu Nagios não apenas relatou que outras VMs não respondiam, mas também recebi este aviso no Dom0:

[2015-01-14 00:38:07]  INFO: task kdmflush:1683 blocked for more than 120 seconds.
[2015-01-14 00:38:07]  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[2015-01-14 00:38:07]  kdmflush      D 0000000000000002     0  1683      2 0x00000000
[2015-01-14 00:38:07]   ffff88001fd37810 0000000000000246 ffff88001f742a00 ffff8800126c4680
[2015-01-14 00:38:07]   ffff88000217e400 00000000aae72d72 000000000000f9e0 ffff88000e65bfd8
[2015-01-14 00:38:07]   00000000000157c0 00000000000157c0 ffff880002291530 ffff880002291828
[2015-01-14 00:38:07]  Call Trace:
[2015-01-14 00:38:07]   [<ffffffff8106ce4e>] ? timekeeping_get_ns+0xe/0x2e
[2015-01-14 00:38:07]   [<ffffffff8130deb2>] ? io_schedule+0x73/0xb7
[2015-01-14 00:38:07]   [<ffffffffa0175bd6>] ? dm_wait_for_completion+0xf5/0x12a [dm_mod]
[2015-01-14 00:38:07]   [<ffffffff8104b52e>] ? default_wake_function+0x0/0x9
[2015-01-14 00:38:07]   [<ffffffffa01768c3>] ? dm_flush+0x1b/0x59 [dm_mod]
[2015-01-14 00:38:07]   [<ffffffffa01769b9>] ? dm_wq_work+0xb8/0x167 [dm_mod]
[2015-01-14 00:38:07]   [<ffffffff81062cfb>] ? worker_thread+0x188/0x21d
[2015-01-14 00:38:07]   [<ffffffffa0176901>] ? dm_wq_work+0x0/0x167 [dm_mod]
[2015-01-14 00:38:07]   [<ffffffff81066336>] ? autoremove_wake_function+0x0/0x2e
[2015-01-14 00:38:07]   [<ffffffff81062b73>] ? worker_thread+0x0/0x21d
[2015-01-14 00:38:07]   [<ffffffff81066069>] ? kthread+0x79/0x81
[2015-01-14 00:38:07]   [<ffffffff81012baa>] ? child_rip+0xa/0x20
[2015-01-14 00:38:07]   [<ffffffff81011d61>] ? int_ret_from_sys_call+0x7/0x1b
[2015-01-14 00:38:07]   [<ffffffff8101251d>] ? retint_restore_args+0x5/0x6
[2015-01-14 00:38:07]   [<ffffffff81012ba0>] ? child_rip+0x0/0x20

Eu tentei agendadores de prazo e cfq. Com o CFQ, não torna um DomU mais responsivo se eu definir os blkbackprocessos de back-end para prioridade de E/S em tempo real.

Dei ao Dom0 um sched-cred de 10000, pois ele precisa de um peso maior para atender todos os IO dos DomU's (e no meu caso não faz muito mais). Mas o que quer que eu defina, não deve influenciar o ddcomando e o kdmflushbloqueado, já que é tudo Dom0.

Esta é a tw_clisaída (apenas tinha um disco quebrado, daí a inicialização. Não está relacionado, porque o problema existe há muito tempo):

Unit  UnitType  Status         %RCmpl  %V/I/M  Stripe  Size(GB)  Cache  AVrfy
------------------------------------------------------------------------------
u0    RAID-6    INITIALIZING   -       89%(A)  256K    5587.9    RiW    ON     
u2    RAID-1    OK             -       -       -       1862.63   RiW    ON     

VPort Status         Unit Size      Type  Phy Encl-Slot    Model
------------------------------------------------------------------------------
p1    OK             u0   1.82 TB   SATA  1   -            WDC WD2000FYYZ-01UL 
p2    OK             u0   1.82 TB   SATA  2   -            ST32000542AS        
p3    OK             u0   1.82 TB   SATA  3   -            WDC WD2002FYPS-02W3 
p4    OK             u0   1.82 TB   SATA  4   -            ST32000542AS        
p5    OK             u0   1.82 TB   SATA  5   -            WDC WD2003FYYS-02W0 
p6    OK             u2   1.82 TB   SATA  6   -            WDC WD2002FYPS-02W3 
p7    OK             u2   1.82 TB   SATA  7   -            WDC WD2002FYPS-02W3 

Name  OnlineState  BBUReady  Status    Volt     Temp     Hours  LastCapTest
---------------------------------------------------------------------------
bbu   On           Yes       OK        OK       OK       0      xx-xxx-xxxx

Eu realmente acho isso bizarro e irritante. Tenho a sensação de que isso é uma peculiaridade do controlador RAID. Outras máquinas com RAID por software têm um desempenho muito melhor.

Espero que alguém possa me esclarecer.

Eu tenho um servidor Ubuntu executando o Bind9, que não faz recursão. Também não quero usá-lo para nenhum tipo de DNS local, porque pode não refletir o que o mundo exterior vê (obter registros obsoletos, por exemplo). Portanto, o próprio servidor sempre deve usar servidores DNS externos.

No entanto, resolvconf -uparece sempre colocar 127.0.0.1lá e não consigo desligá-lo.

127.0.0.1não ocorre em nenhum dos arquivos em /etc/resolvconf.

Isso pode ser evitado?

Recentemente, compramos um disco rígido USB3 Verbatim Store 'n' Save 4 TB para backups offline de nossos backups. Não funcionou no servidor (Linux) em que eu queria usá-lo e também não funcionou em uma máquina Windows Server 2008; a máquina Linux apenas produziu erros USB não descritos (impossível enumerar o dispositivo, erro -71 ou algo assim) e a máquina Windows não fez nada (nem apareceu no gerenciamento de armazenamento). No meu PC Linux funcionou. Foi então que percebi que estava dividido em duas unidades (não partições), para ser compatível com as tabelas de partições MBR. Eu suspeitei que esse era o motivo do disco não funcionar naquele servidor Linux, mas mesmo usando a ferramenta do Windows para configurar seu modo e defini-lo como contíguo não ajudou.

Suspeito que esse controlador USB para SATA especial com esse recurso extra de divisão tenha sido a causa da incompatibilidade. Mas agora uma loja está dizendo que 'algumas placas-mãe não suportam discos maiores que 2 TB'.

Essa última afirmação é precisa? Eu acho que cabe ao kernel do Linux suportá-lo ou não.