Talk:ExFAT/Archive 1

Archive 1

How max cluster size may be greather than max file size?

--Dojarca 14:25, 9 October 2007 (UTC)

Why not? It's not a contradiction. They may very well have designed it that way. Unsound (talk) 04:59, 7 June 2008 (UTC)

No idea, yet it hasn't been updated in Microsoft's Connect site; so unless it's being beta tested inhouse; who knows.. Many beta tester's including myself think that it may be dead. :( —Preceding unsigned comment added by 65.185.10.34 (talk) 21:29, 16 October 2007 (UTC)

2^255 cluster size, that's great :)

it has to be 2^25 i think, because 2^25=32MB

--194.27.118.26 (talk) 12:18, 19 March 2008 (UTC)

I agree that it does look a little weird, but look here [1] and you'll see that they too say that theoretically the FAT64 file system supports cluster sizes of up to 2^255. I guess they simply felt that oversizing one particular field in a header in order to absolutely guarantee future-proofness is a minor waste of space (32 bytes is really nothing). I would guess that the cluster size field is simply 256 bits long. Unsound (talk) 04:57, 7 June 2008 (UTC)

And I think it's one byte long, but its value means the exponent of 2. So the value 5 would mean 2⁵=32 bytes or perhaps sectors. This would easily explain why the theoretical limit is 2²⁵⁵--Azarien (talk) 10:13, 21 January 2009 (UTC)

Yes, the 8-bit exponent is documented in the Microsoft patent application now referenced on the main page. Richardguk (talk) 22:47, 4 August 2009 (UTC)

The sector size is one byte, and is a power of 2. The largest sector size, as per the current specification is 4096 (2^12). The standard sector size is 512 (2^9). So the value is usually 9. The cluster size is not specified, the largest cluster as per the specification is 32MB (2^25) The number of sectors per cluster is one byte, is a power of 2, and specifies the blocking factor. The two bytes (sector size and blocking factor) must be <=25. — Preceding unsigned comment added by Rshullic (talk • contribs) 18:07, 17 October 2012 (UTC)

Windows Server 2008

I added Win2008 to the initial description but couldn't find an external source...I know it supports it because I just formatted my flash drive with it :-) I suppose I can't use a screenshot of the format screen as a citation... —Preceding unsigned comment added by 209.143.2.97 (talk) 14:29, 16 May 2008 (UTC)

I think there's no need for external sources for things that are easily verifiable by anyone.--Azarien (talk) 10:16, 21 January 2009 (UTC)

I can verify that. File system driver exists in Windows Server 2008 and there is support in the "format" utility. So it's fully usable. I added it to the info box. Unsound (talk) 04:47, 7 June 2008 (UTC)

I've just had a go at using an exFAT formatted drive with a Win2008 server and the server didn't want to copy files larger than 4 Gb to it. It may be a local phenomenon but a warning might be in order.

Merge with File Allocation Table?

All other FAT file systems are listed under the File allocation table article, and I don't think exFAT/FAT64 should be any different. Unsound (talk) 04:43, 7 June 2008 (UTC)

See #Merger proposal further down. —92.27.34.75 (talk) 17:16, 25 March 2013 (UTC)

Difference between "free space bitmap" and regular?

Isn't the standard "sectors used" map the same thing as a "free space" map? In one case you are looking at the filled portion of the map. In the other you are looking at the empty portion of the same map.

It's unclear in this article what function an entirely separate free space map provides compared to the regular sector usage map.

DMahalko (talk) 15:14, 16 March 2009 (UTC)

Support in Vista with SP2?

In the ReadyBoost page it says that Vista (with SP2) will be able to read exFAT. Yet this article says that it isn't able to be read in Vista. Is one wrong? Should this one be edited to reflect the information in the ReadyBoost page? --97.100.228.74 (talk) 19:42, 12 April 2009 (UTC)

The ReadyBoost article now concurs with this page. BabelStone (talk) 11:38, 16 June 2009 (UTC)

Contradictory size limits

I've made several tidying updates to the main article, including new footnotes. But there seems to be a contradiction about the file and volume size limits between the specification appended to the patent application and the Knowledge Base article about the exFAT update for XP.

• While implementation limits might reasonably vary, is it really theoretically possible for file sizes to reach 64 ZiB (2⁷⁶ bytes) when the internal DataLength field is a 64-bit byte count?
• Does the 512 TiB recommended limit apply to all current implementations?

Richardguk (talk) 23:01, 4 August 2009 (UTC)

Further on the contradictory size limits, the Microsoft KB talks about theoretical vs. recommended sizes, and say the theoretical limit of FAT32 in Windows XP is 32GB. While this is the limit that XP will format to FAT32, it can still read larger FAT32 volumes made with other tools. I believe 2TB is the limit of FAT32, while 32GB is the recommended limit. —Preceding unsigned comment added by 142.68.60.234 (talk) 16:02, 7 October 2009 (UTC)

If you read the KB on FAT32 for XP, it states that the maximum volume size of FAT32 is 8TB. http://support.microsoft.com/kb/184006 What they did is take the maximum number of fat index (2^28) times 32KiB and that gives you 8TB. The idiot that wrote the KB did not consider that the BPB was a 32 bit number and FAT32 was restricted to 2^^32 sectors.

In exFAT, as I tried to explain, you have 2^^25 for the max cluster times 2^32 index = 2^57 bytes which is 128PiB. but it I really 2^32 minus 11, so its a little less. Now, to add injury, the current standard is LBA-48, which means you can only address with 48 bits. You can't get 64ZB until someone invents and implements LBA-64, and you still need to increase the size of cluster because the FAT is still 32 bits. So, in the XP KB they blundered the other way and took the 64 bit number in the BPB without looking at what the FS supports.

There is a blog from someone from MS that states when FAT32 development was being done, they did math (as we can see MS can't even do arithmetic) and figured that with a 32K cluster (this ws before 64K clusters were allowed) and a 32GB disk, there would be 1 million FAT entries, and 4 bytes per entry, that is 4mb of FAT. In a heavily allocated disk looking for a free cluster would mean reading 4mb of FAT to find it. FAT doesn't have B-Trees link NTFS, so yes, MS limited FAT32 and created this limit based on projected performance (back with Windows 95 OSR2 which was what? 1999) where I/O was slow.

They I look at it, you have theoretical limits (which in some cases is as relevant as the moon is made of cheese - a theory). Then you have the implementation, which Microsoft says this is realistic, or restricted due to other reasons, or MS puts a governor in to lock it there. An example of restriction could be something like the LBA-48 or something else. But I like to have a middle ground here, because there is theoretical and implementation, and in-between a "architectural" limitation. So, when you get to exFAT size, the maximum file size is Theoretical 16EIB because the length is 64 bits, the architectural length max is 128PIB (approx.) because the file system cannot grow that big, and the implementation is restricted to 512TB because MS limited the file system to that and a file can't be bigger than the FS.

This leaves us to cut through the noise and dothe mth nd show that there are contractions, why they are they, and what the numbers should be - we need to show out math — Preceding unsigned comment added by Rshullic (talk • contribs) 06:38, 1 June 2014 (UTC)

Support in Linux

Please work with this: http://lwn.net/Articles/348825/ (my english is not to storng for this job) Thanks! 27 Aug 2009

We need to say that Microsoft company didn't released exfat file system spcecifications. And i think Linux support is very experimental and it's not good to use for every day. —Preceding unsigned comment added by Kesrut (talk • contribs) 11:04, 16 June 2009 (UTC)

Agreed, and done. BabelStone (talk) 11:38, 16 June 2009 (UTC)

Added a sentence to the end of the appropriate part of the restrictive patents section referencing the current working FUSE based extfs driver for Linux. I know my addition needs work, was wondering if someone more knowledgeable about this driver might shed some light as to how complete it is as data is scarce. I know it's good enough to be in Ubuntu's main repository. https://code.google.com/p/exfat/ Insidious611 (talk) 18:43, 29 September 2014 (UTC)

Invalid Patent

A section should be added which outlines the enormous amounts of prior art that exist that invalidates this patent. Either way NO PATENTED TECHNOLOGY should be ALLOWED to be made a STANDARD. This happened with GIFs and people are retarded to think this won't hurt them. —Preceding unsigned comment added by 80.68.93.104 (talk) 13:41, 22 October 2009 (UTC)

That definitely doesn't warrant a whole section. And I'm not sure it warrants inclusion at all. This is a descriptive article, and while everyone loves to complain about software patents (in many cases for good reason), whining about it on Wikipedia in every case is petty, and not particularly encyclopedic. --ShadowRangerRIT (talk) 15:02, 22 October 2009 (UTC)

I agree. That is a criticism of the patent system (particularly as it exists in the United States), not of exFAT. It doesn't belong here. In any case, who is makign these assertions? It sounds like your view which we are not interested in as per NPOV. CrispMuncher (talk) 20:09, 22 October 2009 (UTC)

While largely agreeing with CrispMuncher and ShadowRangerRIT, the only thing I will point out is if there is specific reliably sourced criticism of the patents covering ExFAT, in particular allegations that some of the patents are invalid because of prior art, then there may be some merit to mention that in the article. However as I've mentioned this has to be specific and reliably sourced. General comments on how bad the patent system is or how the US or whatever patent office is always granting invalid patents because they fail to uncover prior art are not suitable for this article. And we also have to bear in mind WP:Undue Nil Einne (talk) 04:14, 25 January 2010 (UTC)

TRS-DOS 2.0 published by Radio Shack in 1978 may be prior art for at least two of the independent claims of US 2009/0164440 A1, and probably some of the dependent claims as well. See my blog entry [2]. --Brouhaha (talk) 06:03, 17 September 2012 (UTC)

Let me point out that US 2009/0164440 A1 is not the exFAT patent. The patent is one on extensible file system, which BTW was approved in 2013. And MS fought hard on that one because there was challenges. US 2009/0164440 A1 is wrongfully being called the exFAT patent because a copy of the specification was included as an appendix. US8583708 B2 (Nov 12, 2013) is the real exFAT patent.

In reading the article, including this section, we are seeing the same kind of gripe, which is all over the internet and I don't think is appropriate here. That is that the open source people are not Happy that a propriety file system is out there and people have to pay for it. They are also unhappy that Linux file systems such as ext2, ext3,and ext4 were not used instead. I just think that this type of complaining should not be here, and it needs to be removed. — Preceding unsigned comment added by Rshullic (talk • contribs) 06:47, 1 June 2014 (UTC)

Why not NTFS?

The article needs to discuss why Microsoft believes a new file system is necessary. Why not just use NTFS? Currently all the article says about this is, "exFAT can be used where the NTFS file system is not a feasible solution, due to data structure overhead," which is not at all clear. Comet Tuttle (talk) 01:00, 5 March 2010 (UTC)

It would need some sourcing to go along with it, but I suspect much of the "overhead" spoken of relates to permissions, security and ownership data which aren't really necessary on a portable storage medium. —Locke Cole • t • c 02:10, 5 March 2010 (UTC)

I think Microsoft's statement is based on a marketing decision, not a technical one. System internals, originally by Mark Russinovich, posted a utility NTFSFlp at least eight years ago which modified the NT floppy driver to get out of the way and allow NTFS to format a floppy volume. It worked okay, but there were a few extra seconds of disk writing compared to a FAT file system that seemed lengthy, but really wasn't all that bad. The accompanying technical investigation reported that it seemed as though Microsoft sabotaged format by artificially increasing the minimum size of $LogFile. Naturally, Microsoft no longer offers the utility since they acquired System Internals.[3] The security overhead amounts to just a few clusters on a small NTFS volume. —EncMstr (talk) 06:24, 5 March 2010 (UTC)

One of the primary reasons is probably the amount of metadata NTFS stores makes it unattractive for smaller volume sizes. There's a knowledge base article on this: [4] which is old enough to consider it worth comparing to HPFS in addition. For a 100Mb partition metdata accounts for 4% of capacity. Reading between the lines and applying common sense it would be even more for smaller drives.

Also, NTFS is a much more complex standard. Embedded devices would need to be more powerful to deal with that overhead and sofrware development costs much higher. If you keep an eye on the embedded groups you'll see engineers having problems with plain old FAT. Targeting NTFS would be orders of magnitude more complex and also immediately rule out the small microcontrollers with a few kilobytes ROM and perhaps a kilobyte RAM. CrispMuncher (talk) 22:13, 5 March 2010 (UTC)

Thowing in my 2cents. First, look where exFAT came from. Windows CE, which is in the line of embedded systems. They are made to run with very small amounts of memory, low power, and the actual OS is minimized. Windows CE is like Windows, but a different code base. Windows XP embedded is desktop code, but stripped down and customized. (ok, I read about older Windows phones using NTFS for their OS). FAT was the logical choice to provide a lean OS with a smaller footprint, and as I read somewhere, to be able to put the code into firmware - this is the origins of exFAT. Second, look at where exFAT is going. It is considered optimized for flash memory. Today disks, even magnetic disk, but mainly large capacity flash storage AND SSD are leaving the factory pre-formatted as exFAT (and yes, some are still NTFS and even HFS or what ever MAC uses). But one of the major issues in flash is to limit the writes. in exFAT - the FAT is no longer used or updated - unless the FS is fragmented. The bitmap is used for allocation. reading a sector of 4096 BITS (512 bytes) give you allocation status on 4096 clusters, where when using a FAT for allocation, you would have to ready 128K because you needed to look at one 32bit word to determine if one cluster was allocated. This is also part of the performance improvement. And with the SDXC, reduction of limitations - breaking the 4gig barrier. Now, considering 4K TV resolution, recording HDTV is going to send bits like drinking like a firehose, besides the bigger bus (UHS-2) they need a lean filesystem where the overhead doesn't get into the way and slow things down

And one more thing (because I have been reading the SD specs), NTFS still has a largest cluster of 64K, exFAT is 32MiB, and the SD specification actually supports a maximum cluster (they call it an AU - Allocation Unit) of 64Mb. NTFS isn't cutting it. — Preceding unsigned comment added by Rshullic (talk • contribs) 07:02, 1 June 2014 (UTC)

exFAT aka FAT64. FAT64?!?

Shouldn't it be pointed out that exFAT is most definitely not a FAT64 and it is not sensible in any way to incorrectly call it FAT64 because FAT64 would be a FAT file-system where the FAT has 64bit entries. As far as I can see exFAT uses 32 bit FAT entries the same as FAT32. (exFAT may use 48 or 64 Bit FAT entries for really big drives -- I don't know because I haven't formatted anything really big as exFAT yet) BrianDGregory (talk) 23:04, 6 March 2010 (UTC) Now done BrianDGregory (talk) 01:15, 15 March 2010 (UTC)

I agree and finally removed the "FAT64" mentioning from the article. Even if some users seem to like coining new terms, we shouldn't condone this in Wikipedia. The filesystem discussed here is named exFAT. It does not (normally) have 64-bit FAT entries, so calling it FAT64 is wrong even in a technical sense. Also, the internal organization of the filesystem is significantly different from previous FAT filesystems such as FAT12, FAT16 and FAT32, so it really does not belong in this family of filesystems any more. --Matthiaspaul (talk) 04:51, 13 November 2011 (UTC)

This is not going to add anything, but I'll throw in my 2 cents. First - I AGREE, I so agree that I see FAT64 in many other places and it ticks me off. There is no place in ANY Microsoft document, presentation, or even KB that EVER used FAT64 term Based on the specification, the FAT is 32 bits, it doesn't change to 64 bits if the file gets bigger, there just isn't anything in the specification. And by the way, in FAT32, even though the FAT is 32 bits, it is really only 28 bits where the first 4 bits are not used. Maybe a result of the LAB-28 standard, don't know. A 64 bit FAT - even if planned, would be a big problem anyway, because the 64 bit file system size in the BPB would still restrict the total volume size to 64zb. — Preceding unsigned comment added by Rshullic (talk • contribs) 07:08, 1 June 2014 (UTC)

exFAT project

For a exFAT read/write implementation see http://code.google.com/p/exfat/ . As far as I know they need testers and feedback! - 5 April 2010 — Preceding unsigned comment added by 80.219.204.23 (talk)

Merger proposal

I propose that this page (ExFAT) should be merged with the File allocation table article for the following reasons:

-Virtually all formats relating to FAT (FAT, FAT16, FAT32, etc.) do not have separate articles - arguably these formats are more widespread and well-known than ExFAT

-This article's contents could be effectively placed into the File allocation table article; it contains no information that would need a separate article (e.g. history, development) - all it contains is general information about exFAT

--Michael Kourlas^{talk – contribs} 20:05, 8 June 2010 (UTC)

• Oppose: File Allocation Table is already a long article. exFAT is much shorter but more than a stub. If we merged exFAT into File Allocation Table#exFAT, some of the more detailed exFAT information could get lost or confused with the information applying only to earlier versions of FAT. In particular, I don't see how we could easily integrate {{Infobox filesystem}} infoboxes for both the legacy and the exFAT versions. It would also make it less clear which bits of the merged article were applicable only to legacy versions. Conversely, because the FAT12/FAT16/FAT32 versions are so much more widely implemented than exFAT, it seems likely that most readers of the main article will be uninterested in detailed information about the new version. — Richardguk (talk) 23:36, 8 June 2010 (UTC)

I oppose the merger, and agree this should be separate. — Preceding unsigned comment added by Rshullic (talk • contribs) 07:09, 1 June 2014 (UTC)

• Oppose: despite its name, exFAT is not a simple variant of FAT in the way that FAT32 extends the pre-existing FAT file structure, but has a completely different structure compared with FAT12/FAT16/FAT32. It would be difficult to merge the two articles effectively and would be confusing to readers. BabelStone (talk) 00:26, 9 June 2010 (UTC)

• Response from Michaelkourlas: Both of you in opposition make fair points that I had not thought of. I actually find myself agreeing with you in opposing the merger. Unless anyone has any objections, I will close the merger proposal by leaving exFAT its separate article. --Michael Kourlas^{talk – contribs} 17:12, 10 June 2010 (UTC)

Suited especially for USB flash drives?

exFAT is a "file system suited especially for USB flash drives."

In what way is it suited especially for USB flash drives? Insterested (talk) 08:57, 13 July 2010 (UTC)

I guess exFAT has many of the useful/helpful features of NTFS but doesn't cause a lot of writes to the certain areas when files are read like NTFS which wears out flash memory. Also it doesn't have per user access restrictions which can be an annoyance with drives that need to be accessed from many computers. BrianDGregory (talk) 23:57, 31 July 2010 (UTC)

What kind of flash memory does not have load leveling? I think the question stands. Fnj2 (talk) 17:47, 19 February 2011 (UTC)

Any reference explaining why exFAT doesn't wear out pendrives faster than NTFS? — Preceding unsigned comment added by 190.167.166.74 (talk) 20:08, 14 November 2011 (UTC)

I have already said a lot before )above). However, besides endurance, and performance that I specified already. It is important to align the file system to the physical structure of the flash memory, especially in SD cards, but any kind of Flash. For this reason there are separate alignments for the start of FAT and start of Cluster HEAP. If things don't line up, then it is possible that sectors don't line up properly with the page size and erase block size in the flash design. For example, in order to write flash memory, you don't just write, flash memory is like eproms, you have to erase the memory before you can write to it. And that memory is in blocks. If the filesystem doesn't align with these blocks, then by spanning a filesystem sector across two erase blocks means that to write the sector you need to erase, then rewrite two of those erase blocks, instead of one. real slow, and that is why you have wear leveling andhave to deal with the write cliff when they are properly aligned, it is worse when it is not aligned. — Preceding unsigned comment added by Rshullic (talk • contribs) 07:17, 1 June 2014 (UTC) and the OEM Parms in the VBR seems to be another flash friendly item because it allows flash parameters to be specified in the file system ----

New Apple Computers

The most recent Mac Mini and iMac both include SDXC card readers so presumably OSX should be added to the list of ExFAT supporting OSes? Urban worrier (talk) 18:22, 25 August 2010 (UTC)

This needs to be checked since these new computers might require you to re-format SDXC cards in some other format before using them. Or maybe they can only read exFAT and not write. Or maybe they are going to rely on you acquiring an exFAT implementation for OSX from somewhere else. —Preceding unsigned comment added by Briandgregory (talk • contribs) 14:53, 1 October 2010 (UTC) Sorry BrianDGregory (talk) 15:13, 1 October 2010 (UTC)

It seems confirmed that certain releases of MAC supports the exFAT, as id required for SDXC. Although I haven't tried it (but will soon) I heard that by using a camera adapter the iPAD can read SDXC. I don't know if it is true, or what IOS supports this, something to look at. — Preceding unsigned comment added by Rshullic (talk • contribs) 07:19, 1 June 2014 (UTC)

Add comparative speed differences: FAT > exFAT>> NTFS

I'm not an expert on filesystems, but when I used a USB flash drive for ReadyBoost, I found there were major differences in timings on machines and filesystems used. On my thinkpad laptop, writing to USB flash formatted NTFS was almost 6.5 times slower than if the same drive was formatted with FAT32. And I found that ExFAT is about 20% to 30% slower than FAT32! This seems very significant and should be mentioned in the article if someone can confirm this as well. Stk (talk) 04:44, 22 September 2010 (UTC)

NTFS is generally slow on low performance Flash storage. Yes for a drive used solely for ReadyBoost you obviously want the simplest crudest file system so it goes fast since you are clearly not worried about tracking access times or being able to recover data from the drive after a crash. BrianDGregory (talk) 15:43, 30 September 2010 (UTC)

Going somewhat off topic, if you want your Flash drives (and even hard drives) to go fast then try formatting them with larger allocation blocks. For flash drives in particular the Windows default size allocation blocks are usually much too small. When you get a new Flash drive it's always worth nothing down the original allocation block size before you reformat it and lose that information for ever. BrianDGregory (talk) 15:43, 30 September 2010 (UTC)

Partitions created OS X 10.6.5 are inaccessible from Windows 7

The article claims that partitions created OS X 10.6.5 are inaccessible from Windows 7 however I have not been able to find any confirmation of this either from Apple or Microsoft. Furthermore, in my own testing I have yet to experience any problems. --Severud (talk) 18:20, 13 December 2010 (UTC)

Opinion about the creation of exfat partitions in 10.6.5 removed by user mblwatson 11:44, 15 December 2010 (PST) because the article is not the place for such discussions. Should only be in the article if it is an issue recognized by Apple. — Preceding unsigned comment added by Mblwatson (talk • contribs)