35 replies to this topic

[Wonko the Sane]

ONLY seemingly OT and just for the interest of Holmes.Sherlock:
http://www.codeproje...iles/FDump.aspx
http://www.codeproje...aw-Disk-Sectors
http://www.wd-3.com/...e/luserland.htm
http://reboot.pro/15086/page__st__25



Wonko

[Holmes.Sherlock]

ONLY seemingly OT and just for the interest of Holmes.Sherlock:

I was thinking to myself when bearded uncle will join the party.

[Sha0]

IF, a SECTOR-mapped filedisk is an EXACT replica of the bits & bytes on the sectors of a hard-disk partition, then what a FILE-backed filedisk is?

For a sector-mapped disk, saying "filedisk" in the quote is a mistake. For a sector-mapped disk, I/O to the virtual disk's sectors are remapped to ranges of sectors on another "backing" disk. The simplest case is where there is a contiguous range of sectors on the backing disk.

For example, you could have a partition and in that partition could be a hard disk image, instead of a filesystem. GRUB4DOS can establish this kind of mapping. As another example, G4D can look at a file in a filesystem, see that it is composed as a contiguous range of sectors, and allow you to establish a mapping to those sectors.

A sector-mapped disk requires a backing disk.

For a file-backed disk, I/O to the virtual disk is redirected to a file. Files can be accessed via local storage, removable storage, or via network filesystems. Files can be fragmented (non-contiguous).

A file-backed disk requires a filesystem or some other means to access the file.

If you were to examine only the content of either of these, you'd get the same result, because obviously the data is supposed to be the virtual disk data. If you examine the organization and accessibility of this data, they're completely different.

[Holmes.Sherlock]

For example, you could have a partition and in that partition could be a hard disk image, instead of a filesystem. GRUB4DOS can establish this kind of mapping.

How can it be done practically by using G4D?

For a file-backed disk, I/O to the virtual disk is redirected to a file. Files can be accessed via local storage, removable storage, or via network filesystems. Files can be fragmented (non-contiguous).

map --mem XYZ.iso (0xff)

Here all the read/write from/to virtual drive numbered 0xFF are redirected to XYZ.iso. So, can it be an example of file-backed filedisk?

[Sha0]

How can it be done practically by using G4D?

If I'm not mistaken, you could do:

map (hd0,3) (hd1)

map --hook

To create a sector-mapped disk with BIOS INT 0x13 drive number 0x81 whose sectors are mapped to the sectors of the fourth partition on physical drive 0x80, as an example.

map --mem XYZ.iso (0xff)

Here all the read/write from/to virtual drive numbered 0xFF are redirected to XYZ.iso. So, can it be an example of file-backed filedisk?

Sorry, no. Using --mem means the disk is neither a sector-mapped disk nor a file-backed disk; it is a RAM disk.

If, instead, you had typed:

map XYZ.iso (0xe0)

map --hook

I would have said: "No, that is not a file-backed disk." This is a misunderstanding about GRUB4DOS. G4D can only produce sector-mapped disks (or RAM disks). That is why XYZ.iso needs to be contiguous; the fact that it's a file is just a co-incidence. What G4D cares about is that it is a contiguous range of sectors that it can use for producing its sector-mapped disk. No file-backed disks are possible with G4D, unlike the "loopback" disks of GRUB2, for instance. The fact that XYZ.iso was originally a file is lost by G4D, and that cannot be found out in the future by any OS.

Using the tricks in the earlier-referenced articles, you can explicitly tell WinVBlock that a particular sector-mapped disk should be "hot-swapped" with a file-backed disk at some time after booting Windows. That is to say, if you used G4D to produce the sector-mapped disc for XYZ.iso, you can tell WinVBlock, "I know you only got a sector-mapped disc from GRUB4DOS, but what I'd like you to do as soon as possible is to switch that virtual disk from being sector-mapped to being file-backed, using file XYZ.iso."

---EDIT--- I misread your code the first time. You used --mem. That means it is neither a sector-mapped nor a file-backed disk (which G4D cannot produce). It is a RAM disk. I've corrected this post to reflect this.

[Holmes.Sherlock]

No file-backed disks are possible with G4D, unlike the "loopback" disks of GRUB2, for instance. The fact that XYZ.iso was originally a file is lost by G4D, and that cannot be found out in the future by any OS.

When we mount a loopback device with "mount -t loop...." or even more commonly, when we use a virtual HDD in a VM, are we using file-backed filedisks?

[Sha0]

When we mount a loopback device with "mount -t loop...." or even more commonly, when we use a virtual HDD in a VM, are we using file-backed filedisks?

Instead of "filedisks," please say "virtual disks." You can have a RAM-backed virtual disk, a sector-mapped virtual disk, a file-backed virtual disk, a Registry-backed virtual disk, a network block device virtual disk, etc.

I think you meant "mount -o loop ..." In Linux, "everything is a file." So yes, losetup and the Linux loopback mechanism produce file-backed block devices (which is a more general notion than "disk"). (Also: Possibly worth noting is that this mechanism might internally create a sector mapping, but that probably just "muddies the waters" for understanding. )

[Holmes.Sherlock]

If, instead, you had typed:

map XYZ.iso (0xe0)

map --hook

I would have said: "No, that is not a file-backed disk." This is a misunderstanding about GRUB4DOS. G4D can only produce sector-mapped disks (or RAM disks). That is why XYZ.iso needs to be contiguous; the fact that it's a file is just a co-incidence.

If this is not an example of file-backed virtual disk but a sector-backed one, then I conclude that G4D is only concerned about the initial sector of the logical file in the filesystem to locate the absolute read/write sectors on the physical disk, the file (.ISO) being a continuous one. Doesn't it mean that G4D should have some command to pass the initial sector as argument to emulate the sector-backed disk as what I can identify this to be only piece of necessary info that G4D needs?

[Sha0]

If this is not an example of file-backed virtual disk but a sector-backed one, then I conclude that G4D is only concerned about the initial sector of the logical file in the filesystem to locate the absolute read/write sectors on the physical disk, the file (.ISO) being a continuous one. Doesn't it mean that G4D should have some command to pass the initial sector as argument to emulate the sector-backed disk as what I can identify this to be only piece of necessary info that G4D needs?

GRUB4DOS' filesystem drivers allow it to determine which sectors a file occupies, and whether or not the file is contiguous. Yes, the number of the first sector is in the map.

Yes, if you knew the sector-number and length of the disk image, that is sufficient. That is why, for example, you can produce a sector-mapped floppy without any filenames, if you know where it is on the backing disk:

map --heads=2 --sectors-per-track=18 (hd0)+938 (fd0)

map --hook

[Holmes.Sherlock]

Yes, if you knew the sector-number and length of the disk image, that is sufficient. That is why, for example, you can produce a sector-mapped floppy without any filenames, if you know where it is on the backing disk:

map --heads=2 --sectors-per-track=18 (hd0)+938 (fd0)

map --hook

I see, I was be-fooled by the presence of the file and was completely unaware of the sector translation taking place under the hood. Thanks for your patience.

[Sha0]

I see, I was be-fooled by the presence of the file and was completely unaware of the sector translation taking place under the hood. Thanks for your patience.

Sure, except that my code contains a mistake. I believe the syntax is actually <offset>+<length> So more like

map (hd0)938+2880 (fd0)

map --hook

Sorry about that!