OSDev.org

Just for your information, and since I haven't found much on this subject, I thought I would comment about sector sizes other than 512 bytes.

Those of us that use QEMU may have noticed that a recent update brought the NVMe emulation to version 1.3. With this addition, the NVMe drive now supports sectors sizes that are larger than the default 512-byte sectors.

For example, use similar command line arguments to: This allows you to have 4096-byte sectors.

At this point, you can't really do anything with it, other than recognizing that the media is using a sector size other than 512 bytes. For example, you actually need a file system that supports different sector sizes.

With gratitude toward him, the author of the LEAN file system has allowed me to work with his file system through its revisions, and I have added a few small details to allow this file system to work on media devices with sector sizes other than 512 bytes. With some tests of my code, I was able to mount and use a LEAN file system formatted with 4096-byte sectors. As long as the sector size is equal to or greater than 512 bytes *and* is a power of two, it works just fine.

The additions I added:
- changed the version to 0x0007 (from 0x0006)
- an indicator byte in the Super Block to compare the physical sector size and the formatted sector size to be sure they match before mount time. (0 = 512, 1 = 1024, 2 = 2048, 3 = 4095, etc)
- specifying that an Indirect Block uses all remaining space in the sector for its extents. (ex: with 512-byte sectors, there is room for 38. With 4096-byte sectors, there is room for 336)
- the Super Block's CRC is calculated on the whole sector, not just the super block data. i.e.: Don't assume 512-byte sectors.
- all remaining space after the INODE and before the end of the sector is used no matter the size of the sector. i.e.: Don't assume 512-byte sectors.

The only thing to consider with the new revisions are that as long as you only use 38 extents in the Indirect, a version 0x0006 driver will handle a version 0x0007 partition just fine and visa-versa. i.e.: I have made no change to the file system other than the specification that the Indirect Block can use all remaining space within the sector for extents. This holds true to either version, though with only one exception:
- The extent count member in the Indirect block now must be a WORD sized member rather than a BYTE sized member. With this in mind, if a version 0x0007 ever writes more than 255 extents to this Indirect Block, then a version 0x0006 driver ever reads the count, it will read an incorrect count. Hence the addition to the Super Block to first verify the size of the sector, and of course the version field.

Back to my point, as far as I know, QEMU and the NVMe is the only form of emulation allowing TRUE emulation of 4096-byte sectors. All other forms of emulation require the physically attached media to support this sector size. (Please correct me if I am wrong, and point me to the means of doing this).

Anyway, you now have a way to test your media and file system drivers with sector sizes other than 512 bytes.

There are some things to remember though.
- You can't boot a Legacy system with the media having a sector size other than 512 bytes. However, you can boot something else first. For example, boot FAT32, as one of the media devices, having an additional NVMe device with one or more namespaces.
- The file system must support a sector size other than 512 bytes. FAT? haha. Good luck. It will have to be something built to allow non-standard sizes.

After getting the Lean author's permission, I will post an updated specification.

Also, I have started the 4096-byte sector function of my image utility as well. It currently allows different sized sectors, though I only tested with a simple LEAN FS partition. It is still experimental.

Thanks,
Ben
- http://www.fysnet.net/osdesign_book_series.htm

BenLunt wrote: - The file system must support a sector size other than 512 bytes. FAT? haha. Good luck.

No luck needed; all the popular FAT implementations must already support 4096-byte sectors in order to read and write EFI system partitions.

@BenLunt: Good work! I'm sure it'll be useful. I was briefly a little surprised that I'm only seeing it now, but then I remembered ours is a rare hobby, changing sector size is, conceivably, a lot of work for some filesystems, and we're not exactly a unified team pulling towards a common goal. And there's hard-coding. I've been used to the concept of different sector sizes since the 128-byte sectors of Atari disks in the 80s, FAT16 with its "cluster size" kept the concept alive in my mind, and of course Flash media has 4K sectors, but I still hard-coded the block size in a Forth block system I wrote last week. Why? Because the number is easier to type and looks much nicer than "chars/block".

Emulator question, if anyone knows: Does virtio have a sector size concept? If so, does the protocol allow for it to be changed, and could Qemu allow changing it without too much trouble? I thought it might be easier for Qemu devs than changing Qemu's disk emulation. I know virtio rarely comes up around here, we mostly want to develop for 'bare metal', but I've been thinking an OS with only virtio drivers would make sense for VPS nodes. If the node's drive is an SSD, 4K sectors (or at least blocks) would be better than 512-byte.

Octocontrabass wrote:

BenLunt wrote: - The file system must support a sector size other than 512 bytes. FAT? haha. Good luck.

No luck needed; all the popular FAT implementations must already support 4096-byte sectors in order to read and write EFI system partitions.

Hi Octocontrabass,

The file system itself may support 4k sectors, but I would bet that 99.9% of all current (including modern) FAT drivers are hard coded to use 512-byte sectors.

After some more work, one of the things on my list is to format a FAT partition using 4k sectors, then boot via EFI and see if the firmware recognizes it and mounts it okay. I will be more surprised if it works than if it doesn't. But we will see. Hence, the comment about getting FAT to work on 4k sectors.

Thanks,
Ben

eekee wrote:Does virtio have a sector size concept? If so, does the protocol allow for it to be changed,

Yes.

eekee wrote:and could Qemu allow changing it without too much trouble?

It seems like you can specify it as a command-line option, although I haven't tried it myself to see if it would work.

BenLunt wrote:The file system itself may support 4k sectors, but I would bet that 99.9% of all current (including modern) FAT drivers are hard coded to use 512-byte sectors.

Maybe, but I'm talking about the popular ones, which are mostly just Windows and Linux. Both work just fine reading, writing, and booting from an EFI system partition with 4096 bytes per sector. How often do you use a different FAT driver?

Octocontrabass wrote:

BenLunt wrote:The file system itself may support 4k sectors, but I would bet that 99.9% of all current (including modern) FAT drivers are hard coded to use 512-byte sectors.

Maybe, but I'm talking about the popular ones, which are mostly just Windows and Linux. Both work just fine reading, writing, and booting from an EFI system partition with 4096 bytes per sector. How often do you use a different FAT driver?

I'll have to take your word for it. I have not ever done any tests or seen Windows or Linux boot and use a 4k sector size with FAT. Have you personally seen it, or have you just seen sources stating so? If the latter, please let me know where it is shown. I'd like to read it.

Thanks again,
Ben

BenLunt wrote:Have you personally seen it, or have you just seen sources stating so?

I have personally seen it with both Windows and Linux, but you can also check Microsoft's documentation for Windows support. (It's not stated explicitly, but booting from a 4kn drive implies support for 4096-byte sectors in the FAT driver.)

Octocontrabass wrote:

eekee wrote:Does virtio have a sector size concept? If so, does the protocol allow for it to be changed,

Yes.

eekee wrote:and could Qemu allow changing it without too much trouble?

It seems like you can specify it as a command-line option, although I haven't tried it myself to see if it would work.

Awesome; thanks!

BenLunt wrote:

Octocontrabass wrote:

BenLunt wrote: - The file system must support a sector size other than 512 bytes. FAT? haha. Good luck.

No luck needed; all the popular FAT implementations must already support 4096-byte sectors in order to read and write EFI system partitions.

Hi Octocontrabass,

The file system itself may support 4k sectors, but I would bet that 99.9% of all current (including modern) FAT drivers are hard coded to use 512-byte sectors.

After some more work, one of the things on my list is to format a FAT partition using 4k sectors, then boot via EFI and see if the firmware recognizes it and mounts it okay. I will be more surprised if it works than if it doesn't. But we will see. Hence, the comment about getting FAT to work on 4k sectors.

Thanks,
Ben

I stand corrected. I formatted an image file--PMBR, GPT, and FAT16--placed enough files on it to boot, and EFI booted it just fine. I am surprised, but at the same time impressed. Glad to see that the assumption of 512-byte sectors might start to be a thing of the past.

Sorry for the error on my part, and thanks for the "encouragement" :-)

Ben

Hi Ben,
Lot of the hard disc shipped these days have 4k sector size. I do not want to get into details,
But can usually manually override sector size with set sector size cmd in sata or by setting format options and doing a format for SAS
I would recommend that you perform a full write of the disc if you did change the sector size.

--Thomas

Thomas wrote:Hi Ben,
Lot of the hard disc shipped these days have 4k sector size. I do not want to get into details,
But can usually manually override sector size with set sector size cmd in sata or by setting format options and doing a format for SAS
I would recommend that you perform a full write of the disc if you did change the sector size.

--Thomas

You're absolutely correct. However, my biggest concern and the reason for my post was not the disk itself, but the software/firmware that would run on it. I have known about 4k disks for some time now.

Anyway, as far as I know all Legacy firmware will only allow and recognize a disk that has 512-byte (logical) sector sizes. I was surprised that UEFI firmware supported FAT on 4k sector sizes, but now am not surprised at all.

My main reason for the post was to see if our hobby project(s) would work on 4k sector sizes, especially our file systems. I had never even thought that FAT would work on 4k sectors, but after this thread and some research, found out that FAT works just fine on 4k sectors.

Shows that the more you learn, the more you learn you don't know everything there is to know. Especially in my case. I have been doing this stuff for nearly 30 years and still learn stuff every day.

Thanks,
Ben

I'm glad to see this. I can't wait for the new specification for LeanFS; I've wanted to implement it for a while but am sorting out some other things with my kernel at the moment.
Hate to drag this OT, but I would love some advice about disks, and since we're talking about disks... :3
I'm trying to work on a common interface for all disk drivers. Currently my interface requires a driver to implement the flush, read, write, and identify operations. What else should I require and what should I make optional? (Again, sorry for the drag to OT, but I thought I'd ask.)

Hi,

Ethin wrote:I'm glad to see this. I can't wait for the new specification for LeanFS; I've wanted to implement it for a while but am sorting out some other things with my kernel at the moment.

I am currently in communication with the author and I think we have narrowed the details down to one modification, two clarifying additions, and a possible fourth new addition.

Ethin wrote:Hate to drag this OT, but I would love some advice about disks, and since we're talking about disks... :3
I'm trying to work on a common interface for all disk drivers. Currently my interface requires a driver to implement the flush, read, write, and identify operations. What else should I require and what should I make optional? (Again, sorry for the drag to OT, but I thought I'd ask.)

Are you talking about the actual driver that reads and writes to the media? Not the driver that reads the file system, correct?

One other item you should implement is disk change status. On optical drives, USB drives, and old floppies, you need to be able to tell if the disk is still available. In fact, all of my functions call another function to verify that the media is present and ready for access.

Does this help?
Ben

Yes, just the driver. And as for verifying that the media is available, I'm primarily planning to just support NVMe disks for now -- I'll work on XHCI much later. Right now I just want to be able to read a file system. I used to be able to -- I had an ATA driver -- but the way I'd implemented it was horrible, and though I've tried AHCI, I find AHCI over-complicated. NVMe, for me, is much simpler and easier to mentally figure out and comprehend than AHCI