Os méritos de um sistema de arquivos sem partição

39

Encontrei algumas semanas atrás que nunca tinha visto antes: Um sistema de arquivos (ext3, acredito) instalado em um dispositivo de armazenamento sem uma partição. Em essência, /dev/sdb era todo o sistema de arquivos. Sei que muitos sistemas de arquivos podem ser estendidos para o espaço vazio, portanto, isso permite estender sem lidar com o LVM ou algum outro tipo de gerenciador de volumes, mas existem outras vantagens em configurar o armazenamento dessa maneira?

O caso específico que vi foi como o volume efêmero de dados de um servidor de processamento de números, os volumes de inicialização e raiz eram partições tradicionais em um dispositivo de armazenamento completamente diferente. -

filesystems partition lvm

— sysadmin1138
fonte

O Oracle VM também faz isso - para "armazenamento local".

— Nils

3

Eu perdi essa pergunta e iniciei uma nova que abrange o mesmo terreno: unix.stackexchange.com/q/52389/4801 . Essa pergunta foi encerrada, mas algumas das respostas também podem ser úteis para os leitores deste Q e podem ser mescladas aqui.

— precisa saber é o seguinte

11

... e outro em unix.stackexchange.com/questions/206141/…

— derobert

Funciona, mas leva a problemas que acabam perdendo tempo, como mostrado aqui - access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… .

— slm

24

Pro: você não desperdiça um setor de disco em uma tabela de partição. (Yay.)

Pro: o disco pode ser usado em um sistema operacional que não suporta partições no estilo PC. (Como você vai usar um.)

Con: isso é incomum e pode confundir co-administradores de sistemas. (Vejo?)

Contras: se você instalar outro sistema operacional, poderá pensar que o disco contém lixo e facilitar a substituição acidental do mesmo selecionando o disco errado - enquanto os sistemas operacionais geralmente deixam de lado partições cujo tipo elas não entendem.

Irrelevante: estender o sistema de arquivos não é mais fácil se estiver diretamente no disco do que em uma partição, nem vice-versa. Estar no LVM tornaria mais fácil.

Conclusão: funciona, mas não é uma boa ideia.

— Gilles 'SO- parar de ser mau'
fonte

2

Confusão, ahoy! Atualmente, meu medidor interno está inclinado a "tentativa equivocada de otimização".

— sysadmin1138 29/05

6

outro golpe: torna mais difícil dividir posteriormente a partição em dois.

— Kim

3

Deparei-me com as perguntas e respostas do superusuário, que tem bons exemplos de uso hexdumpe odque mostram em termos muito concretos o que está acontecendo com uma configuração /dev/sdavs .. /dev/sda1

— Slm

4

É um pouco mais simples estender o volume em um disco inteiro, pois você não precisa estender a partição primeiro.

— Psusi

2

Em um ambiente não comercial, a instalação de outro sistema operacional pode ser relevante - mas quem faz o boot múltiplo em um ambiente comercial? Estou perturbado que esta seja a resposta canônica. Nada de errado com isso, exceto que é opinião. Estou em cima do muro sobre o uso de disco sem partição, mas algumas boas razões são apresentadas abaixo.

— Graham Nicholls

18

Não tem certeza de como isso se aplicaria ao Linux, mas com o ZFS nativo, um motivo pelo qual é recomendável criar conjuntos em discos inteiros e não em partições é no caso anterior que o cache de gravação em disco pode ser ativado.

Várias outras razões também mencionadas aqui:

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools

Conclusão: funciona e pode ser uma boa ideia, dependendo do sistema de arquivos.

— jlliagre
fonte

Bom saber. Nesse caso específico, estava na nuvem! portanto, o armazenamento é bastante abstrato no momento da configuração do sistema.

— sysadmin1138 30/05

11

O que diabos o cache de gravação em disco tem a ver com a existência ou não de uma tabela de partição?

— Psusi

3

O cache de gravação não pode ser ativado no nível da partição. Quando ativado, afeta o disco como um todo. Se um sistema de arquivos estiver usando um disco inteiro, ele "possui" esse disco para poder ativar e desativar esse cache sem nenhum risco colateral. Caso contrário, isso poderá afetar outro consumidor de disco, necessitando que o cache seja desativado por seus próprios motivos.

— Jlliagre

4

Claro, mas ter o sistema operacional ativando o cache de maneira ofuscante sem conhecer os requisitos do consumidor do sistema de arquivos ou do dispositivo bruto não é uma abordagem confiável. Existem aplicativos como bancos de dados que precisam garantir que uma transação confirmada esteja no disco e não apenas na memória.

— Jlliagre

11

@psusi Se o fsync descarregará o cache do disco ou não parece depender do sistema de arquivos.

— Jlliagre

16

Vejo o benefício real quando isso é feito em um ambiente virtual. Como nossos VMDKs são armazenados em nosso NAS, podemos aumentá-los dinamicamente.

Se estamos usando partições, precisamos usar o LVM (e a sobrecarga associada a ele) e encadear as partições juntas, ou precisamos derrubar o host (ou o sistema de arquivos, se não estiver em uso) para usar algo como gparted.

No entanto, se você usar o disco inteiro em vez de uma partição, poderá forçar uma nova varredura nos discos SCSI e usar o resize2fs para aumentar o sistema de arquivos enquanto estiver online (e em uso!).

— Nick Gasparovich
fonte

Bom ponto! Com discos virtuais (como você pode criar, remover e redimensioná-los conforme necessário), as partições parecem ser uma camada inútil.

— Pabouk

11

Colocar um sistema de arquivos em um dispositivo de disco sem criar nenhuma partição não é incomum.

Vantagens:

quando você quiser usar todo o espaço de qualquer maneira, não precisará perder tempo com alguma ferramenta de particionamento
você não precisa se preocupar com incompatibilidades do formato de partição 'padrão' (btw, qual formato de partição é o padrão, o DOS, o BSD?); por exemplo, o formato de partição DOS permite apenas partições de até 2 TB ao usar Setores lógicos de 512 bytes!
você não precisa se preocupar com problemas de alinhamento induzido por partição em unidades com tamanhos de setor (atualmente) incomuns (por exemplo, 4 k) - com certeza, as distribuições atuais devem enviar ferramentas de particionamento que corrigem o alinhamento com diferentes tamanhos de setor

Ser capaz de redimensionar um sistema de arquivos em um dispositivo bruto não é um bom motivo. O espaço que você economiza dessa maneira não pode ser usado para outras coisas. Assim, você pode criar diretamente o sistema de arquivos em todo o dispositivo.

— maxschlepzig
fonte

2

Uma resposta que não foi listada é: se você não criar uma partição, não precisará esperar pelo Kernel para detectá-la, o que pode ocorrer apenas após uma reinicialização.

Um caso de uso pode ser um volume EC2 EBS que você adiciona ao nó e deseja inicializar na primeira inicialização.

Se o seu processo de inicialização criar uma partição, você corre o risco de ter que reiniciar o Kernel para ver a partição recém-criada. Você normalmente vê uma mensagem como:

Erro: Erro ao informar o kernel sobre modificações na partição / dev / xvde1 - Dispositivo ou recurso ocupado. Isso significa que o Linux não saberá sobre as alterações feitas no / dev / xvde1 até a reinicialização - portanto, você não deve montá-lo ou usá-lo de qualquer forma antes de reiniciá-lo.

Nesse caso, seu processo de inicialização precisaria executar uma reinicialização e continuar adicionando um sistema de arquivos à partição recém-criada.

Se você sabe que precisará apenas de uma única partição, pode ignorá-la, sem correr o risco de exigir uma reinicialização.

— lloesche
fonte