CrystalDiskMark - how are Linux partitions mapped to Windows drive letters?

I want to use the Windows app "CrystalDiskMark" for testing drives. Before you suggests the alternatives - GNOME Disks, bonnie++ or hdparm - I already know about these. The thing is the output of CrystalDiskMark has kind of become a de facto standard (because Linux desktop share is < 3% and Windows > 61%). I am successfully running CrystalDiskMark under Wine but the difficulty is its menu shows Windows drive letters e.g, C:, D:, E: ... How does Zorin map partitions into Windows drive letters? Confusingly, it shoes more drives than I have mounted. Is it also mapping the tmpfs partitions?

Will CrystalDiskMark produce the same numbers under Zorin as under Windows. I still have my Windows 10 partition so I can test this myself if no one already knows the answer.

However, CrystalDiskMark does show drive letters and at least some of these drive letters match Linux partitions by size. I was able to run CrystalDiskMark on a particular flash drive because it had a unique partition size. Unfortunately, all the other partitions have the same size and cannot be differentiated by size. It seems to me Wine is mapping Linux partitions into Windows drive letters. The flash drive was formatted as MBR/FAT32. I really only want to use CrystalDiskMark for testing flash drives which I can always format at least temporarily to MBR/FAT32. The other partitions were on my hard disk which was GPT/EXT4 so CrystalDiskMark did see these GPT partitions. I can always create a small NTFS or FAT32 partition on the GPT hard disk if I wanted to test the hard disk.

Wine is a Windows emulator and therefore it is only logical that it will emulate Windows drive letters by mapping into Linux partitions. I have found the mapping - open the menu item - Wine -> Configure Wine -> Drives.

I also created a GPT/EXT4 partition and CrystalDiskMark worked on this partition also. Incidentally, if I was writing a drive test program I would not use the existing file system but I would create a small temporary "standard" file system and test against that. That would remove the performance of the file system as a variable. The idea is to test the performance of the drive independent of the file system.

Of course Windows can't read a EXT# partition but a Windows emulater can. That is the idea of emulation - you emulate something using something else.

The problem with using Linux software for drive testing is most of the world will not understand what those numbers mean. But CrystalDiskMark is so popular that it has become a de facto standard for testing drives.

Wine Is Not an Emulator
Wine attempts to run Windows applications on the Linux OS, not emulate Windows itself.

Gday @mcuda , when using Linux a lot of thing's/habits/terminology/etc from Windows need to be divorced.

In brief as explained above & as your finding out, this terminology isn't cross-platform.

In Zorin OS, and generally in Linux systems, drive letters are not used to map partitions like in Windows. Instead, Linux uses a hierarchical file system where each partition is mounted to a specific directory within the file system.

When running CrystalDiskMark under Wine, the drive letters you see in the application's menu are virtual representations provided by Wine to emulate the Windows environment. These drive letters do not necessarily correspond to the actual drive letters used in your Zorin OS system.

Regarding the extra drives shown in CrystalDiskMark that you haven't mounted, it's possible that Wine is presenting some virtual or virtualized drives that may include temporary or system-related partitions. These may include things like the WINEPREFIX directory or other internal Wine-related elements.

It's important to note that these virtual drives shown in CrystalDiskMark do not necessarily represent the actual mounted partitions in your Zorin OS system. To accurately identify and test your mounted partitions, you should refer to the Linux utilities you mentioned earlier & further suggested in above posts, such as GNOME Disks or command-line tools like bonnie++ or hdparm, as they provide information specific to your Linux system's partitions and devices.

If your married to CrystalDiskMark, like most programs, Linux normally has an alternative, in this case it's called "KDiskMark" you can find it in the software app store.

To help further:
Linux, drives and partitions are typically represented as block devices and are accessed through the directory structure. The root of the file system is denoted by a single forward slash (/). Here are some common directories used in Linux for drive identification:

  • " / ":
    The root directory and the starting point of the file system hierarchy.

  • " /dev ":
    This directory contains device files that represent hardware devices, including drives and partitions. For example, "/dev/sda" represents the first hard drive, and "/dev/sda1" represents the first partition on that drive.

  • " /mnt " or " /media ":
    These directories are used as mount points for manually mounting external or internal drives. Mounting a drive attaches it to a specific directory in the file system, allowing you to access its contents.

It's important to note that in modern Linux distributions, drives are often automatically mounted under the "/media" directory when connected. Each mounted drive is usually assigned a subdirectory under "/media", which can be named based on the drive's label or other identifiers.

Additionally, Linux allows for more flexible and customizable mounting options, including network shares and virtual file systems. This allows you to mount various types of drives and file systems seamlessly within the directory structure.

Overall, Linux does not rely on drive letters like Windows but instead uses a directory-based approach, providing greater flexibility and control over drive identification and mounting.
Hope this helps.

1 Like

I never heard of it, either. But I figured that I am just behind the times...

CrystalDiskMark is a well-known application in Japan.

I have read the source code of CrystalDiskMark - - see file CrystalDiskMark/DiskBench.cpp

The work is being done by 3 Windows system calls - CreateDirectory(), CreateFile() and WriteFile() these can very efficiently be emulated by the Linux system calls mkdir(), open() and write(). CrystalDiskMark is file system agnostic - the kernel knows the file system type from the path and will redirect the system call to the appropriate file system driver ext2, ext3, ext4, ntfs, fat32. It should work under Wine.

However, since CrystalDiskMark is using the existing file system the benchmark will have a dependency on the implementation of that file system so to be comparable to a test run on Windows CrystalDiskMark should be run on FAT32 or NTFS whichever was used on Windows.

I did figure this out - the extra drive was a virtual C: drive that Wine creates to support the Windows environment, it has a C:\Program Files folder.

However. if you open the menu item Wine -> Configure Wine -> Drives you will see some drive letters are for actual physical partitions. CrystalDiskMark will run on these partitions and since it is file system agnostic it doesn't matter if they are ext2, ext3, ext4, ... I have test this and it works.

Thanks for the info about KDiskMark - I did not know about this.

At the end of the day /dev/sd*, /media/user/*, d: are just handles to some kernel objects - you are free to access those kernel objects via the handle of your choice.

1 Like

You are totally correct - it is not emulating the Windows code but replacing Windows library and system calls with functionally equivalent Linux code.

What does regiyuraa mean? I can read katakana.

CrystalDiskMark is well known in the PC world where I came from. In fact I regularly use GNOME Disks but I want to communicate with people from the PC world and they will not understand GNOME Disks without some effort but they can just glance at the output of CrystalDiskMark and have a feel for what those numbers mean. Since, CrystalDiskMark is open source I think Ocka's KDiskMark is a port of it and will provide the same numbers. You are angry with me but I think you should read your original response to my question - it is total nonsense.


If you were to read/view tests of drives you will find most of reviewers use CrystalDiskMark. It is not the best benchmark - better benchmarks were developed later - but because people have become very familiar with CrystalDiskMark numbers reviewers still use it - the more technical reviewers will in addition also use a more recent and better benchmark.

Wine makes it possible for Windows applications to access Linux ext2, ext3, ext4 partitions. The Wine compatibility layer redirects Windows ReadFile(), WriteFile() system calls to Linux read(), write() system calls. The application itself is usually ignorant of the underlying file system. The same Linux application will run on an ext2, ext3 or ext4 file partition. It is ignorant of the actual file system type being used. The kernel using the file handle can determine the file system type and redirect the call to the appropriate file system driver. In the same way a Wine application can read/write from/to ext2, ext3, ext4 file partitions.

Wine replaces Windows API calls with "equivalent" Linux calls. This "equivalent" is not perfect and sometimes the imperfections will be significant enough so the Windows application will not run correctly. Other times the application will run perfectly.

You are absolutely correct. In fact the numbers that CrystalDiskMark are computing are very wrong.

The critical point is under Wine Wine reads the partitions not Windows. There will be Windows application e.g., diskpart that are aware of the actual file system being used and will use API calls that have no Linux equivalent and of course there is no way Wine can implement these calls and the application absolutely will not work. More generic applications e.g, wordproccessers, spreadsheets, ... that are not intimately dependent on the filesystem should run just fine.

You are not being honest here. Your original response stated something very different - CrystalDiskMark cannot run at all - it doesn't produce valid numbers but it does run. It is clear to me that you fundamentally don't understand how Wine works - I think you should do more research before you comment on things you don't understand.

@mcuda Even if you win this argument, Wine will not work the way you want.

This summarizes the topic neatly.

WINE serves the purpose of running some Windows applications on Linux. It is not intended to run System Applications.
To perform what you are seeking, using a Linux application would be the best route:

It does not matter which specialty a person focuses on in tech: Every part of tech requires the person to be adaptable and willing to learn. If you are using Windows, then using a Windows Tool is logical.
If it has certain conventions, you learn those conventions.
If you are using Linux, then using a Linux Tool is the logical approach and in just the same way, you must be willing to learn the conventions.

1 Like

In your initial response you stated that CrystalDiskMark cannot work because it needed drive letters and it cannot read ext* partitions. This is not true and shows a that at least initially you did not understand how Wine works. Wine supports drive letters and supports accessing ext* partitions.

Linux supports both FAT32 and NTFS and of course I would run CrystalDiskMark under Wine using either FAT32 or NTFS to remove the dependency on the file system. I don't think CrystalDiskMark is aware of the type of the underlying file system at all - it simply is creating files and writing to and reading from these files and timing the cost of these calls using API calls that are file system agnostic. (It is the kernel that knows the file system type and then redirecting to the appropriate file system driver.) In other words, CrystalDiskMark does not have or need code that is file system specific. Unfortunately, it still has a dependency on the actual implementation of the file system drivers which are totally different since the Linux drivers were independently written.

You are correct. I am surprised that it didn't work. The API calls CrystalDiskMark are using are so low level that I would have guessed that the "emulation" (I don't know what the right word is here but you know what I mean) would have been near perfect. But, it isn't. I don't yet know why but I find it interesting and will find out.

CrystalDiskMark is not really a system applications - it doesn't call functions in the system API. There are API calls specific to the OS that system applications will use but CrystalDiskMark isn't using any of these. CrystalDiskMark behaves like a normal user application. As I have said previously although it does run "normally" the numbers are funny. Something is distorting the timing calculation. I intend to find out what as this looks like an interesting problem.

Actually, I do use the Linux tools frequently and I think very skillfully. The reason for my interest in CrystalDiskMark is I wanted to communicate with users in the Windows community (which is more than twenty times larger than the entire Linux community) with numbers that they are familiar with. At the time I was not aware of KDiskMark which I think does what I want - thank-you for the head-up.

This is not surprising to me, since Wine is more about performance than having the same behavior as Windows.

This is impractical for the reasons mentioned above: even if an application running by Wine returns some value, it is not comparable to Windows.

Actually, no. Linux as a whole does not support NTFS. Zorin OS does with the inclusion of the ntfs-3g package.

I do not agree with your take on this but I also do not feel like diving deep and digging through the source code on CrystalDiskMark just to belabor a point.
If KDiskMark can resolve your issue - that is what matters most.

I was not aware of this. Thank-you for the correction.

I looked at KDiskMark - it is not a port of CrystalDiskMark but a new implementation. The GUI mirrors exactly CrystalDiskMark's GUI and I think it may do exactly what KDiskMark. Again, thank-you for the heads-up, I was not aware of it when I wrote my original post.

As I want to understand why CrystalDiskMark did not work as I expected I will investigate this further. However, I think I will do this community a favor and leave this forum. Have a good day - Bye.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.