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.

Linux uses the /dev/ directory to map hardware and mount drives. Drive & partition letter assignment is not used.

While Crystal is a software you are familiar with, this limitation makes it useless for Linux system drives.

Even booting into windows won't help since windows can't read ext# partitions, so will never assign a drive letter to it.

Your only options are Linux compatible software for drive and partition management.

Have you tried smart disk assessment? You can access it in disks application.

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 configures a file with a drive letter, inside of your existing partition. Using that, depending on the purpose, may or may not give an accurate depiction of what you are looking for. Being that you will only be testing one portion, about four gb of a drive, there is no certainty you can determine how the drive performs, what sectors are not functional or any other type of metric possible. This is like being allowed to beta test software for five minutes and decide on the three hours worth of features performance, experience and general functionality. It's absurd.

Read the documentation... try man dd and or gnome-disks and you will find all the information you seek.

Just because a software is popular doesn't make it the industry standard. Expect software not to give you what you are looking for and it won't. Be willing to learn and adapt and new software may surprise you.

Do what you will, but it will not give you an accurate depiction of drive health or performance from that slice of data. Believe what you will.

By who? I'm a technician and engineer, yet I've never heard of this software. I can use disk management as well as dd, gparted or disks to get the info I need. You seem to be a power user, but refuse the tried and true tools of the industry. Confusing.

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 - CrystalDiskMark8_0_4Src.zip - 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.

[

I am not angry. Frustrated, maybe, but not angry.

This is a software I never knew existed, yet you say it's an industry standard. Not in the US. My response is based on your representation of the software. Since it needs drive letters, it is a windows only application and only recognizes a handful of filesystem formats. If ext is a part of the original code, than it is capable to access ext...windows can not without third party intervention.

The fact that wine replaces the system calls, does not mean it is compatible for linux. Are algorithms in place to take into account the difference in read times due to linux contiguous storage verse windows fragmented storage types? This alone can give false reading in software.

Windows disk manager tells me that the linux partition is damaged and in need of repair, but that is because it doesn't read ext#.

My logic is sound. Not knowing the limitations or abilities of the software, I provided a response. Not all windows software works in wine, and not all windows software that does work in wine should be used in wine.

Ask the developers to add Linux and or Mac support...this will ensure that any metrics provided are valid and trustworthy. As of now, I still stand by my original recommendation to use software that includes Linux support. Which you call nonsense because it doesn't give you the answer you are looking for, but is sound advice.

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.

I do understand how wine works. I'm failing in relaying the concept I'm trying to get across.

Crystal is a benchmark software, expecting FAT, FAT32 or NTFS. Though EXT4 is a journaling file system, it is not NTFS and the algorithms to test it are going to be different than those for NTFS. The data is incorrect, giving false information due to this. It was not programmed to recognize or deal with the differences of ext4, the lack of drive letters, the ability to adjust the metrics for ext4 or recognize the FS at all.

Though wine is interpreting the calls properly, the lack of support in Crystal for this FS makes it a poor choice for benchmark software in a Linux environment.

Ask the developers to include Linux support if you insist on using the software.

@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.