FILEDISK and RAMDISK
#26
Posted 11 May 2012 - 10:15 AM
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
#27
Posted 11 May 2012 - 10:26 AM
ONLY seemingly OT and just for the interest of Holmes.Sherlock:
I was thinking to myself when bearded uncle will join the party.
#28
Posted 26 October 2012 - 03:57 PM
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.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 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.
#29
Posted 26 October 2012 - 04:47 PM
How can it be done practically by using G4D?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.
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?
#30
Posted 26 October 2012 - 05:08 PM
If I'm not mistaken, you could do:How can it be done practically by using G4D?
map (hd0,3) (hd1) map --hookTo 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.
Sorry, no. Using --mem means the disk is neither a sector-mapped disk nor a file-backed disk; it is a RAM disk.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?
If, instead, you had typed:
map XYZ.iso (0xe0) map --hookI 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.
#31
Posted 26 October 2012 - 05:15 PM
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?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.
#32
Posted 26 October 2012 - 05:22 PM
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.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?
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. )
#33
Posted 26 October 2012 - 05:29 PM
If, instead, you had typed:
map XYZ.iso (0xe0) map --hookI 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?
#34
Posted 26 October 2012 - 06:20 PM
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.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?
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 likes this
#35
Posted 26 October 2012 - 06:24 PM
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.
#36
Posted 26 October 2012 - 06:35 PM
Sure, except that my code contains a mistake. I believe the syntax is actually <offset>+<length> So more likeI 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.
map (hd0)938+2880 (fd0) map --hookSorry about that!
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users