What's the advantage of keeping the sdb1 partition in a single 455 Gb? Is there any reason why I should divide it in more partitions?

Disk /dev/sda: 119.2 GiB, 128035676160 bytes, 250069680 sectors

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1            2048 233066495 233064448 111.1G 83 Linux
/dev/sda2       233066496 250068991  17002496   8.1G 82 Linux swap / Solaris

Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sdb1            2048 955283455 955281408 455.5G  7 HPFS/NTFS/exFAT
/dev/sdb2       955283456 976773119  21489664  10.3G 82 Linux swap / Solaris
  • From a storage standing point it's better to keep similar types of data in a single partition rather than mixing things up, and separating the OS from the data is always a good idea in case of a system failure. – Muaad ElSharif Apr 13 '17 at 8:34
  • For all previous comments: it's not an OS disk, it's an extra drive for data and (extra) swap. The OS disk is an SSD with its own swap. – ubuntubu Apr 13 '17 at 8:39
  • You probably don't need one swap let alone two (the one in sda2 isn't being used anyway). For the rest, partitioning - single or multiple - is the way OSes handle drives, it's how the OSes can read/write to the drives. Not an option. – user589808 Apr 13 '17 at 9:40
  • My mistake, the one not working is sdb2 and the differences are quite easy to spot. – user589808 Apr 13 '17 at 15:55

It's usually best to keep a partition table on a disk, even if that disk has nothing but a single partition. Reasons for this include:

  • Flexibility -- With a partition table on the disk, it's (relatively) easy to shrink the partition to create room for additional partition(s), should your needs change in the future. Without a partition table, this task becomes much harder.
  • Identification -- It's pretty much standard for hard disks to have partition tables. If you put a filesystem directly on a disk, without a partition table, a tool that scans disks and assumes that the disk has a partition table may misidentify the disk, possibly doing bad things to it. That said, I can't cite a specific utility that does this; but given the sheer number of obscure tools out there, and the potentially catastrophic consequences of an error, do you want to take the chance? Similar arguments can be made for instructions you might read on the Internet -- a procedures that assumes a disk contains a partition table, if followed blindly and applied to a disk without a partition table, could wreak havoc.
  • Partition table metadata -- Partition tables provide metadata that can help identify the disk's purpose. These include partition type codes, assorted flags, and (on GPT disks) partition names. These features may be redundant with features provided by the filesystem you use, but you may find uses for them nonetheless.
  • Why not? -- An MBR partition table consumes one sector on the disk, and depending on the way the partitioning software lays out the partitions, you'll lose a few more sectors (up to perhaps a couple MB of disk space) beyond that. GPT uses more sectors, but chances are you'll lose no more disk space with GPT than with MBR. Given the sizes of modern disks, the lost disk space is trivial, whereas the preceding advantages are much more significant. Thus, the argument against partitioning a disk is very weak.
| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.