filesystems and mbr

dumaisp · Post by **dumaisp** » Sat Mar 22, 2008 2:12 pm

Hi,

Can anyone tell if there is a MBR on all storage media? I know that I will find one on a hard drive, but is there one on a usb key? on a cd rom? etc..

The reason I am asking is because I need to know if the partition number should be transparent to a filesystem driver or not. I was thinking about implementing two layers for storage devices: device abstraction layer (which is basicaly just an API for reading/writing blocks on a device) and a filesystem layer. But I am now wondering where the partition information should be handled. If the device has no MBR (just a partition starting at the first byte on the media), then I can assume there is a MBR. And if there are several partitions, maybe I could find some other structure than a MBR

Can anyone give me a hint on that?

thanks.

lukem95 · Post by **lukem95** » Sat Mar 22, 2008 4:18 pm

yes, USB's and CD's etc can have MBR's. Its as dependant on the FS as the storage device though

xyzzy · Post by **xyzzy** » Sun Mar 23, 2008 1:25 am

lukem95 wrote:yes, USB's and CD's etc can have MBR's. Its as dependant on the FS as the storage device though

USB devices certainly can have, but I don't think CDs can ever have one. Also, not all systems use an MBR, for example EFI-based systems such as Intel Macs use GPT.

bewing · Post by **bewing** » Sun Mar 23, 2008 1:43 am

An MBR has two parts -- boot code, and a partition table.

The boot code is only useful if the BIOS actually will look at it. And the BIOS will only look at particular specific devices for boot code.

I think I agree with AlexExtreme about CDs. A CD uses a ISO9660 or UDF filesystem, and I don't think either one can support an MBR-style partition table. A partition table on a CD would have a different format.

I'm not sure what filesystem a USB flash drive uses (UDF also?) -- as said before, support of an actual MBR partition table is filesystem specific.

xyzzy · Post by **xyzzy** » Sun Mar 23, 2008 2:00 am

bewing wrote:I'm not sure what filesystem a USB flash drive uses (UDF also?) -- as said before, support of an actual MBR partition table is filesystem specific.

Depends on the device. For example, most USB sticks have an MBR partition table on (at least, every one I've ever come across does), but other USB storage devices may not.

Brynet-Inc · Post by **Brynet-Inc** » Sun Mar 23, 2008 8:06 am

bewing wrote:I'm not sure what filesystem a USB flash drive uses (UDF also?) -- as said before, support of an actual MBR partition table is filesystem specific.

They can use anything you write to them, I use FFS/UFS on mine.. and a MBR exists.

Typically, they use FAT32 though... not UDF.

lukem95 · Post by **lukem95** » Sun Mar 23, 2008 8:36 am

oops, my bad about the CD thing. Sorry for the bad information (shuts head in door)

Ready4Dis · Post by **Ready4Dis** » Mon Mar 24, 2008 2:57 am

Well, this is how it's done in my OS for now. I have my block device handler in my kernel (basically, a list of block devices with call-back functions to read/write a sector). Each block devices stores the size of a block, Number of blocks, a pointer to read/write, and it's relative offset on the disk (aka, partition start), and index/id for the device (for example, my ATA driver can register more than 1 device, so it sets a unique ID for each so it knows which IDE controller/IO port to use when accessing the device).

My Disk drive has a read/write function, that is passed the block device header when reading. It takes the sector passed to read, adds the start block stored in the structure, and reads the the block into the pointer that it was passed.

When my disk driver registers a device, I have a function in my Block Dev handler in my kernel that checks for a valid partition table, if it's found, it splits itself into however many partitions are found. Basically, the original is copied to the new ones, then the starting block and size are modified to match the partition table. So, this way, each driver doesn't need to know about what a partition is, it's just responsible for reading/writing where you ask it, based on the starting offset in the structure and the offset passed in to the read/write function. I can, for example, put a partition on a floppy disk and it would handle it properly, irregardless of the device or file system it will work, as long as my partition checking code see's it as valid (which I am sure needs some modifications to work with a wider selection, but i will add more to it as i start checking more and more device types). I contemplated making the driver do it's own checks, but then I decided it'd be easier to write a single function to do it, than repeat the same code many times in drivers, because I want to support a USB device whether it has an MBR or just a filesystem, same with a hard disk, my OS does not require a partitioned drive, but can use a partitioned drive on any device (even ones not normally partitioned, like the afformentioned partitioned floppy).