Les mérites d'un système de fichiers sans partition


39

Il y a quelques semaines, j'ai rencontré quelque chose que je n'avais jamais vu auparavant: un système de fichiers (ext3, je crois) installé sur un périphérique de stockage sans partition. Le système de fichiers dans son ensemble /dev/sdb était essentiellement . Je sais que de nombreux systèmes de fichiers peuvent être étendus dans un espace vide, ce qui permet de les étendre sans traiter avec LVM ou un autre type de gestionnaire de volume, mais existe-t-il d'autres avantages à configurer le stockage de cette manière?

Le cas spécifique que j’ai vu concernait le volume de données éphémère d’un serveur chargé de traiter des nombres, les volumes d’amorçage et racine étant des partitions traditionnelles sur un périphérique de stockage totalement différent. -


Oracle VM le fait également - pour le "stockage local".
Nils

3
J'ai raté cette question et commencé une nouvelle qui couvre le même terrain: unix.stackexchange.com/q/52389/4801 . Cette question est maintenant close, mais certaines des réponses pourraient également être utiles aux lecteurs de ce Q et pourraient être fusionnées ici.
dubiousjim


Fonctionne, mais conduit à des problèmes qui vont vous faire perdre du temps, comme indiqué ci-dessous - access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… .
slm

Réponses:


24

Pro: vous ne perdez pas un secteur de disque sur une table de partition. (Yay.)

Pro: le disque peut être utilisé dans un système d'exploitation qui ne prend pas en charge les partitions de type PC. (Comme vous allez en utiliser un.)

Con: Ceci est inhabituel et peut confondre les co-administrateurs. (Voir?)

Inconvénient: si vous installez un autre système d'exploitation, cela peut laisser penser que le disque contient des déchets et qu'il est facile de l'écraser accidentellement en sélectionnant le mauvais disque, alors que les systèmes d'exploitation laissent généralement seules les partitions dont ils ne comprennent pas le type.

Non pertinent: l'extension du système de fichiers n'est pas plus facile si c'est directement sur le disque que si c'est dans une partition, ni inversement. (Être sur LVM rendrait les choses plus faciles.)

Conclusion: ça marche, mais ce n'est pas une bonne idée.


2
Confusion, ahoy! Mon compteur interne est actuellement orienté vers "une tentative d'optimisation peu judicieuse".
sysadmin1138

6
un autre con: il est plus difficile de scinder ultérieurement la partition en deux.
Kim

3
Nous sommes tombés sur ce Q & A de superutilisateur qui contient de bons exemples hexdumpet odmontre très concrètement ce qui se passe avec une configuration /dev/sdavs. /dev/sda1
slm

4
Il est un peu plus simple d’étendre le volume sur un disque entier car il n’est pas nécessaire d’étendre la partition.
Psusi

2
Dans un environnement non commercial, l'installation d'un autre système d'exploitation peut être pertinente - mais qui peut effectuer plusieurs démarrages multiples dans un environnement commercial? Je suis dérangé que ce soit la réponse canonique. Rien de mal à cela, sauf que c'est l'opinion. Je suis sur la clôture sur l'utilisation de disques sans partition, mais quelques bonnes raisons sont données ci-dessous.
Graham Nicholls

18

Vous ne savez pas exactement comment cela s’appliquera à Linux, mais avec ZFS natif, il est recommandé de créer des pools sur des disques entiers et non des partitions, c’est dans le cas précédent que le cache en écriture disque peut être activé.

Plusieurs autres raisons ont également été mentionnées ici:

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

Conclusion: cela fonctionne et pourrait être une bonne idée en fonction du système de fichiers.


Bon à savoir. Dans ce cas précis, c'était dans le cloud! le stockage est donc assez lourdement abstraite au moment de la configuration du système.
sysadmin1138

1
Qu'est-ce que le cache d'écriture de disque a à voir avec le fait qu'une table de partition soit utilisée ou non?
psusi

3
Le cache en écriture ne peut pas être activé au niveau de la partition. Lorsqu'il est activé, cela affecte le disque dans son ensemble. Si un système de fichiers utilise un disque entier, il le "possède", ce qui lui permet d'activer et de désactiver ce cache sans risque de garantie. Sinon, cela pourrait affecter un autre consommateur de disque ayant besoin que ce cache soit désactivé pour ses propres raisons.
Juin

4
Bien sûr, mais si le système d'exploitation active aveuglément le cache sans connaître les exigences du système de fichiers ou du consommateur de périphériques, ce n'est pas une approche fiable. Il existe des applications telles que des bases de données qui doivent s'assurer qu'une transaction validée est sur le disque et pas seulement en mémoire.
jlliagre

1
@psusi Le fait de savoir si fsync videra le cache de disque ou non semble dépendre du système de fichiers.
jlliagre

16

Je vois le réel avantage lorsque cela est fait dans un environnement virtuel. Puisque nos VMDK sont stockés sur notre NAS, nous pouvons les développer de manière dynamique.

Si nous utilisons des partitions, nous devons soit utiliser LVM (et la surcharge qui lui est associée) et chaîner les partitions ensemble, soit supprimer l'hôte (ou le système de fichiers s'il n'est pas utilisé) pour utiliser quelque chose comme gparted.

Cependant, si vous utilisez le disque entier au lieu d'une partition, vous pouvez forcer une nouvelle analyse de vos disques SCSI et utiliser resize2fs pour développer le système de fichiers lorsqu'il est en ligne (et utilisé!).


Bon point! Avec les disques virtuels (comme vous pouvez les créer, les supprimer et les redimensionner à votre guise), les partitions semblent constituer une couche inutile.
Pabouk

11

Placer un système de fichiers sur une unité de disque sans créer de partition n'est pas si rare.

Avantages:

  • de toute façon, quand vous voulez utiliser tout l’espace, vous n’avez pas à perdre votre temps avec un outil de partitionnement
  • vous n'avez pas à vous soucier des incompatibilités du format de partition 'standard' (d'ailleurs, quel format de partition est le standard, le DOS, le BSD?), par exemple, le format de partition DOS n'autorise que les partitions jusqu'à 2 To lors de l'utilisation 512 octets de secteurs logiques!
  • vous n'avez pas à vous soucier des problèmes d'alignement induits par les partitions sur les disques avec des tailles de secteur inhabituelles (par exemple, 4 Ko) - bien sûr, les distributions actuelles doivent fournir des outils de partitionnement offrant un alignement correct avec différentes tailles de secteur

Pouvoir redimensionner un système de fichiers sur un périphérique brut n'est pas une bonne raison. L'espace que vous économisez ainsi ne peut pas être utilisé pour autre chose. Ainsi, vous pouvez créer directement le système de fichiers sur l’ensemble du périphérique.


2

Une réponse qui ne figure pas dans la liste est la suivante: si vous ne créez pas de partition, vous ne devez pas attendre que le noyau la détecte, ce qui pourrait n'être qu'après un redémarrage.

Un cas d'utilisation pourrait être un volume EBS EC2 que vous ajoutez au nœud et que vous souhaitez initialiser au premier démarrage.

Si votre processus d'initialisation crée une partition, vous risquez de devoir redémarrer pour que le noyau puisse voir la partition que vous venez de créer. Vous devriez généralement voir un message comme:

Erreur: erreur informant le noyau des modifications apportées à la partition / dev / xvde1 - Périphérique ou ressource occupé. Cela signifie que Linux ne saura rien des modifications que vous avez apportées à / dev / xvde1 tant que vous n’avez pas redémarré - vous ne devez donc pas le monter ni l’utiliser de quelque manière que ce soit avant de le redémarrer.

Dans ce cas, votre processus d'initialisation devra effectuer un redémarrage, puis continuer à ajouter un système de fichiers à la partition nouvellement créée.

Si vous savez que vous n'aurez besoin que d'une seule partition, vous pouvez également l'ignorer, ce qui ne risque pas de nécessiter un redémarrage.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.