21 replies to this topic

[Olof Lagerkvist]

There are plans for a 1.6.0 release very soon. Something like a "release candidate" is available here:
http://www.ltr-data....kinst_1.6.0.exe

• Geometry emulation - switched to using volume boot sector values, when such values exist.
• LBA -> CHS calculation errors fixed.
  Cylinder was not correctly calculated and bits 9 and 10 of cylinder were not placed correctly in MBR partition entry.

These two changes primarily come from discussion in this thread: http://reboot.pro/16516/

When a disk image file is mounted, the boot parameter block is now read from the volume boot record. If geometry values are found there, they are reported as disk geometry to Windows. This causes disk geometry queries made by applications and other drivers to report the same geometry values as were found originally in the VBR when image file was mounted. This also causes reformatting of the volume to not overwrite this geometry with other geometry values and similar.

The change can be seen with my devioctl tool (latest versions). "Disk CHS geometry" and "LBA length" are values reported by Windows. They of course depend on what the disk driver, in this case ImDisk, has originally reported when the disk device was created. "Partition information" is what Windows thinks about the "partition", also depends on what ImDisk reports. "Volume boot record values" are values read from BIOS parameter block in volume boot record.

Before this change:

C:>devioctl geometry E:

Disk CHS geometry:

Media type : 12

Cylinders	 : 83

Tracks per cyl: 32

Sectors per tr: 63

Bytes per sect: 512

Total CHS size: 85671936 (81.7 MB)



LBA length : 86030336 (82.04 MB)



Partition information:

Start offset : 32256

Partition size: 86030336 (82.04 MB)

Hidden sectors: 1

Partition no : 1

Partition type: 0x06

Boot indicator: 0

Recognized par: 0



Volume boot record values:

OEM name	 : NTFS

Bytes per sect: 512

Sectors per cl: 1

Reserved sect : 0

FAT count	 : 0

FAT root entr : 0

Total sectors : 0

Media descript: 0xF8

Sectors pr FAT: 0

Sect per track: 17

Number of head: 15

Physicl drv no: 0



E:: The operation completed successfully.

After this change:

C:>devioctl geometry E:

Disk CHS geometry:

Media type : 12

Cylinders	 : 658

Tracks per cyl: 15

Sectors per tr: 17

Bytes per sect: 512

Total CHS size: 85908480 (81.93 MB)



LBA length : 86030336 (82.04 MB)



Partition information:

Start offset : 8704

Partition size: 86030336 (82.04 MB)

Hidden sectors: 1

Partition no : 1

Partition type: 0x06

Boot indicator: 0

Recognized par: 0



Volume boot record values:

OEM name	 : NTFS

Bytes per sect: 512

Sectors per cl: 1

Reserved sect : 0

FAT count	 : 0

FAT root entr : 0

Total sectors : 0

Media descript: 0xF8

Sectors pr FAT: 0

Sect per track: 17

Number of head: 15

Physicl drv no: 0



E:: The operation completed successfully.

So, this makes the BPB and Windows "running values" agree. This also means that the function that saves a volume as an image file prefixed with an MBR, can use the same way to identify disk geometry for both ImDisk volumes and physical disk volumes (and volumes created by other virtual disk drivers).

Now, this seems to work correctly for filesystems with a BPB in the volume boot record and as long as the values there are "sane". This is usually the case for FAT12, FAT16, FAT32, NTFS, HPFS. It does not work at all with exFAT, HFS+ etc as far as I can see. There is something like BPB values in EXT2/EXT3 and UFS boot records, but I cannot really understand what their values come from. For example, I have a 10,000 MB VHD file with C/H/S geometry 20317/16/63 where FreeBSD is installed. In the volume boot record of the boot partition, FreeBSD has Sectors/Head = 18 and Number of Heads = 2...

There is also of course the possibility that ImDisk will mistakenly treat something as a BPB geometry that is not meant to be something like that, just happens to be stored at the same location in a filesystem format that uses that byte position for something else. For now, it just checks that the bytes per sector is a power of two and that heads and cylinders are not unreasonably high.

Anyway. This should not be worse than it was before. The only problem is that if, for example, a FAT32 volume is mounted with geometry from BPB and the volume is reformatted as exFAT, the geometry values will not "survive" a dismount/remount. Because the next time the volume is mounted there are no BPB geometry values for ImDisk to read, since exFAT has no BPB. If that image is then saved as an image file with MBR prefix, it will be placed in a very different place in the image than it was possibly originally loaded from.

Further changes in this release:

• Partition auto-detection works with partition entries that start at LBA=0.
  Previously, such entries were treated as "not used" and simply skipped. Corresponding change has also been made to devio (with variants). There were a discussion about this bug here: http://reboot.pro/17715/
• Support for sparse image files.
  A new command line option -o sparse causes ImDisk to create a sparse image file. This effectively sets sparse flag using FSCTL_SET_SPARSE, it causes image file size not to be increased to virtual disk automatically and it causes the image write routines to call FSCTL_SET_ZERO_DATA when an all-zero block is written to image.
• ExAllocatePoolWithTag instead of ExAllocatePool.
  This means that poolmon.exe and other kernel memory monitoring, verifying and leak detecting tools that work on running drivers will work more like expected with ImDisk. Pool tag for imdisk.sys is now "ImDi" and for Awealloc it has been changed to "AWEA". The 64 bit versions now free pool memory using ExFreePoolWithTag instead of ExFreePool. This causes a BAD_POOL_CALLER blue screen in case something goes entirely wrong and the driver tries to free the wrong memory block. The 32 bit version is still left without this check, to be compatible with NT 4.0 and earlier.

That's all for now. Please feel free to try this "release candidate" and post your thoughts, ideas and opinion!
http://www.ltr-data....kinst_1.6.0.exe

[Wonko the Sane]

Olof, JFYI, exFAT has by design a blank BPB.
See:
http://www.sans.org/...le-system_33274
(from page 22 onwards)

The next field, Must Be Zero, defines 53 bytes of 0x00 in a location that the older FAT file systems used to define their BPB. This reduces the risk of the legacy FAT implementations of accidently mounting an exFAT volume by mistake.

There is not anymore HS data in the VBR, only LBA data at offsets 64 and 72.

Ext2/3 have a completely OPTIONAL initial 1024 bytes (two sectors) space for boot structures.
Syslinux and grub4dos - as an example - fill the first sector with needed BPB values (on partitioned media, by getting them from the parititon table or defaulting to 255/63) but grub4dos' bootlace.com - when used to install the loader to a Ext2/3 filesystem "floppy" or "super-floppy" device needs to have manually the data, from README_GRUB4DOS.TXT

Note 3: If DEVICE_OR_FILE is a floppy device or a floppy image file, and it
was formated EXT2/EXT3, then you should specify --sectors-per-track and
--heads explicitly.

This "feature" of Ext2/3 caused in the past (before the fix) a quite peculiar issue (still JFYI):
http://www.mail-arch...g/msg07306.html
(since first two sectors were not touched, a reformatted as EXT2/3 filesystem - which was previously FAT formatted - was incorrectly re-identified as FAT)


Wonko

[Sha0]

I look forward to using this version, since ImDisk is (and devio and devioctl are) great!

[saddlejib]

Can you chage "unmount" to "dismount" former word does'nt exist. Sorry for being pedantic, Yes, I know its not you're native language, hope somebody helps me the same someday.

[Olof Lagerkvist]

Can you chage "unmount" to "dismount" former word does'nt exist.

I have, numerous times, corrected people who do not have Swedish as their first language, when they say something in Swedish that I spontaneously feel must be some kind of mistake. I just assume that what I just heard cannot reasonably be correct Swedish. Until someone hit me with a dictionary showing me that the language I have spoken for as long as I can remember, was a little more complex and complicated than I spontaneously thought.
http://en.wiktionary.org/wiki/unmount

You have not used Linux or other Unix-like operating systems a lot, have you?
http://unixhelp.ed.a...an-cgi?umount 8

Sorry for being pedantic, Yes, I know its not you're native language, hope somebody helps me the same someday.

Being a little more serious, I agree that dismount would have been a more appropriate term. Microsoft use "dismount" rather than "unmount" throughout their documentation and naming conventions. But many pieces of ImDisk, especially basic concepts of it, originate in the world of *nix, where "unmount" has been a frequently used term since at least the 1970's. So, I just happened to use "unmount" instead of "dismount" in ImDisk as well. I am truly sorry for that, for many reasons. I know that "unmount" is rarely used in "real life", especially in spoken English, especially outside the *nix world. I also know that just because it is used in everything from 1970's Unix systems up to throughout modern Linux distros, that does not make it a correct English word. But anyway, that is the reason why I happened to use "unmount" instead of "dismount".

...and yes. I will, definitely, change all "unmounts". Also, ideally, something like "detach" would probably be even more appropriate. Or something like that. "Dismount" or "unmount" are usually terms for detaching the filesystem driver from the disk device, not for removing a disk device in a disk device driver or detaching a disk device from parent device stack. Both dismounting the filesystem and removing the disk device (usually) happen when you remove an ImDisk drive. So, there is a chance that I change to "detach" instead. We could probably use something like "delete" or "remove", but there is a risk that people assume that such a command would remove all their data as well, not just the virtual disk device.

Just out of curiosity, and just an example I came to think of:
Microsoft have, for some unknown reason, translated "Unload Hive" in registry editor with "Ta bort struktur" in Swedish versions of Windows. Literally that means "remove/delete structure/hierarchy" or something like that. Which of course means a risk that users think of something entirely different than just detaching a registry database file. Bad translations can make things look just awkward, absurd and unnecessarily risky.

Anyway, thank you for pointing this out. I appreciate all feedback, even linguistic feedback!

[Wonko the Sane]

Actually most of MS literature is written in American English, so I wouldn't take it as a valid source.

Besides the usual color/colour and similar, there are far worse issues with it.

Remember that the good guys had to "invent" the "mickey" (completely missing the correct dimensional check):
http://www.msfn.org/...post__p__999823
and redefined the conversion of inches in metric measures:
http://support.micro...kb/189826/en-us
more:
http://reboot.pro/3541/

Unfortunately for saddlejb unmount is recorded in the Collins Dictionary:
http://www.collinsdi...english/unmount
so, specifically, this point is overruled

For the record there are historically similar perplexities with "uncompress" vs. "inflate" vs. "extract" vs. "expand" as opposite of "compress" and with "unencrypted" instead of "decrypted" as opposite of "encrypted".


Wonko

[Sha0]

Anyway, thank you for pointing this out. I appreciate all feedback, even linguistic feedback!

I agree that "detach" makes the most sense.

A small request: Please continue to be careful about whose advice you heed, regarding the English language.

[saddlejib]

I stand corrected and thanks for your input and additional thanks for Imdisk an exceptional program.

[Bad_Machine]

Olof, thank you for the new version and for all the time you put into this program. I was wondering how feasible would it be to code some options into it. Things like:

• Reclaiming the memory after a user deletes files/folders from the RAMdisk. At the moment RAM is not freed back into the system pool after deletions, this would be a great option to add.
• A RAMdisk to be natively intitialized on every reboot.
• An option that would allow users to enable/disable the creation of a TEMP folder (or even define their own custom folder structures) to be automatically created upon RAMdisk initialization.

Those three are the options that I would like to see the most. Of course there is more:

• Automatic formatting of the RAMdisk upon initialization (rather than having the Windows format prompt coming up after creation).
• An option where the user can enable or disable NTFS compression and indexing, before RAMdisk initialization. The program would then create the RAMdisk, format it as NTFS, and enable or disable NTFS indexing/compression automatically.

BTW I enjoyed the uber-geeky linguistics exchange! Thanks guys

[Wonko the Sane]

I would have thought that command line parameters (and batches/AutoIt/*any* scripting language) already allow for most of what you are asking for (exception made for the "release" of RAM)

As I see it (and I am possibly very wrong) the Control Panel applet is a (nice, useful) tool to get an easy GUI access to SOME of the IMDISK features, but the thingy remains essentially a command line tool.
JFYI:
http://reboot.pro/15593/
(last FAQ/FGA)

You are actually cited for having created a guide on how to create a ramdisk at boot :
http://thessdreview....ftware/1834.htm
Are you "negating" what you actually wrote and assembled in the guide?

Still FYI, the "traditional" ways on PE is/was to have a small pre-made image and extend it (as opposed to create and format):
http://www.911cd.net...showtopic=19711

@Olof
As a low-low-low priority thing, could you actually give numbers to the FAQ's here:
http://reboot.pro/15593/
(so that they can be referred to more easily, most probably all that is needed )
I took the liberty of quoting your FAQ list, modifying it's BBCODE so that it has numbers:
http://reboot.pro/15..._25#entry162834
as soon as you have time to update your original post, I'll delete my post with the Quote)


Wonko

[Olof Lagerkvist]

@Olof
As a low-low-low priority thing, could you actually give numbers to the FAQ's here:
http://reboot.pro/15593/
(so that they can be referred to more easily, most probably all that is needed )
I took the liberty of quoting your FAQ list, modifying it's BBCODE so that it has numbers:
http://reboot.pro/15..._25#entry162834
as soon as you have time to update your original post, I'll delete my post with the Quote)

Thanks! Good idea. I have changed to numbered list now. I also updated a few things that needed update, for example the /mount switch to DiscUtilsDevio.

[Bad_Machine]

I would have thought that command line parameters (and batches/AutoIt/*any* scripting language) already allow for most of what you are asking for (exception made for the "release" of RAM)

As I see it (and I am possibly very wrong) the Control Panel applet is a (nice, useful) tool to get an easy GUI access to SOME of the IMDISK features, but the thingy remains essentially a command line tool.
JFYI:
http://reboot.pro/15593/
(last FAQ/FGA)

You are actually cited for having created a guide on how to create a ramdisk at boot :
http://thessdreview....ftware/1834.htm
Are you "negating" what you actually wrote and assembled in the guide?

Still FYI, the "traditional" ways on PE is/was to have a small pre-made image and extend it (as opposed to create and format):
http://www.911cd.net...showtopic=19711

Hi Wonko. No, I'm not negating my guide, it works anyway. I just wanted to outline features that could make ImDisk become more accesible to a large number of users, people who may not be so comfortable with the creation of scheduled tasks, command line arguments, and batch files. I see this as a natural evolution of the software from a command line tool into something more accesible, something that can possibly even become wizard-driven. This will enable even more users to easily set it up and make use of it.

BTW: Dynamic memory management is something that is feasible, as Romex has demonstarted with Primo. I would love to see the wealth of options that a commercial software like Primo offers, all built into a freeware ImDisk.

There aren't many decent RAMdisk software out there. An easy to use wizard-driven ImDisk could become a top choice among RAMdisk users. Just my opinion for what its worth.

Edited by Bad_Machine, 07 November 2012 - 01:48 PM.

[Sha0]

Olof, thank you for the new version and for all the time you put into this program. I was wondering how feasible would it be to code some options into it. Things like:

• Reclaiming the memory after a user deletes files/folders from the RAMdisk. At the moment RAM is not freed back into the system pool after deletions, this would be a great option to add.

Obviously I have nothing to do with ImDisk, but I think you are confusing the block layer with the filesystem layer. For example, you can invent your own, new filesystem today and format an ImDisk RAM disk with it. How would ImDisk know which blocks to reclaim, if only your filesystem knows which blocks it uses? "Deletion" might not even be a valid concept for some filesystems, such as ISO9660.

• An option that would allow users to enable/disable the creation of a TEMP folder (or even define their own custom folder structures) to be automatically created upon RAMdisk initialization.

Those three are the options that I would like to see the most. Of course there is more:

• Automatic formatting of the RAMdisk upon initialization (rather than having the Windows format prompt coming up after creation).
• An option where the user can enable or disable NTFS compression and indexing, before RAMdisk initialization. The program would then create the RAMdisk, format it as NTFS, and enable or disable NTFS indexing/compression automatically.

All of that seems more appropriate for batch files, in my opinion. Imagine that there are 20 filesystems in the world. Then Olof has to write (essentially) batch files into ImDisk for all 20 filesystems: Their different format commands, their different folder-creation commands, etc. My $0.02.

[Bad_Machine]

Obviously I have nothing to do with ImDisk, but I think you are confusing the block layer with the filesystem layer. For example, you can invent your own, new filesystem today and format an ImDisk RAM disk with it. How would ImDisk know which blocks to reclaim, if only your filesystem knows which blocks it uses? "Deletion" might not even be a valid concept for some filesystems, such as ISO9660.


All of that seems more appropriate for batch files, in my opinion. Imagine that there are 20 filesystems in the world. Then Olof has to write (essentially) batch files into ImDisk for all 20 filesystems: Their different format commands, their different folder-creation commands, etc. My $0.02.

Thank you for your comments. It is obvious that you are approaching this from an expert user's perspective, and that was the exact point I was trying to make. ImDisk doesn't have to remain within the domain of the power user. Ultimately it is down to Olof to decide whether "mainsteaming" is a direction that is appropriate for his program or not.

Regarding your file systems comment: Most Windows users use FAT32 NTFS, and exFAT. Add plain old FAT to the list and it should cover the needs of most users. These four would do, there's really no need for Olof to create wizards for every single possible file system out there.

Edited by Bad_Machine, 07 November 2012 - 03:24 PM.

[Wonko the Sane]

Regarding your file systems comment: Most Windows users use FAT32 NTFS, and exFAT. Add plain old FAT to the list and it should cover the needs of most users. These four would do, there's really no need for Olof to create wizards for every single possible file system out there.

So, my Solaris, Plan 9 volumes and BSD slices won't be supported?
Bad, bad Olof!

Come on , if you are going with the demographic/popularity approach the intended use/feature you proposed is actually desired/needed ONLY by "advanced users", and actually by a very limited minority of them.




Wonko

[Bad_Machine]

So, my Solaris, Plan 9 volumes and BSD slices won't be supported?
Bad, bad Olof!

Come on , if you are going with the demographic/popularity approach the intended use/feature you proposed is actually desired/needed ONLY by "advanced users", and actually by a very limited minority of them.




Wonko

Such support would still be there as it currently is, it would still be available but without the need for a wizard. What I am talking about is the inclusion of a plain wizard which would enable vanilla users to easily set up the program according to their needs and with a few clicks. NTFS/FAT/FAT32/exFAT options for such a wizard would be more than enough for the needs of such users.

Is ease of use such a a bad thing? Would it be so bad to create a more 'inclusive' version which could automate the creation of a RAMdisk at every startup with just with a few clicks? I don't think it is such a bad idea. Such a wizard-driven interface would certainly cater for the less technically adept among us. For the more adept rest there will always be the command line to play with. Just my opinion for what its worth.

Anyway, I never meant for this to go into a full-blown debate. I love this software and I plan to include it in a high-profile RAMdisk showdown which I will publish within a very well known technology website in the near future. I have already thoroughly tested every single RAMdisk software available for Windows and ImDisk is certainly one of the best. It just needs to be more 'approachable' where the average users are concerned. Sometimes it is very easy for power users to forget where we have all started from...

Edited by Bad_Machine, 07 November 2012 - 04:27 PM.

[Olof Lagerkvist]

Such support would still be there as it currently is, it would still be available but without the need for a wizard. What I am talking about is the inclusion of a plain wizard which would enable vanilla users to easily set up the program according to their needs and with a few clicks. NTFS/FAT/FAT32/exFAT options for such a wizard would be more than enough for the needs of such users.

Is ease of use such a a bad thing? Would it be so bad to create a more 'inclusive' version which could automate the creation of a RAMdisk at every startup with just with a few clicks? I don't think it is such a bad idea. Such a wizard-driven interface would certainly cater for the less technically adept among us. For the more adept rest there will always be the command line to play with. Just my opinion for what its worth.

Anyway, I never meant for this to go into a full-blown debate. I love this software and I plan to include it in a high-profile RAMdisk showdown which I will publish within a very well known technology website in the near future. I have already thoroughly tested every single RAMdisk software available for Windows and ImDisk is certainly one of the best. It just needs to be more 'approachable' where the average users are concerned. Sometimes it is very easy for power users to forget where we have all started from...

While I principally agree with you, I just feel I need to clarify my own view regarding this. I think that for an open source project like ImDisk, anyone can contribute with ideas, solutions, add-ons, additional interfaces, scripts or whatever they want to share. I, personally, give most attention to the kernel mode driver, the proxy logic and various kinds of API accessible to other developers. I think that this is where my time and effort makes itself most useful. I am not much of a GUI programmer. My goal is instead to provide an API that GUI programmers can use to write their own interfaces, wizards, scripts or whatever, to make things more "user accessible".

So, there is nothing bad with ease of use and I have not forgotten other than "power users", I just cannot really imagine myself taking ImDisk into the direction of wizards and full-feature GUI. There are lots of other people who can do that a lot better than me.

[Wonko the Sane]

Is ease of use such a a bad thing? Would it be so bad to create a more 'inclusive' version which could automate the creation of a RAMdisk at every startup with just with a few clicks? I don't think it is such a bad idea. Such a wizard-driven interface would certainly cater for the less technically adept among us. For the more adept rest there will always be the command line to play with. Just my opinion for what its worth.

Not at all.
See what someone did (a lot of time ago) in a very similar case :
http://jaclaz.alterv...ts/VDM/vdm.html

The topic is IMHO a tidy bit different, more about who should do what and where it should be done, you seem like proposing that the who should be Olof and the where should be the IMDISK Control Panel applet, I am saying that the who could be anyone BUT Olof (which can use his time - with advanced skills - for something more useful to the community) AND expecially that the where should NOT be the IMDISK Control Panel applet.
The risk - as I see it - is that the interface will be clogged by a number of options that will make use much more complex than needed.
This is IMHO a common issue with what I call "featuritis", the obsessive drive that affects many developers to add features to their app until it's use becomes either awkward or very complex (and since the documentation - where existing - is usually a few or several versions behind) or even downright unusable (which multiplies the requests for assistance, etc.)
This is why I was suggesting an external *something*, like batch, autout, etc., let's call it IMDISK Advanced Configurator .

Anyway, I never meant for this to go into a full-blown debate. I love this software and I plan to include it in a high-profile RAMdisk showdown which I will publish within a very well known technology website in the near future. I have already thoroughly tested every single RAMdisk software available for Windows and ImDisk is certainly one of the best. It just needs to be more 'approachable' where the average users are concerned. Sometimes it is very easy for power users to forget where we have all started from...

BUT unless there is a "debate" (actually an exchange of ideas/opinions) it is more difficult that the good (or bad) ideas will arrive to the Author and to the Community more in general.


Wonko

P.S.: overlapping posts with Olof, however it seems like he is on the same wave lenght as I am

[Bad_Machine]

Olof, Wonko, thank you for your detailed input to my suggestions guys! BTW, I never meant to direct an accusation towards any of you regarding my "we were all novices once" comment. It was just a general comment that I frequently find true: There are many experts out there who have no patience when it comes to people with much lesser knowledge than themselves. It is often easy to look at things from a power user's perspective and forget that what looks like a shallow pond for some of us will seem like the deepest ocean for many others (please excuse my poor attempt at a metaphor).

Olof, I understand that your time is limited, and as you said ImDisk is open sourse. I was hoping that you'd have some time to program something like this, but since you don't then I can only hope that a decent gui coder may take up the challenge of creating a nice little frontend for the program.

Edited by Bad_Machine, 07 November 2012 - 07:37 PM.

[Sha0]

Thank you for your comments.

You're welcome.

It is obvious that you are approaching this from an expert user's perspective, and that was the exact point I was trying to make. ImDisk doesn't have to remain within the domain of the power user.

Reading this and the rest of the thread up until this point, I now believe that I misunderstood your suggestion. I honestly thought you were suggesting that the features I suggested belong in batch files should be incorporated directly into ImDisk.exe and perhaps the driver. If, instead, you were discussing the control panel applet or any other external program, then that seems fair, modulo any hindrance that might come to "expert users" (more mouse clicks, for example).

Ultimately it is down to Olof to decide whether "mainsteaming" is a direction that is appropriate for his program or not.

And clearly.

Regarding your file systems comment: Most Windows users use FAT32 NTFS, and exFAT. Add plain old FAT to the list and it should cover the needs of most users. These four would do, there's really no need for Olof to create wizards for every single possible file system out there.

With the block versus filesystem response, I actually meant to draw your attention to the real difficulty (I perceive) with your first feature request:

• How do you know when a file has been deleted?
• How do you know what blocks the file was using, to reclaim them?
• Would this mean that the virtual disk is not one contiguous memory allocation, but instead needs to be accessed as multiple allocations, so that some pieces can be reclaimed?
  
  • I don't know if Olof uses multiple allocations already, but if not, that'd be a bit of a chore to code, and it impacts performance because you introduce a level of indirection; first the map of allocations, then the virtual disk data.
  • It also means that you can wind up with "bad sectors" for the virtual disk if you run out of memory, as it won't be able to grow!
• Assuming the filesystems you mentioned were to be supported, how do you determine the granularity of the virtual disk chunk size?
  
  • In NTFS, a file can be resident in the MFT record. If you were to delete such a file and wished to reclaim the memory, you'd be reclaiming a piece of the MFT record, which is really a rather awkward granularity.

This kind of confusion about disk (or block) versus filesystem seems pretty common. But what you really want, I think, is more akin to Linux' ramfs and tmpfs. These are filesystems that don't even involve a disk or block device (other than a swap-file, for the latter). That means that your file creations and deletions consume and free memory, as needed. The performance is going to be far better than a virtual disk, firstly because this type of filesystem is much less complicated than a block device filesystem, and secondly because there are no block device accesses.

If you are curious about this performance difference, I'd recommend creating a .WIM file with no compression (decompression can affect performance), booting the WIM as a Windows PE environment, then testing the speed of file-reads from it. This is the closest Windows has to Linux' rootfs (a ramfs), as far as I know, and it's not all that close due to the WIM format.

But obviously a rootfs for Windows is off-topic for an ImDisk thread.

[Bad_Machine]

Thank you Sha0 for the very detailed response, it has certainly made things clearer. I'm not a Linux expert but I know enough to understand what you are saying from a technical standpoint.

The thing is that Romex has proved that such a feature can be feasible and stable. I have tested all available RAMdisk apps on six different testbeds during the last three months, these are all systems featuring very different hardware configs, and amounts of RAM ranging from 4GB to 32GB. Primo has been 100% stable with all of them, just like ImDisk. Furthermore, Primo's Dynamic Memory management/Compact Mode feature works faultlessly. I am very impressed with it and I would love to see ImDisk emulating such an option if possible. If an open source freeware program like ImDisk can emulate such a feature then I'd most certainly make sure to publicize the fact via the websites I work for.

Please have a look here for a general example on how Primo deals with dynamic memory management (of course Romex are not revealing of how such a feature is being implemented):

http://www.romexsoft...management.html

I just hope that Olof may be able to find a way to code this, and maybe develop a similar way of releasing the RAM back to the system after deletions take place. If the Romex guys have already hacked it then I'm confident that Olof could also figure out a way.

Edited by Bad_Machine, 07 November 2012 - 10:07 PM.

[Olof Lagerkvist]

@Bad_Machine:

What I think the guys at Romex have done, is that they have probably written something to intercept a kind of "zero" message sent by filesystem driver to disk stack. The same kind of message as the one used in ATA port driver to create TRIM messages down to SSD storage controllers.

This could be reasonably easy to implement for a memory emulated disk driver that already has some kind of dynamic allocation and/or block based allocation, where memory is not allocated as one single block. Unfortunately, ImDisk is implemented in the rather opposite way. It allocates all memory needed for a virtual disk a one big block at once, when the virtual disk is created. This makes access easier. For example, to access the virtual disk data, all the driver needs to do is to add the requested offset to base address of allocated memory block. Like Sha0 says, dynamic block allocation adds an abstraction layer in between. There is no such logic in ImDisk today at all, so, to add that would mean quite a lot of code to rewrite.

On the other hand, the way awealloc works, means that we might have something to start with anyway. It allocates everything as one memory block, so the allocation method itself is not useful, but it then maps chunks of that memory block to virtual address space when needed. Therefore, it already has got a way to calculate virtual offsets within a specific chunk of the complete memory block.

This could be worth some investigation. But I don't know how and/or when that could be done.