Hello, I've been having problems using vvfat virtual block device. Even linux fdisk was able to find problems with it. The reason turned out to be simple, MBR have bogus parameters.
1. Partition size in sectors is threated as partition end, causing the partition to have the same size as the device, while starting 63 sectors inside it. 2. The disk CHS geometry was set to maximum allowed values, not the maximum sizes of parameters. Cylinders = 1024 -> 0 .. 1023 Heads = 16 -> 0 .. 15 Sectors = 63 -> 1 .. 63 By historical reasons sectors maximum allowed value and size match. I've changed it to correct values. Now disks are at 504MB limit. 3. The size of partition was fixed with pre-calculated value based on the wrong geometry. I've implemented dynamic calculation. 4. The size of partition have been precalculated to fill the maximum geometry. However usually this means that there is incomplete cluster at the end of it. I've implemented proper shrinking of the partition after init_directories(). 5. WinNT clones refuse to mount disk that doesn't have NT-ID. I set it to 'qemu'. :) As a bonus I reworked the rest of init_mbr code, so it can handle disk outside the CHS limits in a way that all modern systems do, using LBA. Because I couldn't find sector->CHS function I wrote one and to simplify its calling I changed the 3 separate bytes for CHS into an array of 3. Also when LBA mode is detected it sets the proper FAT partition types. I haven't touched any of the directory/boot_record/etc code. (I haven't done automatic fat/partition/disk growing, so far it all have to fit into the maximum CHS geometry). I also moved the ":rw:" handling after other option parsing, as some of them change the sector_count that is used to initialize the snapshot device. However in qemu-0.9.0 and qemu-cvs RW mode doesn't work for me, it fails at bdrv_open() in enable_write_target(). I'll try to debug that and if I find solution I would send additional patch. The attached patch is to the current CVS, it should apply to qemu-0.9.0 with `patch -l`, as there have been only whitespace changes. Here is some simple table of the virtual disk, that would help you understand the code changes. ==== MBR - 0 --- partition_start boot - first_sectors_number-1 FAT1 - first_sectors_number FAT2 - first_sectors_number+sectors_per_fat DIR_ROOT - first_sectors_number+2*sectors_per_fat = faked_sectors ...data... partition_end - cluster_count*sectors_per_cluster + faked_sectors = sector_count ==== P.S. Maybe it is good idea to use 80/2/18 CHS for 1.44MB floppy, instead of 80/2/36 CHS for 2.88MB. Linux doesn't seem to autodetect them. The problem is noticed first by Thomas Schwinge in mail to qemu-dev at 28 Mart.
qemu_vvfat_mbr.patch
Description: Binary data
