37 Memória persistente #

Essa forma de acesso à memória não é transacional. Em caso de queda de energia ou outra falha no sistema, os dados podem não ser gravados no armazenamento. O armazenamento PMEM será adequado apenas se o aplicativo puder resolver a situação dos dados parcialmente gravados.

Isso é útil quando você deseja usar a memória persistente em um conjunto de NVDIMMs como um pool do tipo disco de armazenamento rápido. Por exemplo, ao colocar o diário do sistema de arquivos na PMEM com BTT, você aumenta a confiabilidade da recuperação do sistema de arquivos após uma queda de energia ou outra interrupção repentina (consulte a Seção 37.5.3, “Criando um namespace PMEM com BTT”).

Para aplicativos, esses dispositivos aparecem como SSDs rápidas e podem ser usados como qualquer outro dispositivo de armazenamento. Por exemplo, a LVM pode ser colocada em camadas sobre a memória persistente e funcionará normalmente.

A vantagem do BTT é que a atomicidade de gravação do setor é garantida; portanto, até os aplicativos sofisticados que dependem da integridade dos dados continuarão funcionando. O relatório de erros da mídia funciona por meio dos canais de geração de relatórios de erros.

É possível usar o comando ndctl list para listar todos os NVDIMMs disponíveis em um sistema.

No exemplo a seguir, o sistema tem três NVDIMMs, que estão em um único conjunto de canal triplo intercalado.

# ndctl list --dimms

[
 {
  "dev":"nmem2",
  "id":"8089-00-0000-12325476"
 },
 {
  "dev":"nmem1",
  "id":"8089-00-0000-11325476"
 },
 {
  "dev":"nmem0",
  "id":"8089-00-0000-10325476"
 }
]

Com um parâmetro diferente, o ndctl list também listará as regiões disponíveis.

Nota

As regiões podem não aparecer em ordem numérica.

Apesar de haver apenas três NVDIMMs, eles aparacem como quatro regiões.

# ndctl list --regions

[
 {
  "dev":"region1",
  "size":68182605824,
  "available_size":68182605824,
  "type":"blk"
 },
 {
  "dev":"region3",
  "size":202937204736,
  "available_size":202937204736,
  "type":"pmem",
  "iset_id":5903239628671731251
  },
  {
   "dev":"region0",
   "size":68182605824,
   "available_size":68182605824,
   "type":"blk"
  },
  {
   "dev":"region2",
   "size":68182605824,
   "available_size":68182605824,
   "type":"blk"
  }
]

O espaço está disponível em dois formatos diferentes: como três regiões separadas de 64 do tipo BLK ou como uma região combinada de 189 GB do tipo PMEM, que apresenta todo o espaço nos três NVDIMMs intercalados como um único volume.

Observe que o valor exibido para available_size é igual ao de size. Isso significa que nada do espaço ainda foi alocado.

Para o primeiro exemplo, configuraremos nossos três NVDIMMs em um único namespace PMEM com Acesso Direto (DAX).

A primeira etapa é criar um novo namespace.

# ndctl create-namespace --type=pmem --mode=fsdax --map=memory
{
 "dev":"namespace3.0",
 "mode":"memory",
 "size":199764213760,
 "uuid":"dc8ebb84-c564-4248-9e8d-e18543c39b69",
 "blockdev":"pmem3"
}

Esse procedimento cria um dispositivo de blocos /dev/pmem3, que suporta DAX. O 3 no nome do dispositivo é herdado do número da região pai, neste caso, region3.

A opção --map=memory separa parte do espaço do armazenamento PMEM nos NVDIMMs para que ele possa ser usado para alocar as estruturas de dados internas do kernel chamadas struct pages. Isso permite que o novo namespace PMEM seja usado com recursos como O_DIRECT I/O e RDMA.

A reserva de parte da memória persistente para estruturas de dados do kernel é o que causa uma redução na capacidade do namespace PMEM em relação à região PMEM pai.

Na sequência, verificamos se o novo dispositivo de blocos está disponível para o sistema operacional:

# fdisk -l /dev/pmem3
Disk /dev/pmem3: 186 GiB, 199764213760 bytes, 390164480 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Antes que possa ser usada, como qualquer outra unidade, ela deverá ser formatado. Neste exemplo, nós a formatamos com XFS:

# mkfs.xfs /dev/pmem3
meta-data=/dev/pmem3      isize=256    agcount=4, agsize=12192640 blks
         =                sectsz=4096  attr=2, projid32bit=1
         =                crc=0        finobt=0, sparse=0
data     =                bsize=4096   blocks=48770560, imaxpct=25
         =                sunit=0      swidth=0 blks
naming   =version 2       bsize=4096   ascii-ci=0 ftype=1
log      =internal log    bsize=4096   blocks=23813, version=2
         =                sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none            extsz=4096   blocks=0, rtextents=0

Em seguida, podemos montar a nova unidade em um diretório:

# mount -o dax /dev/pmem3 /mnt/pmem3

Agora, podemos verificar que temos um dispositivo compatível com DAX:

# mount | grep dax
/dev/pmem3 on /mnt/pmem3 type xfs (rw,relatime,attr2,dax,inode64,noquota)

O resultado é que agora contamos com um namespace PMEM formatado com o sistema de arquivos XFS e montado com DAX.

Qualquer chamada mmap() para arquivos nesse sistema de arquivos retornará endereços virtuais que são mapeados diretamente para a memória persistente em nossos NVDIMMs, ignorando o cache de página.

Qualquer chamada fsync ou msync nos arquivos nesse sistema de arquivos ainda garantirá que os dados modificados sejam totalmente gravados nos NVDIMMs. Essas chamadas descarregam as linhas de cache do processador associadas a qualquer página que tenha sido modificada no espaço do usuário por meio de mapeamentos mmap.

# umount /mnt/pmem3

# ndctl disable-namespace namespace3.0
disabled 1 namespace

# ndctl destroy-namespace namespace3.0
destroyed 1 namespace

A BTT oferece atomicidade de gravação de setores, o que faz dela uma boa opção quando você precisa de proteção de dados para diários do Ext4 e XFS. Em caso de queda de energia, os diários estão protegidos e podem ser recuperados. Os exemplos a seguir mostram como criar um namespace PMEM com BTT no modo de setor e como colocar o diário do sistema de arquivos nesse namespace.

# ndctl create-namespace --type=pmem --mode=sector
{
 "dev":"namespace3.0",
 "mode":"sector",
 "uuid":"51ab652d-7f20-44ea-b51d-5670454f8b9b",
 "sector_size":4096,
 "blockdev":"pmem3s"
}

Em seguida, verifique se o novo dispositivo está presente:

# fdisk -l /dev/pmem3s
Disk /dev/pmem3s: 188.8 GiB, 202738135040 bytes, 49496615 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Como o namespace PMEM compatível com DAX que configuramos anteriormente, esse namespace PMEM compatível com BTT consome todo o armazenamento disponível nos NVDIMMs.

Nota

O s à direita do nome do dispositivo (/dev/pmem3s) indica o sector e pode ser usado para diferenciar facilmente os namespaces configurados para usar a BTT.

É possível formatar e montar o volume como no exemplo anterior.

O namespace PMEM mostrado aqui não pode usar DAX. Em vez disso, ele usa o BTT para fornecer atomicidade de gravação do setor. Em cada gravação de setor efetuada por meio do driver de bloco PMEM, o BTT alocará um novo setor para receber os novos dados. O BTT atualizará atomicamente suas estruturas de mapeamento internas depois que os novos dados forem totalmente gravados para que os dados recém-gravados ainda fiquem disponíveis aos aplicativos. Se acabar a força a qualquer momento durante esse processo, a gravação será perdida, e o aplicativo terá acesso a seus dados antigos, ainda intactos. Isso impede a condição conhecida como “setores interrompidos”.

Esse namespace PMEM habilitado para BTT pode ser formatado e usado com um sistema de arquivos como qualquer outro dispositivo de blocos padrão. Ele não pode ser usado com DAX. No entanto, os mapeamentos mmap para os arquivos nesse dispositivo de blocos usarão o cache de página.

Quando você coloca o diário do sistema de arquivos em um dispositivo separado, ele deve usar o mesmo tamanho de bloco que o sistema de arquivos. O tamanho mais provável é 4096, e você pode saber o tamanho do bloco com este comando:

# blockdev --getbsz /dev/sda3

O exemplo a seguir cria um novo diário do Ext4 em um dispositivo NVDIMM separado, cria o sistema de arquivos em um dispositivo SATA e, em seguida, anexa o novo sistema de arquivos ao diário:

# mke2fs -b 4096 -O journal_dev /dev/pmem3s
# mkfs.ext4 -J device=/dev/pmem3s /dev/sda3

O exemplo a seguir cria um novo sistema de arquivos XFS em uma unidade SATA e cria o diário em um dispositivo NVDIMM separado:

# mkfs.xfs -l logdev=/dev/pmem3s  /dev/sda3

Consulte man 8 mkfs.ext4 e man 8 mkfs.ext4 para obter informações detalhadas sobre as opções.