Talk:File Allocation Table

archive 1 (2004–2007)

Maximum FAT32 format in WinXP

Hey all. I dont have much experience in Win2k but I have, many times, formatted a 120GB drive with FAT32 in WinXP. It needs to be done from the Microsoft Management Console as far as I've seen, but it is possible.

Same here. I just used the FORMAT command on 250GB drive in fat32. Some of the confusion might be different front-ends: command-line, MMC drive manager, wizard? I also speculate that the restriction may have been lifted at some time (via updates), not per OS version. —Długosz (talk) 03:23, 13 February 2008 (UTC)

Then again, it did not work! It was happily formatting, but I didn't want to wait 6 to 10 hours, so I broke out and did a /q format. It complained that the partition was too large. Would the non-quick format have complained after writing all the sectors?!

Meanwhile, in contrast to the report from the anonymous poster above, the MMC "Drive Manager" snap-in did not give any choice other than NTFS. I found [1] and worked on Vista. —Długosz (talk) 04:50, 13 February 2008 (UTC)

Errors in file system information at ntfs.com

Tarun just changed the file size limits on FAT32 and FAT16 to 4 GiB − 2 bytes and 2 GiB respectively on the basis of this table (I assume) at ntfs.com. I've just verified that this is incorrect by creating a >2 GiB file on a FAT16 volume with 64K clusters and a 4 GiB − 1 byte file on a FAT32 volume, using WinXP Pro SP2. Here are some other mistakes I noticed, while I'm at it:

• Long file names on FAT12 aren't limited to 254 characters (verified).
• Long file names on FAT aren't limited to the "system character set", assuming that means the system code page (verified). I think this is true on Win9x, but that's an operating system limitation that applies to all file systems, including NTFS volumes mounted over the network.
• The number of files on a volume is not limited to 4194304 on FAT32 or 65536 on FAT16 (verified).
• No OS that I know of limits FAT32 volumes to 32 GiB. It's a limitation of some Microsoft formatting tools, not of the filesystem implementation.
• NTFS volumes are not limited to 2 TiB.

-- BenRG (talk) 17:13, 3 February 2008 (UTC)

ExFAT File Size Limit

According to MSDN, there is no 4 GiB file size limit on ExFAT file systems. See http://msdn2.microsoft.com/en-us/library/aa914353.aspx However, I'm not sure what the actual limit is.
Vfs (talk) 17:26, 9 March 2008 (UTC)

The article says now that exFat has "support for files up to 2⁶⁴ bytes". — Wenli ^{(reply here)} 02:27, 30 May 2008 (UTC)

Proposed Change: slightly misleading statement about impact of fragmentation of solid state media

The 3rd paragraph in the introduction says:

[...] fragments tend to become scattered over the entire disk, making reading and writing slower. [...] . Due to a limited number of lifetime writes, and their quick access times, solid-state memory cards should usually not be defragmented.

The last sentece should be changed to:

Solid-state memory (such as flash memory cards or flash usb sticks), should not be defragmented. They don't suffer speed degradation by fragmentation due to their design. Additionally running a defragmentation program will reduce the lifetime of these media by using up a significant number of their limited number of write cycles.

Reason:

I think the original statement is a bit misleading in implying that solid state disks will, at least to some extent, suffer read/write speed degradation from fragmentation. This is not the case. The reduced speed is a direct result of the access latecy due to the movement of the read/write heads of magnetic and optical media. Reading is only significantly slower if fragments are in different tracks (rotational delay might also have an effect but that is significatly less). Due to the design of solid state media, their access time is the same for each cluster, regardless where it is stored. Viper144 (talk) 18:18, 15 June 2008 (UTC)

I agree that's the primary reason. However, sequential contiguous sectors inspire increased efficiency in other ways. One is because some driver code (such as FAT drivers I've written) looks for opportunities to reduce the number of kernel read operations by increasing the size of a read if subsequent linked clusters are sequential. —EncMstr (talk) 20:51, 15 June 2008 (UTC)

Also in the case of fat reading a fragmented file requires reading more sectors of the file allocation table (for a badly fragmented file it may require reading a sector of FAT for every sector of data!). So it will be slower even on media where all sectors cost the same to read. Plugwash (talk) 13:36, 18 June 2008 (UTC)

Binary Units

Shouldn't all the filesystem limits be listed in kib, MiB, GiB and TiB? These limits naturally come from the number of bytes you can address with integers of certain length so i'm pretty sure it would be binary limits. —Preceding unsigned comment added by 98.213.141.241 (talk) 01:35, 2 July 2008 (UTC)

I agree. In several of the computer-related articles, attempts to implement that have been reverted with the reasoning that the manual of style doesn't endorse binary units. It should be straightened out first before fixing the articles again. —EncMstr (talk) 01:53, 2 July 2008 (UTC)

The deprecation of IEC units was introduced on 7 June 2008, despite a clear consensus against such deprecation. Thunderbird2 (talk) 15:03, 5 July 2008 (UTC)

Not true. The text you, TB2, refer to was put there with consensus, the link you provided claiming "despite a clear consensus" misrepresents the truth of where the consensus is. This is because firstly votes (the link you provided is nothing but a vote) don't make consensus, good arguments make consensus. Secondly the real consensus is here. Thirdly the vote you cite is old. At the time you did not present substantive arguments and you have still have not provided substantive arguments. The consensus is actually for the text in MOSNUM which includes the deprecation of IEC prefixes for the many good reasons given in the link I have provided. Fnagaton 16:38, 5 July 2008 (UTC)

Now back on topic. The IEC prefixes KiB, MiB etc should not be used in this article because they are not used by the sources we cite, they are unfamiliar and therefore confuse readers and because of WP:UNDUE we have to use terms that are used by the real world. Obviously IEC prefixes are not commonly used in the real world, so we don't use them here either. What is much more familiar and easily understood by the average reader is to state the specific number of bytes used for a quantity. The average reader understands the number 1024 much better than KiB. One of the goals of disambiguation is to help clarify, not to cause more confusion. The last time I checked the goals of disambiguation did not include the promotion of virtually unused IEC prefixes. Fnagaton 16:41, 5 July 2008 (UTC)

Should MOSNUM continue to deprecate IEC prefixes?

A discussion has been started at WP:MOSNUM concerning the continued deprecation of IEC prefixes. Please comment at the MOSNUM talk page. Thunderbird2 (talk) 19:15, 5 July 2008 (UTC)

Simple Error

Shouldn't this:

"Common implementations have a serious drawback in that when files are deleted and new files written to the media, directory fragments tend to become scattered over the entire disk, making reading and writing slower on storage devices, which have lower seek time for random data access (Such as mechanical hard drives)."

Be:

"Common implementations have a serious drawback in that when files are deleted and new files written to the media, directory fragments tend to become scattered over the entire disk, making reading and writing slower on storage devices, which have higher seek times for random data access (Such as mechanical hard drives)."

After all, why would it be worse if fragmentation happened on a drive that dealt with it better (lower seeks times are better for fragmented drives).70.62.232.146 (talk) 18:32, 15 July 2008 (UTC)

What about saying "making reading and writing slower on mechanical storage devices (such as hard disk drives), for which access to random locations on the disk requires more head movements, hence increased seek time." 82.67.122.43 (talk) 20:33, 19 July 2008 (UTC)