I know that /dev/sda is the raw device, and that /dev/sda1 is the partition or virtual device.

But I'm a little confused as to why the sda# only comes up some of the time, or only on certain systems. What causes this to occur? Perhaps the times when the sda# drives don't appear is when it is unpartitioned? Or perhaps it's not the same across hardware?

And why can I mount both? (sometimes) Shouldn't the partition be the one mountable?

Any resources or color you can give would be greatly appreciated. Thank you in advance.

  • 1
    "And why can I mount both?" [citation needed] Commented Dec 8, 2011 at 12:33
  • 1
    @IgnacioVazquez-Abrams: I don't really have a citation. I mounted both on a Debian box, and I could write and read to both. Don't know why. Not really a hardware or sysadmin guy, which is why I was asking for clarification. Thanks again to everyone for helping!
    – decoy
    Commented Dec 20, 2011 at 20:41

4 Answers 4


On a modern system, a partition device will only appear if the partition actually exists.

On a disk with an MBR partition table, partition numbers 1 through 4 correspond to the four slots in the partition table, called "primary" partitions. They don't have to be filled sequentially, so it's possible, for example, to have an sda2 but no sda1. Partition numbers 5 and up correspond to "logical drives" in an extended partition, and those are always numbered sequentially, so you can't have an sda6 without having an sda5 too.

On a disk with a GPT partition table, there can be many more (typically up to 128) partitions, and all are "primary". So you could have a disk whose only partition is sda9, for example.

If the disk has no partition table, then it'll have no partition devices, of course.

Older systems — those using a static /dev rather than one managed by udev — will typically have device nodes for all the possible partition numbers, regardless of whether the partitions actually exist. (Trying to open the device file for a nonexistent partition will fail, of course.)

It's possible to forego partitioning and put a filesystem directly on a disk. When you mount a block device, the filesystem driver typically looks for a superblock at a predetermined offset from the beginning of the device, and since the beginning of a partition is not the beginning of the disk itself, the superblock for a filesystem in a partition is located at a different place on the disk than the superblock for a filesystem created on the "whole-disk" device.

So if the disk used to just have a filesystem, and then it was partitioned and a filesystem was created in a partition, the old superblock might still be there, e.g. in the small gap before the beginning of the first partition. So the disk still appears to have a filesystem on both the raw disk device and on the partition device, because whichever one you try to mount, when the filesystem driver goes looking for the superblock it'll find one.

It's not actually safe to mount and use both filesystems, though, since they overlap on the disk. One may have important bookkeeping data in what the other thinks is free space. That's why it's a good idea to zero the beginning of a block device, to remove any unwanted superblocks, when you want to change a raw disk to a partitioned one, or vice versa, or change the type of filesystem used on a partition, etc.


As far as I know, when the kernel detects a new block device on a scsi-like (incl. sata) bus, in addition to adding a node in /dev for the whole disk itself, e.g. /dev/sda it will attempt to see if there's a partition table. If there are readable partitions, it will then create the partition nodes numbered depending on whether they're physical or logical partitions (I believe logical partitions start at #5).

If you see a disk node but with no partition nodes, this would mean that there haven't been any partitions detected. I'm not aware of any instance where you can mount the physical device, as that would imply that there's a filesystem directly written to the physical device without any partition table. It could be that in the event where there's only a single paritition, mount will interpret a mount /dev/sda command as meaning /dev/sda1, but I've never tested this.

  • 2
    You can have a filesystem directly on the disk itself, without a partition table. (A removable device configured that way is sometimes referred to as a "superfloppy", since floppy disks typically weren't partitioned.)
    – Wyzard
    Commented Dec 8, 2011 at 13:07
  • Excellent point. I had a dim memory of sticking a usb drive in a laptop and being able to mount /dev/sdc but wasn't sure if I was making that up.
    – growse
    Commented Dec 8, 2011 at 13:10

/dev/sda - raw device

/dev/sda1 - 'virtual' device, like a partition.

One interesting difference is that if a device has partitions (has MBR data or sth alike) you can't read MBR data from any of the virtual devices, as MBR data resides outside of any partitions on a device. MBR resides in the first sector of the device (CHS: 0 0 1). There is a good practice to create the first partition at 1MiB after the beginning of a device.

To read the MBR data, you have to use the raw device (/dev/sda), i.e.:

dd if=/dev/sda of=mbr.bin bs=512 count=1

Ah, partition tables and device names. Get ready to get confused with them.

Have a HP server with their Compaq RAID controller? No /dev/sda, say hello to /dev/ccsis.

Have an old desktop computer with old IDE interface? No /dev/sda, say hello to /dev/hda.

Have a modern server which says you /dev/sda but after installation you hardly can see it? Say hello to LVM, your OS installation has made your /dev/sda as LVM physical volume, created a volume group inside it, and a logical volume inside that.

So ... if you don't see anything like /dev/sda1, you might have LVM or similar in use, which has created its own "partititions".

Did this answer your question?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .