1) Why do we need to partition the hard disk before using it? Why do we really do it?
Multiple partitions are used for various reasons:
Disk space reservation: partitions are fixed-size; if you accidentally fill up /home to the brim and it's a separate partition, it will not affect the '/' partition and the OS will still have space for itself.
Ability to use different filesystems: e.g. you can use traditional ext4 for '/' but something fancy for '/var' or '/home'.
Usually the firmware and/or the bootloader only understand a very limited set of filesystems – e.g. UEFI machines only understand FAT32, but you certainly don't want to make the entire disk FAT32, so you have a small FAT32 partition with just the EFI-related files in it. Same goes for BIOS systems; many bootloaders only understand simple things like ext2 and wouldn't be able to load the kernel from zfs or btrfs.
Ability to have multiple operating systems on a single disk.
Taking advantage of the disk's physical properties, as described in more detail later.
Why partition a disk when you only want to have one partition? Well, that's not technically required for the disk to work, but it's usually done for consistency. When you already have a partition table and everything, going from 1 partition to multiple (or back) is easy. But if the entire disk is unpartitioned and simply mkfs'd, trying to partition it later can be very troublesome.
On BIOS/MBR systems, having a partition table also generally has the side effect that there's some unused space between the table and the 1st partition. Historically, the GRUB bootloader installed itself into that space. It's not really neat, but... that's what GRUB expects to be able to do on MBR disks. (Fortunately it no longer does the same on GPT disks, taking a regular partition instead.)
I'm doing this by providing the number of partitions as 1
That's not the total partition count; that's the ordinal number of the partition you're creating. The total doesn't need to be specified upfront.
I could see the significant difference in I/O time taken between my primary (which has five partitions in it as sda1, sda2 .. sda5) and secondary partition (which has only one partition sdb1) in it.
Do you mean primary and secondary disks? sda
and sdb
represent disks, not partitions. (And partitions having their own partitions won't make much sense.)
Most of it is likely caused by the disks themselves being physically different. Check what models they are, etc.. For example, a 7200rpm disk will be faster than a 5400rpm disk of the same age, and a modern 5400rpm disk will still be faster than a 15-year-old 5400rpm disk due to increased data density, and a "healthy" disk will be faster than a disk with many reallocated bad sectors due to the latter needing to make many detours when reading data. I'd expect a SATA/AHCI-connected disk to work faster than an IDE-connected disk as well.
But...
2) Will the number of partitions impact the I/O speed?
The number of partitions, by itself, will not. Neither will the partition type ("primary" vs "secondary" is just a hack to get around limitations in the old MBR partitioning format, it doesn't affect the working of a partition itself).
But as you've noticed, areas closer to the "beginning" of the disk work faster than areas near the "end" of the disk, because they tend to physically correspond to the outer and inner areas of the actual spinning disk.
So when you have one large partition across the entire disk, the OS will distribute files more or less evenly throughout the physical disk area; some of them will be in the 'fast' end, some in the 'slow' end. But when you have several small partitions, the 1st partition (first by starting sector, not by list position) will get all the benefits.
(disclaimer: this is probably total nonsense)