As I'm working on an embedded system treating file management on media, I noticed that, using a same media (USB or SD, formated several times on both FAT32 and exfat fs), when I try to copy a file on it, it's faster in fat32 than in exfat (2 times faster).
I was wondering why I have such a difference.
I used basic busybox 1.24.1 cp function, or tar_append_tree function (from libtar), I have the same result. When I compare the cpy duration on my windows, I can't notice any difference. Do you have any clue to make me understand why there is such a gap between fat32 and exfat considering copy duration ?
Thank you in advance for your reply.
I'm migrating a product from jffs2 file system to ubifs.
Previous jffs2 design contains 3 mtd partitions ( 2 ro and 1 rw ) .
moving to ubifs - should I create :
One mtd partition and 3 volumes
3 mtd partitions, 1 volume each
Basically I'm asking if I should replace partitions with volumes when moving to ubifs ?
( my understanding that ubi layer will manage entire flash if doing so )
Thanks,
Ran
The options exist and here are the benefits...
One mtd partition and 3 volumes
The UBI layer will manage the volume. This is a flash virtualization layer that transforms unreliable flash into reliable memory. The UBI layer does wear leveling. Even for read-only data it is beneficial to re-write the data occasionally. This will recharge floating gates, etc so that the data remains readable for longer. For the read-write data it is highly beneficial for longevity. The UBI wear leveling will take place across all volumes. This substaneously increases the erase-write cycles that the file system can handle.
3 mtd partitions, 1 volume each
This is usually less desirable, but there are benefits and it maybe suitable to some users. Mainly having a separate partition increases reliability of mounting a single volume. If something happens to the single MTD partition, then your entire flash might become unuseable. By having seperate MTD partitions, a read-only MTD/UBI/UbiFS system may be useable when the read write filesystem failed.
This really is more beneficial for a 3rd option,
multiple MTD with mixed file systems.
It is possible to put CramFS, RomFS in some flash devices where a device block is gaurenteed reliable by a manufacturer. This maybe a boot file system that is all that is required for a system to minimally function. The tools for manipulating these partitions are quite simple (compared to UBI/UbiFS) and can be implemented in minimal code space. Some systems have large DDR with smaller on-chip SRAM. Loaders/flashes may have restricted code space.
That said, recently (last two years) the mtd-utils contains UBI parsing code. This might be need to be ported to a flasher, recovery code, etc. Recovery code might be in an attached initrd partition, which does mounting/fail-safe recover of the UBI/UbiFS partitions.
u-boot contains code to manage and manipulate UBI/UbiFS code and it use a two phase boot (running from internal SRAM, configuring DDR and then migrating) on many platforms to have rich functionality in a boot loader. u-boot itself will need to be on another device OR in a separate MTD as per above.
The 2nd option 3 mtd partitions, 1 volume each is probably the least likely/desirable. The first will favour system/flash life time. The last will offer simplicity of higher reliability/recovery. The best will depend on what the data is on the partitions and the non-linux resources you have available to recover data. The happy medium is to give as much NAND flash space as possible to UBI and use volumes when you want logical partitioning.
Usually, I would question why to use volumes at all and just put all the data together in such a case, but again it depends on the nature of the data.
I'm considering creating a wise ordering of writes cache (WOW cache) for a database system I'm building, but I'm having trouble mapping regions of the file to physical disk regions.
I've discovered you can use DeviceIoControl to get the virtual cluster allocations for a file but I'm unsure how to relate this to physical disk locations.
Is this possible on Windows? If not is there a workaround or a more applicable write caching algorithm.
Try the following.
First, open the handle to a volume using CreateFile routine (use \\?\C: as the name of volume C:).
Use DeviceIoControl with IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS to retrieve the physical location of a volume on one or more disks.
Thus, you will have the physical location of a volume within a disk (or several disk in more complex setups) and the virtual cluster allocation for a file within a volume. Combine these two pieces of information to get physical location of a file within a disk.
P.S. Possibly, you may also need some auxiliary information as the size of the disk sector and the size of the volume cluster.
I want to parallelize some disk I/O, but this will hurt performance badly if my files are on the same disk.
Note that there may be various filter drivers in between the drivers and the actual disk -- e.g. two files might be on different virtual disks (VHDs), but on the same physical disk.
How do I detect if two HANDLEs refer to files (or partitions, or whatever) on the same physical disk?
If this is not possible -- what is the next-best/closest alternative?
This is rather convoluted, but the first step is getting the volume name from the handle. You can do that on Vista or above using the GetFinalPathNameByHandle function. If you need to support earlier Windows versions, you can use this example.
Now that you have the file name, you can parse out the drive letter or volume name, and use the method explained in the accepted answer to this question.
Is it because the operating system is written in the C programming language?
I think that the A and B languages were not so successful?
I am thirteen and trying to do computer programming in C#.
Wikipedia gives a good explanation about the logic of drive lettering:
Except for CP/M and early versions of MS-DOS, the operating systems assigns drive letters according to the following algorithm:
Assign the drive letter A: to the first floppy disk drive (drive 0), and B: to the second floppy disk drive (drive 1), if present.
Assign a drive letter, beginning with C: to the first active primary partition recognised upon the first physical hard disk.
Assign subsequent drive letters to the first primary partition upon each successive physical hard disk drive, if present within the system.
Assign subsequent drive letters to every recognised logical partition, beginning with the first hard drive and proceeding through successive physical hard disk drives, if present within the system.
Assign subsequent drive letters to any RAM Disk.
Assign subsequent drive letters to any additional floppy or optical disc drives.
It's a left over from the original PC designs.
Originally PCs only had up to 2 floppy disk drives labelled A and B.
Some time later hard disks got added and became drive C.
The hard disk letter is C because historically, drives A and B were for floppy disks. It has nothing to do with the language in which the operating system is written.
Ah, floppy disks, remember those?
You could spend a whole afternoon coding your latest killer app, then find that you couldn't save it because it was too big to fit on a 5.25" single density disk.
That was when floppies really were floppy. Thin and flimsy, usually in either 5.25" or 8" sizes, though the first internal drives that appeared in PCs were 5.25". As previously mentioned, the early versions of MS Dos used to automatically assign drive A: to the first floppy drive and B: to the second. Hard drives didn't even fit into PCs back then. You could buy a 5mb Winchester Hard Disk that weighed about 30Kg and came in a big external cabinet nearly the size of a modern mini tower pc.
If your PC had twin floppies you could type a command something like "copy a: b:" to copy the contents of drive A: to drive B:
But then that was all back in a time when Bill Gates was worth about $10,000!
Its because A and B used to be floppy drives back in the days when floppy drives were the norm and there were no hard-disks. The letter C was given to any hard disk that the user installed. The drives A and B have since then been reserved for floppy drives. This has nothing to do with programming languages.
The origins of drive letters
*But why the letter "C"? Why not "A" or "B"? Why not "Z?"*
Unsurprisingly, the answer lies in Microsoft's old DOS roots. Long before Windows existed, most PC-compatible computer systems had only one disk drive in it - a floppy disk drive. At the time, users would insert their DOS floppy disk into the computer just before they turned it on, and the computer would start, or "boot up" via the software on the floppy.
As the first and often only disk drive installed in the computer, the floppy disk was assigned the first letter of the alphabet.
While floppy drives were attached to drive 0 and 1 (A and B), nowadays, memory card and SD cards are like any other drive (hard-drives, CD-ROM readers, ...), and simply take any drive letter after C.
A and B are kept for backward compatibility reason.
To better illustrate how (finally, Q1 2014) floppy drives are fading away, consider the new Eclipse icons:
Lars Vogel just referenced this Stack Overflow question in his article "Eclipse org.eclipse.ui switches to png files and waves good bye to the floppy disk".
It illustrates that the next Eclipse Luna 4.4 will no longer show floppy disk, but rather icons which look "now a bit like a SD card".
They are designed by https://twitter.com/enleeten from http://www.l33tlabs.com/, using png file in order to:
support transparency and therefore also look good on a dark theme (background).
I find the difference subtle though:
After:
Before (old icons):
This was recorded in bug 422175:
Someone mentioned on twitter how the traditional save "floppy" idiom is somewhat anachronistic these days. So while working on the eclipse icons, we've created a new version of the save icon.
The new icon keeps the profile of the floppy icon but replaces the diskette sliding door with some electrical contacts, effectively turning the icon into a memory card. This ensures that the icon is recognized by most users as "save" while still being representative of modern storage media.
I've attached an image for comparison.
The first row is the current icon,
the second row was a more extreme change (making it look like an SD card) and
the third row is the icon we're proposing in this bug.
On computers running Windows or MS-DOS, the hard drive is labelled with the drive letter C, because it is the first available drive letter for hard drives. The computer reserves the A: and B: drive letters for the floppy disk drive and removable media, such as tape drives, even if none of these devices are installed in the computer. As you install other drives and create new partitions, they will be assigned to other drive letters after C, such as D, E, F, G, etc.
Source
Think DOS was working from floppy drive, and windows built on DOS continued the same drive letter convention ...
On computers running Windows or MS-DOS, the hard drive is labeled with the C: drive letter. The reason is because it is the first available drive letter for hard drives. The computer reserves A: and B: drive letters for the floppy disk drive and removable media, such as tape drives, even if these devices are not installed in the computer. As you install other drives and create new partitions, they are assigned to other drive letters after C, such as D, E, F, G, etc.
I'd say that it's because the A: and B: drives were traditionally floppy drives and early computers required you to boot using a bootable floppy disk.
I strongly doubt if the lettering has anything to do with programming languages.
I think it's a kind of legacy from old versions of Microsoft Operating Systems where letters A and B were assigned to floppy drives.