Talk:Comparison of file systems

Incorrect or incomplete

HFS Plus maximum volume and file size information was incorrect. In Mac OS X 10.4 and 10.5, the maximum is slightly less than 8EB - not 16EB. In Mac OS X 10.3, the maximum was 16TB, which I think the previous author confused. One terabyte (decimal) is one trillion bytes (10^12); petabyte is one quadrillion (10^15), and exabyte is on quintillion (10^18)! —Preceding unsigned comment added by Gerritdewitt (talk • contribs) 07:49, 11 April 2008 (UTC)

I think this article is very incorrect and incomplete, and should be somewhat rewrote. Suggestions, here, please, as this weekend if no one does it firts, I'll do the job. —Claunia 02:37, 2 December 2005 (UTC)

• Please explain what you think is incorrect and incomplete, and why you think that rewriting is the answer, instead of merely correcting the parts that are incorrect and filling in the parts that are incomplete. Uncle G 03:55, 2 December 2005 (UTC)
  • Well, I mean correcting, but there are so many errors, that will be almost a rewrote. For example, it says that all filesystems supports any characters but NULL, but that is not real, specifications says illegal characters. It treats HFS and HFS+ as the same, when they are very different filesystems, and FFS and UFS1 as different filesystems, when they are just the same. It says that are not ADS aware in a lot of filesystems that are (ext2, ext3, XFS, JFS, Reiser, etc). And the most important thing I saw is that is says HFS/HFS+ not uses extents, when they are basically extent based (Extent Overflow File). There is also information in infoboxes that are not here, and viceversa. Both should be enriched. —Claunia 13:31, 2 December 2005 (UTC)
    • Most filesystems do support any characters except NUL. It is only the filesystem drivers that implement additional restrictions. There's even a clear footnote on this, footnote number 25. And, no, Unix File System is not the same as Berkeley Fast File System, as our articles on them, and the documents that they link to, make clear. (As discussed above on this very page.) If this is your idea of "correction", please do not put it into practice. Uncle G 16:22, 2 December 2005 (UTC)
      • Did you read FAT specification, for example? The implementation (DOS) don't support " " (spaces) but the specification says they are supported (ever saw "EA DATA. SF" file?). There are filesystems in the table that the specifications says clearly illegal characters and this should be corrected. Just one question, if 4.3BSD filesystem is FFS, and FreeBSD filesystem is UFS, and both drivers can read both revisions, why is it different? So we should consider the Atari ST's FAT 12, the DOS <3.0 FAT12 and the rest of FAT12s are different filesystems? And that each revision of NTFS is a different filesystem? As the only difference, as I see, are some differences in some non critical structures. (even the magic number is the same for FFS and UFS)
        • The article is correct. Spaces are supported in FAT. And if you want your question answered, read the documents linked to by the articles mentioned above. Uncle G 18:43, 11 December 2005 (UTC)
          • Spaces are supported in FAT, but nothing between 0x00 (0x0000 in LFN) and 0x1F (0x001F in LFN), however the article says it support. Article says "anything but NUL". Read Microsoft FAT specification. ARTICLE IS INCORRECT!. —Claunia 19:57, 11 December 2005 (UTC)
            • Wrong. It is the Microsoft specification that is incorrect. Uncle G 18:26, 12 December 2005 (UTC)

OK, this is a bit long, so I'm resetting the indentation, so that we can also, hopefully, reset the discussion.

There are several layers at which you can ask what characters are supported in file systems. At the lowest layer of the on-disk data structures, most file systems probably support, in file names, either all byte values ("byte" for the benefit of those talking about non-8-bit-byte systems...) or all two-byte values if file names are stored as counted strings, or all byte values or two-byte values except 0 if file names are stored as null-terminated strings. (Byte vs. two-byte depending on whether the count in a counted string counts single bytes or byte pairs, and on whether the terminator in a null-terminated string is one byte or two.) Other limitations are imposed by the layer into which a particular implementation of the file system (there can, of course, be more than one implementation of a given file system with a given on-disk layout, plugging into one or more pluggable file system frameworks on OSes that have those frameworks), or by the code above that layer.

For example, UFS's on-disk structure can support names with any byte value in them, including not only '/', but even NUL, as there's a string count in the directory entry - you still have to append a '\0', however, as the count doesn't include a terminating NUL that's supposed to be there (so a file named "foo/\0bar" would have a count of 8 and the bytes 'f', 'o', '/', '\0', 'b', 'a', 'r', '\0' in the entry). However, the VFS layers into which it plugs on most UN*Xes pass null-terminated strings to it, so, at least on those systems, the name can't include NUL. It can, however, include '/' - and, in fact, older UN*X-based NFS servers would cheerfully create files named "foo/bar" if you sent them an NFS packet requesting that a file/directory/link/symlink/etc. be created with that name; you couldn't remove the name locally, though, you'd have to do it over NFS. Most if not all NFS servers should now have that fixed, either by checking for '/' in the file system or in the NFS server code.

Similarly, NTFS's on-disk structure supports either all two-byte values or all but 0x0000 - and, with the proper (or, if you will, improper :-)) use of smbclient, you can create files with at least some of the names that the Win32 API doesn't allow (I've done that), just as you can do with the POSIX subsystem.

Further limits might be imposed by OS APIs, e.g. you cannot create files with '/' in their name through a POSIX/UN*X API, as that's a pathname separator.

In practice, implementations for OSes other than the "native" OS (or OS family - I'm lumping all UN*Xes together in one family, and both "Windows OT", i.e. 95/98/Me, and "Windows NT", i.e. NT 4.0, W2K, WXP, WServer2K3, WVista, etc., together in another family here) probably impose the same limitations the "native" OS does, at least if one of the purposes of the implementation is data exchange with the "native" OS or family.

Footnote 25 clearly states that the limitations being discussed are those of the on-disk data structure. FAT's on-disk data structure does not, as far as I know, forbid a byte with the value 0x01 in a file name. Microsoft's specification might forbid it, but that doesn't, for example, mean that you couldn't implement FAT for some UN*X and allow control-A in a file name. However, it might be unwise to do that if the goal is data interchange with DOS and Windows, as those systems won't be able to handle those files. If the goal is to hide those files (e.g., if you're trying to implement features not present in standard FAT by, for example, having, for a file named "foo", a secondary file named "^Afoo" containing something such as file permissions), however, it might actually be a wise choice (modulo file names of that sort causing DOS or Windows to crash, or destroy those files, if you do intend to read those file systems on DOS or Windows machines - or even if you don't, as somebody's probably going to try to do it anyway).

Footnote 25 also clearly states that the file system implementation, or the OS into which it plugs, might impose other restrictions.

So:

• the article correctly describes the limitations imposed by the on-disk data structure (except that some of them might also support NUL) and states in the footnote that these are the limits imposed by the on-disk data structure and that there might be other limits imposed by the OS;

• however, allowing, in an implementation, all of the byte values allowed by those limitations might be impossible on some OSes and unwise in many situations on other OSes;

• it might, therefore, be useful, and avoid some confusion (and dispute) if it were made clearer in the table itself that the on-disk data structure allows more byte values than "conventional use" of the file system does, and also indicate what the "conventional use" of the file system allows (where "conventional use" would, in most cases, be use on the "native" OS or OS family for the OS - although that might differ depending on the "Windows NT" subsystem you're using). —The preceding unsigned comment was added by Guy Harris (talk • contribs) 09:33, 12 December 2005 (UTC)
  • I just happened across this on WP:RC, but Guy - very nice explanation. A pleasure to read. (BTW, please use ~~~~ to sign posts on talk pages.) JesseW, the juggling janitor 09:43, 12 December 2005 (UTC)
    • (Yeah, I knew about ~~~~, I just forgot to sign the article; sorry about that. I was going to add some more to the discussion anyway, and sign that, and note that the previous comment was also mine, but I'll let this parenthetical note retrocredit the previous comment. :-))

      For file systems with explicit specifications it might be worth giving limitations imposed by the specification (the specification might affect other limits as well, e.g. it might limit file sizes to a value lower than the on-disk structure could support). Those limits might be different from the "conventional use" limit, in that the limit might allow certain characters that the "native OS" doesn't allow.

      Note also that the HFS+ specification in Apple Tech Note 1150 doesn't mention any restrictions on characters in file names, but, in practice, colons aren't allowed in file names, as they're traditional Mac OS path name component separators, and in OS X (and possibly other UN*Xes that include HFS+ implementations), a colon passed into HFS+ is converted to a slash on disk, and a slash on disk is passed out of HFS+ as a colon, so that OS X can read HFS+ volumes from traditional Mac OS and traditional Mac OS can (assuming OS X didn't use any new features in the on-disk format that traditional Mac OS can't handle) read HFS+ volumes from OS X. Thus, saying that the "conventional use" limit on file names is "any Unicode character other than colon" is technically true, but, in practice, OS X will accept from the VFS layer file names with colons in them and will return them, with colons, to the caller of the VFS layer. That would deserve to be noted in a footnote on HFS+, if we add "specification limits" and "conventional use limits" columns to the table. Guy Harris 10:00, 12 December 2005 (UTC)

      • Just as a filesystem developer I think containing any information that violates the filesystem specifications (like saying FAT supports anything but NUL -note that via your description supports everything, NUL also, as they are fixed length strings-) is misinformative and against the encyclopedia spirit. —Claunia 15:07, 12 December 2005 (UTC)
        • It's not misinformative. What's misinformative is the very approach that you describe. Many specifications, especially those for FAT, are written long after the fact, are attempts to revise history, and are downright wrong. Reporting only what the specifications say is to report erroneous information. Uncle G 18:26, 12 December 2005 (UTC)
          • So you think that because a paper wasn't published to public, developers work on air? Just like in the NTFS article discusion, as its specification is private there isn't one and the filesystem is allowed to have any kind of data in its structures? Or that if someone different of the inventor makes a structure modification, it should be took as official? — Claunia 22:56, 12 December 2005 (UTC)
        • As a file system developer, I think that describing what the on-disk structure can support might be useful, and including it, as well as separately describing limitations imposed by the file system specifications if any exist, and limitations of the "conventional use" of the file system, would make the description more, well, encyclopedic.

          Note, though, that if we're discussing the on-disk characteristics of the file system, "case-sensitive" and "case-preserving" aren't on-disk characteristics, they're specification or "conventional use" characteristics (except maybe for HFSX, where there's actually a per-volume case-sensitivity attribute) - a FAT or VFAT implementation could, in theory, be case-sensitive - so one could ask which on-disk characteristics are relevant. File system sizes and file sizes clearly are, but some file name characteristics might not be. Guy Harris 17:27, 12 December 2005 (UTC)

      • The convention in this article has been for the table to discuss the actual on-disc data structures, and for the limits of particular operating systems and filesystem drivers (which vary from platform to platform, which aren't inherent to the filesystems themselves, and which do not adhere to a fixed set of standards) to be discussed in footnotes. Indeed, my opinion has been for some time that the "maximum pathname length" column does not belong in the table at all, because it has nothing whatsoever to do with the actual filesystems. If it can be confirmed that the only two remaining filesystems with pathname length limits (ODS5 and UDF) in fact have no inherent pathname limits and what pathname limits exist are nothing to do with the actual filesystems themselves, it should be removed, and be discussed in comparison of operating systems instead. Uncle G 18:26, 12 December 2005 (UTC)
        • At that point, "allowable characters in entry names" largely devolves to "number of bytes per character in file name" + "are file names counted or null-terminated" (and I suspect that's true even for NSS and NWFS, unless they use very odd string encodings that really do prevent storage of some character values on disk). If that's the intent, the column should probably be changed. For most if not all file systems, the file name character encoding isn't part of the on-disk data structure; should that be given or, is it the case that, as you state, there is no "native" operating system for a given file system, and maybe IBM will use JFS2 on z/OS and encode file names in EBCDIC? In that sense, file names are uninterpreted strings of bytes or 2-byte characters, or strings interpreted only to the extent that they're zero-terminated.

          BTW, comparison of operating systems doesn't currently have anything about file name limitations, etc.. Guy Harris 21:08, 12 December 2005 (UTC)

  • We shouldn't be promulgating the notion that there is a "native" operating system for a filesystem, because in the vast majority of cases many operating systems have filesystem drivers for the filesystem, and there is no objective criterion by which any one operating system can be said to be more "native" than all of the others. "native" should not be conflated with "first implementation". Uncle G 18:26, 12 December 2005 (UTC)
• I don't know if it's appropriate or worth mentioning, but there's nothing in the on disk structure of FAT16 that disallows hard links. MS-DOS (at least 5.0) will behave in a fairly sane fashion if this is done, although chkdsk will report the directory or file as corrupt (cross linked or multiple links I forget exactly). Phredward 23:24, 1 May 2006 (UTC)
  • I must disagree with you. In order to implement hard links you need something like reference count for each file. Else, deleting one hard link will also delete the other (unless, of course, you want to scan the whole disk for each delete operation). Therefore, the on-disk structure of FAT does not allow it to have hard links. 193.226.5.159 08:35, 19 July 2007 (UTC)

If you bypass the filesytem API to manually hard link a file, and chkdsk rejects the resulting filesystem state as invalid, that would seem to be evidence that the FAT designers never intended to support that filestystem state. Similarly, nobody disputes that the ability to include a slash in a Unix filename was a bug, or that a filesystem containing such a file is in error, at least in part due to the strong Unix cultural expectation that (for example) every inode with a non-zero reference count should be addressible by at least one full pathname (and in fact fsck will detect and correct many situations where this isn't the case).

The question of a FAT filename containing CTRL-A is murkier, since so much was unwritten for so long (or written by third-party reverse engineers like Peter Norton). Microsoft now says it was never intended to be allowed, but if it's true that this was never initially communicated, and that the community of implementors developed and acted on a different prevailing belief, it's not obvious to me that Microsoft's current opinion automatically takes precedence. I do lean in the direction of taking Microsoft's word for it, however. Perhaps a new footnote is in order -- I gather you can never have too many footnotes. ;) --Saucepan 01:26, 13 September 2006 (UTC)

It looks like Talk:Comparison of file systems is still redirecting to Talk:File system. --Saucepan 01:40, 13 September 2006 (UTC)

I can confirm that NSS does support undeleting files and directories. In NSS undeleting is called salvaging. Deleted files remain until they are purged or salvaged. See http://www.novell.com/documentation/oes/nss_enu/index.html?page=/documentation/oes/nss_enu/data/bqq4w36.html --132.79.7.16 (talk) 11:47, 17 September 2008 (UTC)

Just skimming here, and wondering why there's still so much debate and so little action? Who cares if a file system on disk can support all characters except NULL? Nobody accesses a filesystem independently. Most people access a filesystem through the most common drivers and interfaces on which that filesystem is most commonly used. Who cares if I implement DOS in Linux and port it to MAC OS X and run it under a Virtual PC in Windows Vista? I want the data to behave well on the filesystem and interface where it's most commonly going to be found. Saying that all characters are supported, WHEN THEY ARE NOT, is deceptively simply, and just clutters the page with non-value-added information. Just remove it if you're not going to say what is and isn't a valid character. The entire column and this discussion is a complete waste of time. Or else include the column and include the data properly that let people understand what the differences are. 71.174.4.229 (talk) 20:41, 7 June 2009 (UTC)

All of the "unknown" under z/OS can safely be changed to "No" IBM's z/OS supports only its own native filesystems. However, one of the most important filesystems in the world, VSAM, is entirely absent from this Wiki page. It is the most common IBM filesystem, having been available from the 1970s and still the predominant filesystem in use today on MVS/ESA and z/OS. Not only is VSAM a native filesystem used in virtually every type of application, but it is also the underlying system for IBM's DB/2. —Preceding unsigned comment added by 87.70.34.225 (talk) 08:55, 5 May 2010 (UTC)

Creation timestamp support

http://www.netadmintools.com/art399.html and http://www.ibm.com/developerworks/aix/library/au-unix-reiserFS/ say that ext2 does track creation time. http://en.wikipedia.org/wiki/Talk:Ext2 mentions "change time of inode". Do ext2 and ext3 support all three POSIX timestamps? Do the drivers use them? --Ctim (talk) 10:08, 24 January 2008 (UTC)

The two web pages mentioned are wrong. Both ext2 and ext3 keep track of the inode-change time, not the file creation time. Joeinwap (talk) 23:19, 18 June 2008 (UTC)

Timestamping granularity and date limitations

It may be a good idea to add the limitations of each filesystem's timestamp(s).

• Granularity (precision): FAT-based systems save based on a 2-second interval, while others operate at 1-second intervals (I think).
• Limitations: I believe many systems start measuring dates at Jan 1, 1970, so they can't register a time before that. It would also be interesting to see which filesystems are susceptible to problems such as the 2038 problem.

Bajenkins 21:59, 26 November 2006 (UTC)

Would really like to have the information about timestamp precision too. Only reference I could find is this Java bug entry: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4697792 where it is said:

Without having a good reference source: FAT12, FAT16, and FAT32 file systems have a 2 second file time resolution. NTFS has a 100 nanosecond file time resolution. Unix/Linux has a 1 second file time resolution.

Rngadam 20:33, 18 January 2007 (UTC)

The original Berkeley Fast File System reserved space in the inode to expand timestamps to 64 bits. McKusick's expectation was that this would be used to extend the range of the timestamps, to deal with the Y2038 problem. When 4.4BSD was released (with what would come to be called UFS1), the extra space was instead used to add nanosecond resolution. (The utimes() system call had always supported setting microsecond timestamps, because it used a struct timeval, but stat() did not return them; you can see in the 4.3BSD Networking/2 manual pages that struct stat includes only st_spareX fields where the microseconds would have gone. In 4.4, struct stat has struct timespec and macros for compatibility.) When Kirk redid the inode format for UFS2, he widened the timestamp to 96 bits -- 64 bits for the time_t and 32 bits for the nanoseconds part. 121a0012 02:56, 10 February 2007 (UTC)

ZFS has 128 bits for each of access, modify, znode change, and create times. The second 64 bits hold the nanosecond portion of the timestamp (although the field is twice as wide as it needs to be).

81.187.162.109 (talk) 07:05, 17 May 2009 (UTC)

LustreOne (talk) 08:51, 4 March 2010 (UTC)

ext4 (with 256-byte or larger inodes) has space for 30-bit nanoseconds, and an extra 2 bits for seconds for each of atime, mtime, ctime, and crtime.

File Change notification

Some filesystem could handle notification following some events

• Linux with inotify (>=2.6.13) Kernel Korner - Intro to inotify or dnotify
• Apple HFS+ (from ?)
• FreeBSD (2000), NetBSD (> Oct. 2002), OpenBSD (> 2.9, Jun 2001) with kqueue kqueue slides
• VxFS with FCL.[1]

(to complete)

For HFS+ under OS X, it dates back to Tiger, and uses kqueues.

This, BTW, is a characteristic of the OS you're using and the OS code for the file system, not of the file system "in the abstract". A given file system might support it on one OS but not on another OS, and a given OS might support it on some file systems but not others. Guy Harris 18:28, 1 December 2006 (UTC)

Agreed, it depends on the functionality of the operating system's virtual file system layer and not the file system itself. -- intgr 19:26, 16 December 2006 (UTC)

Actually, this could be represented on the comparison of operating system kernels article, given a new "virtual file system layer" section. -- intgr 08:10, 4 April 2007 (UTC)

I think that would be an equally bad place for it, because it is dependent on BOTH file system AND kernel. For instance, at least on Windows, support for this feature is implemented as part of the file system driver itself, so not all file systems on Windows would support it. EvanED 01:06, 13 May 2007 (UTC)

Footnotes on comparison page

The comparison of file systems article currently uses the old footnote system, instead of the new (and arguably better) m:Cite.php one (see WP:FOOT). I have already added one <ref></ref>-style footnote. Would anyone be opposed if I started gradually converting footnotes using the old format into the newer one? I realize that while in progress, the conversion could result in confusion, but I think the task is too big to do it all in one run. -- intgr 19:32, 16 December 2006 (UTC)

GPFS / ZFS Limits

Questions about the "Limits" Table...

Question 1: In GPFS, "Maximum Volume Size" says "2^99 bytes". But accordingly to Page2 of http://www.linuxnetworx.com/file_redirect.jsp?siteObjectID=913&fname=GPFSDataSht-web.pdf GPFS supports 2^63-1Bytes. Is the PDF's information incorrect or outdated?

It's outdated. The limits are updated in http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs.doc%2Fgpfs_faqs%2Fgpfsclustersfaq.html 79.169.137.70 (talk) 23:49, 23 November 2010 (UTC)

Question 2: In GPFS, "Maximum File Sise" says "No limit found". But accordingly to Page2 of http://www.almaden.ibm.com/StorageSystems/file_systems/GPFS/Fast02.pdf GPFS supports 2^63-1Bytes. Is the PDF's information incorrect or outdated?

It's outdated. The limits are updated in http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs.doc%2Fgpfs_faqs%2Fgpfsclustersfaq.html 79.169.137.70 (talk) 23:49, 23 November 2010 (UTC)

Question 3: In ZFS, "Maximum Volume Size" says "2^128 bytes". But accordingly to http://en.wikipedia.org/wiki/ZFS#Capacity ZFS supports 16Exbibyte. And *also* accordingly to http://www.opensolaris.org/os/community/zfs/faq/#whatlimits ZFS supports 16Exbibyte. Can someone please clarify this?

Comment was added by Tinho 05:46, 9 January 2007 (UTC).

I don't see a "Limits" table -- where did it go? 69.87.200.105 14:25, 22 January 2007 (UTC)

Tiny files

A column that elaborates on how the filesystem handles tiny file data (of a few bytes, like 5) would be nice. I.e. does it waste an entire sector for it (or worse), does it store it alongside the directory entry (inside the directory "file"), does it store it inside the inode of some other file?

(This doesn't really overlap with "extended attribute", because that's just another tiny file and really, regular tiny files are as interesting) -- dannym 12:12:46, 30 January 2007 (UTC)

This is called tail packing 62.31.67.29 09:49, 29 March 2007 (UTC)

And block suballocation, which is a similar concept. I am unsure about file systems that keep short files with the directory or inode entry. I've heard something vague about NTFS keeping short files in the MFT; if this is true, it indeed isn't represented right now. -- intgr 11:17, 29 March 2007 (UTC)

This is correct. Tail packing and suballocation put multiple files into one block, but that is still discontigous from any other related information, like the inode block or directory listing. By contrast, NTFS stores data for *very* short (I don't have an exact number, but it's in the several hundred bytes region) files in the directory listing, which entirely eliminates a seek for the data. Perhaps a note of this fact in a footnote for the "partial" suballocation support? 76.204.89.43 01:00, 13 May 2007 (UTC)

/ allowed on ext3?

If I recall correctly, the ext3 page reads that the filenames can contain any unicode characters except NUL and /. This page states that only NUL is prohibited. Which one is it? —The preceding unsigned comment was added by B^4 (talk • contribs) 11:08, 18 February 2007 (UTC).

The virtual file system layer is responsible for splitting slashes to directory names, so you cannot normally create files or directories with a slash in their name. However, the low-level file system code normally does not verify file names, so technically, the file system itself does allows names with slashes in them. -- intgr 11:23, 29 March 2007 (UTC)

If it's true this information is probably worth putting in the article. 76.102.230.209 (talk) 03:02, 21 December 2007 (UTC)

The higher level unix layers prohibit nul and / in filenames, so this goes for pretty much all unix filesystems. A foreign filesystem that uses / in filenames would need that character translated when it was being read on a unix system. Some unix filesystem implementations may also be unable to store / in the names, but why check if higher level code already does this? --ssd (talk) 06:00, 14 September 2008 (UTC)

QNX

What about Qnx4fs?? --200.59.172.38 18:17, 12 March 2007 (UTC)

Nobody probably knows enough about it. -- intgr 11:19, 29 March 2007 (UTC)

And yet Fossil is listed with "Unknown" in every column. Guy Macon 13:19, 14 September 2010 (UTC)

Change request for Comparison of Filesystems

Please change the release date of Amiga FFS from 1987 to 1988 and remove the "This article contradicts the article Amiga Fast File System" notice. This is the only contradiction. References for the change were added to the Amiga Fast File System page. 62.31.67.29 09:48, 29 March 2007 (UTC)

Thanks, will fix. Please note that Wikipedia is a wiki, and thus you are invited to make changes yourself. -- intgr 11:18, 29 March 2007 (UTC)

I would love to, but the page is locked. I am not convinced of the merits of registering an account, but that's an argument for some other time. 62.31.67.29 11:29, 29 March 2007 (UTC)

Ahh, okay, that explains it. -- intgr 11:35, 29 March 2007 (UTC)

ZFS sparse files

ZFS supports sparse files, in fact lseek has been enhanced to let programs detect "holes." Here are the words from the blog of the primary architect of ZFS: http://blogs.sun.com/bonwick/date/20051212 —Preceding unsigned comment added by 131.225.136.60 (talk • contribs)

AFS / OpenAFS

I would be eager to read about AFS / OpenAFS in this comparison! Unfortunately I know little about it.--Gaborgulya 12:45, 30 April 2007 (UTC)

AFS is the Andrew File System. It was developed at Carnegie-Mellon University. It was spun-off to a company called Transarc in Pittsburgh. (Ref: http://www.faqs.org/faqs/afs-faq/) Finally, it was acquired and subsequently administered by IBM.

Details about how the software works: www.cs.cmu.edu/afs/andrew.cmu.edu/usr/shadow/www/afs.html

AFS is a robust distributed file system. It's technology was incorporated by the storaage company Spinnaker Networks, also of Pittsburgh. Spinnaker was later acquired by NetApp, allowing for clustered, networked storage. (Ref.: http://www.esj.com/news/article.aspx?EditorialsID=2283)

The Wiki entry for AFS has been expanded, and should be referenced.

208.40.129.196 20:39, 11 June 2007 (UTC)

XFS Limit

According to this pdf http://oss.sgi.com/projects/xfs/training/xfs_slides_02_overview.pdf[2] The XFS have a File System Limit of 18ExB and Files Size Limit of 9 ExB

Anyone can double check? — Preceding unsigned comment added by 192.228.185.184 (talk)

Dunno, I wouldn't except the SGI to be wrong about their own file system. Perhaps it's an implementation-enforced limit under Linux? If so, the footnote would probably need to be expanded. I am not touching it right now as I have zero knowledge of XFS. -- intgr 19:52, 4 May 2007 (UTC)

It could simply be the fact that 18EB and 9EB are the largest values that can fit into 64-bit unsigned and signed binary integers (respectively). If that's all that the FS allocates for each file length, then that's a hard limit (whether or not files can actually be that large). I would expect the actual limit (based on block size, allocation tables, etc.) to be much smaller. — Loadmaster 20:35, 4 May 2007 (UTC)

This page is protected, please someone to add : fr:Comparaison des systèmes de fichiers

As I worte, please someone to add the fr: page, thank you. "Comparaison des systèmes de fichiers" —The preceding unsigned comment was added by 82.228.207.5 (talk) 13:46, 8 May 2007 (UTC).

This page is protected, please someone to add : ((fr:Comparaison des systèmes de fichiers))

As I worte, please someone to add the fr: page, thank you. "fr:Comparaison des systèmes de fichiers" —The preceding unsigned comment was added by 82.228.207.5 (talk) 13:48, 8 May 2007 (UTC).

Sorting in the tables

In the "Limits" table, if you sort by size (ascending), "1 EiB" will come before "1 GiB". I understand why it does this, but is it possible to fix it? --Ysangkok 15:29, 16 May 2007 (UTC)

FAT16 size limit

• The comparison and fat articles list the maximum size of the filesystem as 4 GB. Technically the filesystem can be 8 GB with a 128k cluster size, but msdos would refuse to format with cluster sizes larger than 32k, and Windows NT would refuse to go larger than 64k. Not sure what, if any, systems actually can use an 8 gig 128k cluster size filesystem, but I bet Linux and NT will.

• There is a hard limit to 64kb clusters, because the boot sector stores the number of 512 byte sectors per cluster in an 8 bit number. 32kb clusters are probably much more portable because any operating system that interprets the number as a signed byte will not be able to deal with 64kb (128 sector) clusters. —Preceding unsigned comment added by 195.212.29.171 (talk) 16:11, 14 December 2007 (UTC)

• I have created and used FAT 4GB partitions under NT 4.0, hence the limit of 2GB that appears on the page is only correct for DOS/9x. —Preceding unsigned comment added by 87.194.66.93 (talk) 12:58, 7 May 2008 (UTC)

XIP

• This article lists Execute in place as a feature which some filesystems support, and others do not. XIP is not a feature of the filesystem itself, but rather an optimization employed by the kernel and filesystem driver when accessing the filesystem.

• Not all file systems are designed such that XIP is possible, however. I suppose this is what the column is alluding to. —Preceding unsigned comment added by 149.170.191.232 (talk) 12:23, 30 April 2008 (UTC)

• yeah i just dropped thru to mention that this column is pretty useless (and also to suggest addition of Transactional support (eg: transactional ntfs). cbf doing the research on other fs tho... —Preceding unsigned comment added by 150.101.232.226 (talk) 02:08, 31 March 2009 (UTC)

FATX maximum volume size

I don't know what the actual number is, but 2GiB is clearly wrong. Straight from the factory, Xboxes have a nearly 5GiB FATX volume and many of us run upgraded hard drives with volumes well over 200GiB Sean 16:17, 1 June 2007 (UTC)

According to Xbox linux project wiki at http://www.xbox-linux.org/wiki/Xbox_Partitioning_and_Filesystem_Details, cluster size is fixed at 32 sectors, or 16KB. Using 32-bit clusters (FATX32) then allows for an approximate maximum partition size of 16KB * 4G = 64TB. Approximate because it's ignoring overhead from the actual FAT itself as well as any directory entries. 24.215.34.209 00:35, 7 June 2007 (UTC)

It's been a while since I looked at XBox hard disks, but isn't there a mix of FATX16 and FATX32 on there from the factory? Some smaller partitions with FTAX16 for game saves and updates, and then the bigger FATX32 ones for caching and music. That's what I seem to remember anyway Supertin (talk) 23:55, 26 January 2008 (UTC)

request to add a "tansactions" column in "features" table

Please add a column in "features" table: "support for transactions". NTFS on Vista supports file transactions: the transaction will guarantee that all changes happen, or none of them do, and it will guarantee that applications outside the transaction will not see the changes until the precise instant they're committed. see NTFS and Transactional NTFS article on MSDN: ( http://msdn2.microsoft.com/en-us/library/aa363764.aspx ).

Disk Operating Systems

Unless un/same-named filesystems of OSs are strictly forbidden from being listed such as many of the older Disk Operating Systems were, they have just as much merit being listed here. These file systems are described at the relevant Wikipedia links such as ProDOS 8 Technical Reference Manual and at DOS 3.3, ProDOS & Beyond NuShrike 23:15, 11 June 2007 (UTC)

Sorry, removing those was my fault; I wasn't aware that these names were also used for describing the file systems of these OSes. I've added comments to the article to avoid further confusion. -- intgr ^#%@! 23:26, 11 June 2007 (UTC)

Added Dos 3.x and ProDOS info. AppleWin Developer, Michael.Pohoreski (talk) 19:30, 2 November 2009 (UTC)

FS size changing

I miss information about ability to online/offline size changes. Info on online/offline deframentation would also be usefull. 147.32.126.179 00:16, 23 June 2007 (UTC)

StorNext File System

Even if it is a propriety file system: what about mentioning Quantum's StorNext file system? I think I can come up with an article here soon. --213.70.66.154 15:30, 1 August 2007 (UTC)

UDF file size limit

Who did add the extremely huge file size limit?

AFAIK, UDF does not support single files > ~ 200 GB (depending on the amount of meta data in the directory entry). This is because a songle directory entry may not be bigger than a sector (2048 Bytes). 84.190.254.74 19:33, 10 August 2007 (UTC)

I have no idea what you're referring to. I see no such limit that could confine the file size to a single sector. The file size information is a 64 bit value, and the extent descriptions can be stored in multiple sectors, so there is no limit to them. tempel 10:33, 11 March 2008 (UTC)

JFS history

A quote from http://www.osnews.com/story.php/69/Interview-With-the-People-Behind-JFS-ReiserFS-and-XFS :

Steve Best: The JFS for Linux is a port from OS/2 and has an OS/2 compatibility option. The OS/2 source was also used for the JFS2 just release on AIX 5L. There is a JFS1 on AIX and we didn't use this source base, since the OS/2 source base was a new "ground-up" scalable design started in 1995. The design goals were to use the proven Journaling File System technology that we had developed for 10+ years in AIX and expand on that in the following areas: Performance, Robustness, and SMP support. Some of the team members for the original JFS designed/developed this File System. So this source base for JFS for Linux is now on the following other Operating Systems: OS/2 Warp Server for e-business 4/99, OS/2 Warp Client (fixpack 10/00), AIX 5L called JFS2 4/01 —Preceding unsigned comment added by Maxal (talk • contribs) 16:09, 10 September 2007 (UTC)

Odd...

on Firefox (Macintosh version 2.0.0.6), the interlang list at the top of this page repeats like wild and never stops, and apparently has done in all versions in the history accessible. (2.0.0.7 only "announced itself" as I write this comment (!!!), and I'm about to switch to a new computer in the next few days. But I don't know if any mismatched brackets, etc. on this page - if any - will be ignored by the newer version. I am able to edit by setting my preferences to remove the preview-before-edit-box, of course, but I can't seem to tell what's wrong.) Schissel | Sound the Note! 19:50, 25 September 2007 (UTC)

NTFS compression and tail packing

Isn't NTFS's compression also logical-block based? Then, like ZFS, it should also automatically behave much like tail-packing for the last block of a file. —Preceding unsigned comment added by 221.128.180.177 (talk) 21:38, 4 October 2007 (UTC)

Not quite - NTFS compression operates on individual 64K clusters (actually 16 clusters of whatever size, 4K being by far the most common since it's the maximum supported), and the final mega-cluster only allocates as many regular clusters as necessary. If that's one byte over the 4K limit, you still waste a full 4K cluster, same as any other file. Foxyshadis^(talk) 09:20, 10 December 2011 (UTC)

File systems without fragmentation

How to indicate in the table file systems that do not allow file fragmenting?--Dojarca 18:51, 8 October 2007 (UTC)

CP/M

Can anybody please add information on this: [3] --Dojarca 14:32, 9 October 2007 (UTC)

Tail packing / Block suballocation

As these features point to the same article (Block_suballocation being a redirection of Tail_packing), these columns should probably be merged together. Hovewer, the columns sometimes have different values for the same file system. This should be reviewed.

--Pallinger 17:13, 12 November 2007 (UTC)

Maximum filesize for NTFS=16 EiB??? = maximum volume size? != what's said in article about NTFS

Mmh, I was amazed about the maximum filesize in NTFS: 16 EiB!!! The article about NTFS however states a maximum filesize of 2 TiB.

Which is correct?

Is it normal that maximum filesize=maximum volume size=16 EiB? —Preceding unsigned comment added by Zoidberg (talk • contribs) 08:51, 15 November 2007 (UTC)

The NTFS article also states a different max volume size: 256 TiB minus 64. Zoidberg 08:56, 15 November 2007 (UTC)

Just guessing: The NTFS _format_ may store the information in 64 bit values, allowing sizes of up to 16 EiB. But maybe the _software_ in Windows can't currently handle such large files for some reason. Same is true for HFS Plus - see the note there that explains the difference between the format and the OS limits. tempel 10:36, 11 March 2008 (UTC)

missing table?

What do you think: shouln't there be a table showing which filesystems are supported by which operating systems (and maybe the state like read-only, read-write, full, partially, beta, natively, with additional tools, ...)?

I think this would be useful for answering questions like "Can i read that data with my OS?" or "Which fs should i choose if i want to give all of my 16 multibooted OS access to?" :-)

I think it would be nice to see a table that explains things in English. The tables are really complex. It would be nice to have a table that lists the filesystems and explains the usage that they were designed for. --Mozkill (talk) 22:44, 28 August 2009 (UTC)

--79.200.12.6 (talk) 16:16, 28 November 2007 (UTC)

license information

Perhaps this has been discussed elsewhere, but I would like to see a tabulation of licenses on this page. Briefly: 'GPL' 'CDDL' or even the catch-all, dismissive 'proprietary'. 24.245.3.7 (talk) 07:09, 19 January 2008 (UTC)

Btrfs?

What about Btrfs? http://oss.oracle.com/projects/btrfs/ —Preceding unsigned comment added by 78.42.31.136 (talk) 00:05, 6 February 2008 (UTC)

• Looks like it's mentioned now, but not in any of the comparisons. Can someone in the know complete the other tables? --Nil0lab (talk) 19:11, 3 April 2009 (UTC)

Minix and ext2+3 support on NTFS

The last graph (OS Support) lists Minix even though the column is completely empty (and as far as I know, no one seriously uses Minix). I'm removing that column because it's pointless.

Also adding Yes for ext2 and ext3 on Windows with link to http://www.fs-driver.org/ —Preceding unsigned comment added by 24.9.122.110 (talk) 02:35, 13 March 2008 (UTC)

Any filesystem can be supported by any operating system if there is a third party tool for it. So you can't just say "yes". But it can niether be ignored. So I propose a state in the middle: "third party or external support" which means that the support is not in the original Operating System Or Kernel shipped by the Organization responsible, though the support can be included by using a third party driver or software. —Preceding unsigned comment added by 122.167.20.0 (talk) 17:35, 13 May 2008 (UTC)

Just read the edit page and it says "Don't delete columns because they are empty". I'm going to leave the Minix column alone because of this, but I think it should removed. —Preceding unsigned comment added by 24.9.122.110 (talk) 02:38, 13 March 2008 (UTC)

NTFS features

I find many of the points on NTFS features to be misleading, since NTFS is actually a variety of file systems, all called NTFS. Most of the features of NTFS mentioned here are actually not available on most common systems like Windows XP. There should be some way to distinguish them.--89.212.75.6 (talk) 02:45, 6 April 2008 (UTC)

I agree. And what's particularly disturbing is that NTFS is shown to support extents - but that is not consistent with the wiki article on extents: http://en.wikipedia.org/wiki/Extent_%28file_systems%29 NTFS was originally regarded to support extents, but that was later revised. It should be revised on this page as well. --May 8, 2008

Fossil (arguably) does support sparse files

Fossil is a bit tricky to characterize this way, because it's not so much a filesystem in itself as a write buffer for the Venti backing store, but I think it should be considered to support sparse files, since Venti does avoid storing zero bytes (see Zero Truncation in the venti(7) manual page). Dzlk (talk) 01:32, 3 May 2008 (UTC)

ext4 limits contradict ext4 article and Sandees interview

The ext4 entry says that the file size limit is 1EiB, contrary to what is written in the Limits table.

Moreover, the Sandees interview cited in this note states that the file system size is dependent on block size, contrary to what is written both in this articel and in ext4. Fpoto (talk) 11:44, 14 May 2008 (UTC)

Sorting

When sorting the filesystems by FILE SIZE or VOLUME SIZE it sorts normally causing filesystems with larger numbers (16 KB) to come before smaller numbers (2 MB) regardless of the fact that 2 MB should come before 16 KB. Matt 75.57.128.57 (talk) 20:54, 15 May 2008 (UTC)

I'm not familiar with MediaWiki's tables, so can't suggest an answer; I can only ask if someone knows how to clue the system in on the sort so that it goes by size rather than alphabetical content. --137.222.28.121 (talk) 13:36, 22 July 2009 (UTC)

Murders your wife

So why is this crap still in? It may be funny for geeks but it is not funny for many others. It isnt even a technical term. Why dont you guys just remove this useless line? And why is there no discussion about it? 80.108.103.172 (talk) 14:28, 9 June 2008 (UTC)

It isn't. You are looking at a specific version from the history, which is specified in the link you followed from Slashdot. -- Mark J (talk) 15:14, 9 June 2008 (UTC)

Gave me a good laugh though. :) 121.45.149.55 (talk) 21:58, 9 June 2008 (UTC)

I hereby nominate this edit for some sort of Wikipedia black-humor prize. Please direct us to the correct page for that... Atario (talk) 00:38, 10 June 2008 (UTC)

I believe this is what you're looking for. --WayneMokane (talk) 16:20, 14 July 2008 (UTC)

While "murders your wife" is of course not technically correct way to express it, I don't really think that it's significance is just "fun for geeks". At the very least, it means the filesystem is no longer seeking economic viability, which is a very important change. Perhaps there should be another way to express this significance? —Preceding unsigned comment added by 138.253.184.200 (talk) 12:41, 12 June 2008 (UTC)

BTW, a version with this "misfeature" is [4]. Vrmlguy (talk) 12:45, 13 June 2008 (UTC)

The only problem is, now, the current page does not give you any way to know if a particular file system will murder your wife. SteubenGlass (talk) 21:44, 8 July 2008 (UTC)

I feel a lot of people would very much like to know if Reiser4 will murder their wives. This could be the start of a whole new ad campaign, "The Cutting Edge in Filesystems, Now Cutting Up Your Wife." I don't even know what it does and I'd buy it. Hell if only Vista could shut my neighbors up.Cpesacreta (talk) 19:26, 9 July 2008 (UTC)

I don't get it.

Hilarious though it is, it looks like people are going to keep adding variations on it for a while now that the news update has come through. Maybe lock the page for a day or so?60.242.240.24 (talk) 05:17, 8 July 2008 (UTC)

Hilarious, indeed. -Avitor (talk) 16:09, 9 July 2008 (UTC)

I don't get it. :| --90.201.31.70 (talk) 16:46, 9 July 2008 (UTC)

Gee, I wish there was some kind of website, a virtual encyclopedia perhaps, that might help you figure it out! 17.214.83.105 (talk) 16:52, 9 July 2008 (UTC)

Gosh I hope this becomes an Internet Meme. (talk) 18:04, 9 July 2008 (UTC) —Preceding unsigned comment added by 68.161.116.238 (talk)

What do you mean? What's going on. Just for fun I typed in http://en.wikipedia.org/wiki/Talk:Comparison_of_file_systems to see if anything was here and low and behold there was. -- Suso (talk) 17:33, 9 July 2008 (UTC)

This made it to Digg: Flickr: Reiser4 kills your wife. Just an FYI. 24.15.182.247 (talk) 23:26, 9 July 2008 (UTC)

And to The Reg. —Preceding unsigned comment added by Ralphbk (talk • contribs) 09:35, 10 July 2008 (UTC)

Can we be sure that other filesystems have not been created or worked on by wife-murderers? If I'm going to switch filesystems away to more spouse-friendly ones, I sure want to have my facts straight --75.154.181.167 (talk) 09:12, 10 July 2008 (UTC)

Great. My wife is dead, and then I come here and see this. If this article mentioned which filesystems are wife murderers she would be with us right now. This could have been avoided. Thanks a lot guys. Wisgary (talk) 11:54, 10 July 2008 (UTC)

Why are you taking it so seriously? The joy of an editable encyclopedia is to have a bit of a laugh around partially verified hearsay. wiki (talk) 14:48, 10 July 2008 (UTC)

Maybe because it's an... encyclopedia? I think it's supposed to be serious. What if everyone started adding "jokes" to other entries? - MB. 17:06, 10 July 2008 (UTC) —Preceding unsigned comment added by 151.56.80.7 (talk)

Um, Don't know about you guys but I think this is a very serious matter. We all should know if a particular file system will murder your wife or not. It may or may not be a desirable feature. —Preceding unsigned comment added by 72.35.126.207 (talk) 03:03, 12 July 2008 (UTC)

I chose ReiserFS precisely BECAUSE... never mind! —Preceding unsigned comment added by 208.65.73.103 (talk) 13:25, 17 July 2008 (UTC)

Then this would just be ED. I see no problem here. —Preceding unsigned comment added by 75.177.116.134 (talk) 01:04, 14 July 2008 (UTC)

Call it a joke, but the main programmer of Reiser really kills his wife and is in jail for something like 20 years for that, not so funny ... —Preceding unsigned comment added by 81.220.158.193 (talk) 13:06, 5 January 2009 (UTC)

NTFS (and ext2/3) on linux and on mac os

From what I know the Paragon package is for Mac OS X not Mac OS - http://paragondotcom.com/home/ntfs-mac/ .
Also NTFS can also be used on linux with ntfsprogs - http://www.linux-ntfs.org and Paragon NTFS for linux - http://www.ntfs-linux.com/ .
Paragon also seams to offer a lot of other drivers for many platforms - http://www.paragon-software.com/home/file_system_drivers.html 79.116.248.179 (talk) 19:29, 20 June 2008 (UTC) Alex Voda

It's also worth pointing out that full support for ext2/3 incl. journal writing is provided for Mac OS X by a driver available from Paragon Software. Pity that so much useful info is on this talk page that never seems to find its way into the actual page. How comes? Rcfa (talk) 14:05, 11 March 2009 (UTC)

Agreed. Added ntfsprogs to NTFS on Linux. I'm afraid I don't know enough to add anything further at the moment. Laned130 (talk) 13:28, 14 January 2011 (UTC)

Meta Data columns

Please delete "This copy created" column in the meta data table, if all file systems have a ? or no.

What is the "this copy created" column? The other columns mostly make sense to me. Ltwizard (talk) 08:34, 2 January 2009 (UTC)

If it's "creation time", it's redundant. Guy Harris (talk) 04:53, 16 January 2010 (UTC)

Mac OS Extended vs. HFS+

"Mac OS Extended" -- Idiotic question (Sorry I don't know how to use WikiPedia better)... Why doesn't the phrase "Mac OS Extended" appear anywhere on this page? On a modern Mac, "Mac OS Extended" is what the operating system reports its using, and when formatting disks, that's what it's called. Is that the same as HFS+? If so, that should be stated somewhere. There's "Mac OS Extended (Journaled)", "Mac OS Extended (Case-Sensitive)", etc. Could at least the main phrase appear somewhere on the page? —Preceding unsigned comment added by 75.69.117.140 (talk) 07:54, 8 July 2008 (UTC)

OK, I guess it is. http://en.wikipedia.org/wiki/HFS_Plus But that phrase/explanation should still appear on the page, at least as a footnote explaining it's also called HFS+. —Preceding unsigned comment added by 75.69.117.140 (talk) 07:56, 8 July 2008 (UTC)

Semi-protected

I've semi-protected this page for five days, to deal with the current resurgence of Reiser-related vandalism. -- The Anome (talk) 11:17, 8 July 2008 (UTC)

Digg effect :) Carlosguitar ^{(Yes Executor?)} 18:38, 9 July 2008 (UTC)

Snap shot link

title for the column about support of snapshotting should just link to the correct article, "Snapshot (computer storage)", would fix my self, but silly vandals.LovesTha (talk) 02:45, 10 July 2008 (UTC)

Vandalism side-effect not yet corrected

Revision 224280683 revoked some vandalism but failed to restore legit changes that the vandalism had also undone. See http://en.wikipedia.org/w/index.php?title=Comparison_of_file_systems&diff=224280683&oldid=223944801 for the content that was remove by the partial restoration.

I cannot correct this myself because the article is locked. Olaf Jan (talk) —Preceding comment was added at 21:16, 11 July 2008 (UTC)

It all seems to have been corrected at some point. Guy Harris (talk) 19:29, 16 January 2010 (UTC)

Solaris does not support Lustre

Solaris doesn't support Lustre and incorrectly has a Yes box. See Sun's own page or Wikipedia's page. Aolcarton (talk) 17:59, 22 July 2008 (UTC)

NTFS Limits

The Limits section on NTFS states "Allowable characters in directory entries" are "Any Unicode except NUL, /". I believe this is incorrect. As stated in the Microsoft Naming a File page (http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx), it clearly states

That almost any character is supported, except for the following:

• The following reserved characters are not allowed:

     < > : " / \ | ? *

• Characters whose integer representations are in the range from zero through 31 are not allowed.

• Any other character that the target file system does not allow.

We discovered this limitation while backing up files from an HFS+ file system to an NTFS 6.0 file system. The HFS+ system had a carriage return (decimal value 13) embedded in the file name.

--Jamercee (talk) 20:56, 17 August 2008 (UTC)

The wikipedia article on NTFS states that "Allowed characters in filenames" in "Posix namespace" is "any UTF-16 code unit (case sensitive) except U+0000 (NUL) and / (slash)" and we are here to compare Filesystem so we must not care of Win32 limitations.

-- 14:18, 29 September 2008 (UTC) —Preceding unsigned comment added by 82.67.232.57 (talk)

I don't think I was clear in my original assertion. While copying files from an HFS+ filesystem to an NTFS filesystem we discovered that carriage return characters were NOT allowed while writting to the NTFS file system. Clearly Carriage-Return characters should have fallen within the range "Any Unicode except NUL, /". It would seem the limitation section should be expanded to encompass the true list of liminations, no?

Jamercee (talk) 20:05, 30 March 2010 (UTC)

Looks like youre confusing what your OS or software app allows with what NTFS allows 82.31.207.100 (talk) 23:25, 20 April 2010 (UTC)

Another limits that seems to be wrong (in contrast to page on ntfs and info on ntfs.com): max. filename length is 255 UTF16 code-points, not 226. Is this a limit yhat evolved over time in different NTFS versions? 82.247.156.143 (talk) 08:36, 6 July 2010 (UTC)

Also just mentioning in passing that Windows XP (presumably NT also) imposes a limit of 259 characters on the full path name but I'm not sure if that is a limitation imposed by NTFS or not.150.101.105.182 (talk) 04:24, 2 September 2010 (UTC)

UFS2 and Block Journaling Support

Please provide reference for UFS2's support of block journaling. I cannot find one.

Moniker117 (talk) 22:19, 28 September 2008 (UTC)

I've been looking around and here's some updates:

• Solaris has support for "logging" using UFS. They introduced it in version 7 of Solaris. This is consistent with what the UFS article in wikipedia says regarding UFS and journaling. This type of journaling is, however, meta-data journaling. Below is a link that confirms the existance of such functionality:

http://docs.sun.com/app/docs/doc/817-5093/fsoverview-43?l=en&a=view&q=ufs+logging

• FreeBSD implements a form of what their documentation calls "block level" journaling through GEOM. This appears to be a feature that is available with UFS or UFS2. Below is a link describing the functionality:

http://www.freebsd.org/doc/en/books/handbook/geom-gjournal.html

• OpenBSD does not implement any form of journaling. See below for link:

http://www.openbsd.org/faq/faq8.html#Journaling

• HP-UX appears to use HFS which is an implementation of UFS and they have a separate file system for journaling support from Veritas. See link below:

http://docs.hp.com/en/B2355-90950/ch02s05.html

I do not doubt that I am missing more operating systems. However, based on the above list, Solaris, FreeBSD, OpenBSD and HP-UX appear to use UFS, but only FreeBSD has data level journaling support. I did not expect one file system to have such variation on one particular feature. It seems fair to me that it should read "No" for both "block journaling" and "meta-data only journaling" under both UFS and UFS2 while having a comment to indicate that certain operating systems implement different levels of journaling support. Any thoughts?

Moniker117 (talk) 04:09, 1 October 2008 (UTC)

Correction on FreeBSD, the GEOM implementation of journaling appears to be filesystem independent. Therefore, it is not a UFS or UFS2 feature.

Moniker117 (talk) 14:36, 1 October 2008 (UTC)

Correction: FreeBSD's gjournal(4) requires filesystem support (transactions) in order to provide the safety guarantees for which journaling is desired; this is implemented in UFS2. (UFS1 is not distinct from UFS2 in this sense: it is the same code, just a different on-disk format. So UFS1 "supports" journaling by default.) 121a0012 (talk) 03:06, 2 October 2008 (UTC)

NetBSD offers journaling on FFSv2 (UFS2) in recent kernels compiled with options WAPBL; mount FFSv2 volumes with the 'log' option to use this feature. —Preceding unsigned comment added by 84.83.37.40 (talk) 03:19, 6 November 2008 (UTC)

Guys, journalling is a feature of filesystem _implementation_, while UFS has many of them. Solaris UFS has journalling. Other UFS implementations don't, except for FreeBSD and NetBSD ones, which seem to be done independently to each other. So, it is unclear whether we can say that UFS implements journalling.

However, UFS2 tends to refer to the current FreeBSD implementation of UFS, which definitely has journalling. Trasz (talk) 12:29, 3 January 2009 (UTC)

Incidentally, the UFS logging in Solaris starts a long time before Solaris 7. In it's original incarnation, it required Disksuite and the logging was on to separate logging devices called trans meta logging. By Solaris 7, the log devices became invisible log files within the filesystem, and it was being bundled for free with the base OS, so it started being more widely known. 81.187.162.109 (talk) 06:39, 17 May 2009 (UTC)

HFS+ Online Shrink/Grow

Online shrink/grow for HFS+ are currently listed as "unknown". The Boot Camp Assistant allows shrinking (when you create a Windows partition) and growing (when you delete one) of the running system's HFS+ partition. I don't know whether this is implemented in the FS driver or if it's a hack implemented somehow else... 24.60.192.190 (talk) 23:12, 23 January 2009 (UTC)

Mistakes about ReiserFS?

The two tables for Metadata and Features, ReiserFS (which I assume is of the version 3) has none of the discussed properties ('No' for every single item). While I am no expert in file systems and ReiserFS in specific, this seems to be contradicting the page of ReiserFS, which states that one of the most publicised features of ReiserFS is "Metadata-only journalling". This suggests ReiserFS should have the minimal metadata for the purpose of system journalling. Besides, the table Features should otherwise have at least the Metadata journalling set to 'Yes' for ReiserFS. I have also checked earlier versions of this page (beginning of this year), and found that the tables were indicating many different properties for ReiserFS.

Obviously, vandalism has happened to this page recently. The maintainer of this page please restore the page to the proper state. It is much appreciated. 125.253.12.53 (talk) 14:34, 22 February 2009 (UTC)

The page about Extended attribute does state that ReiserFS, at least in recent versions, does feature xattr / metadata support! —Preceding unsigned comment added by Zuckerberg (talk • contribs) 13:17, 2 September 2010 (UTC)

http://linux.die.net/man/8/mount states that ACLs are supported in reiserfs. –84.169.112.96 (talk) 22:57, 26 January 2012 (UTC)

There is also the text “Full block journaling for ReiserFS was not added to Linux 2.6.8 for obvious reasons.” To me, the reasons are not obvious. That should be expanded upon, or some reference given. –84.169.112.96 (talk) 23:04, 26 January 2012 (UTC)

Include WinFS?

I was just reading about WinFS on it's own WikiPedia page, and was wondering how it compared to all these other file systems. It's not here. Oh well. I think it would be nice to have here. 71.174.4.229 (talk) 20:41, 7 June 2009 (UTC)

NTFS for windows 98 driver?

The link given is broken, does anyone have a backup for the driver that allows NTFS to be used with Windows 95/98? I could really use it. Coolgamer (talk) 03:43, 12 August 2009 (UTC)

NTFS 6.0

There does not exist any NTFS 6.0 ! There are only system extentions of Windows NT 6.0 (Vista/2008) but inside the specifications of the current NTFS 3.1

Deduplication

I've added a new column to the features table to cover deduplication. I've filled in what I know of existing or being in development, but this leaves a lot of unknown entries. I suspect that all of the unknown's are really no but I don't have the knowledge to say for sure. Darrenmoffat (talk) 11:38, 24 September 2009 (UTC)

Suggested Updates/Todos

I've Added/Updated Tables 1 and 2 for exFAT and TexFAT. But these 2 FS types should be added to tables:

• 3 Metadata
• 4 Features
• 5 Allocation and layout policies
• 6 OS support

Also Table 6 OS Support Needs Windows XP, Vista and Windows 7 break out (maybe in the same column?) Frankk74 (talk) 06:52, 14 October 2009 (UTC)

Sorting across the tables should be refined or made more consistent? Any thoughts?

Info about XP, Vista, and Win7 would be nice... It has been many since NT stopped being supported. 72.251.91.186 (talk) 02:43, 22 October 2009 (UTC)

Windows NT refers to the entire family of NT OSes; Microsoft decided to call NT 5.0 "Windows 2000", and all subsequent Windows NT OSes have had names that don't start with "Windows NT", such as "Windows XP", "Windows Vista", "Windows 7", "Windows Server 2003", "Windows Server 2008", etc.. Guy Harris (talk) 19:51, 17 January 2010 (UTC)

File Creation Time Stamps

Why there is "NO" for ReiserFS & Ext? for File Creation Time Stamps? I feel that this article is worthless since it contains obviously erroneous information. Might someone fix that or delete the article? --82.113.121.154 (talk) 21:00, 28 November 2009 (UTC)

My understanding is that these do not give you file creation time stamps. Instead you get the last inode update timestamp. Initially this corresponds to the creation time, but later changes (such as to file metadata) may change that timestamp, without modifying the underlying file data. —Preceding unsigned comment added by 216.105.130.254 (talk) 05:33, 28 July 2010 (UTC)

Market share

It would be interesting to have some comparison of market share or some other usage statistic, either here or on file system. -- Beland (talk) 14:29, 1 December 2009 (UTC)

It might, indeed. However, as file systems are hardly ‘products’ in the original sense (more like an abstract design), then the concept of ‘market’ is difficult to apply. This would be like having ‘market share’ for natural languages, as such. How would such data be collected, anyway? You've then got statistical analysis problems; for example: how should someone using multiple file systems be counted? They're not mutually exclusive, via partitioning. — Lee Carré (talk) 13:54, 27 December 2010 (UTC)

OS support

I feel that this table would be much more useful if it did not list any filesystems until they are supported by more than one OS. After all, while long list of special purpose linux filesystems is interesting, it seems like it perhaps defeats the purpose of this table? Why not focus on Cross-OS support, perhaps even labeling it such instead? —Preceding unsigned comment added by 66.162.99.237 (talk) 19:15, 29 December 2009 (UTC)

UFS2 limits

According to http://www.freebsd.org/projects/bigdisk/index.html, UFS2 file and volume limit is 2^73, not a "Yobibyte". --Eike sauer (talk) 08:56, 30 March 2010 (UTC)

Units for bytes

I just noticed this article uses lot of IEC prefixes such as EiB but WP:MOSNUM states the IEC prefixes are not to be used except in a few conditions that are not met by this article. I think changing the article to use familiar prefixes would be an improvement. 217.213.60.238 (talk) 18:47, 30 March 2010 (UTC)

It looks like the relevant bit of the MoS is specifically WP:COMPUNITS.

Currently the "Limits" section uses KB, MB, GB, TB, PB, EB, ZB, and YB. Some entries define them more precisely (usually x * 1024^n bytes), but many don't. In general these limits are derived from binary values, so perhaps there should be a note covering the whole table to say this. My opinion is that KB is confusing (though probably correct), MB and GB are definitely ambiguous, and TB and so on are actually incorrect, at least according to the JEDEC prefixes listed in Template:Bit and byte prefixes.

For example I was looking for information on UDF. The table says the maximum file size is 16 EB, and I think this is derived from 64-bit file sizes: 2^64 = 16 EiB. The table says "unknown" for UDF's maximum volume size, though I think I saw elsewhere it is 2^32 * (block size), which would be 2 TiB = 2^(32 + 9) for 512 B block hard disks and 8 TiB = 2^(32 + 11) for 2048 B block optical discs.

Personally I think TiB is generally more clear, and in this particular situation makes it clear that it's a different unit to the decimal TB commonly used for hard disks. For example it might avoid suggesting that a 2 TiB file system and a 2 TB hard disk are exactly the same size. But maybe I'm just being too technical, and there's a sentence in the MoS that says don't use the IEC units anyway.

Vadmium (talk) 02:32, 17 December 2010 (UTC)

As per the MOS I have changed the article to reflect the current consensus. HumphreyW (talk) 12:43, 15 December 2011 (UTC)

V6FS Max Size

This may sound random, but Wikipedia led me astray on my home work and I should try to prevent it for others. The given max size in: "The actual maximum was 8,847,360 bytes, with 7 singly-indirect blocks and 1 doubly-indirect block; PWB/UNIX 1.0's variant had 8 singly-indirect blocks, making the maximum 524,288 bytes or half a MiB." is incorrect. According to the Version 6 Manual, http://wwwlehre.dhbw-stuttgart.de/~helbig/os/v6/doc/V/fs.html, the max size is 32, but cannot be larger than 16 bue to only storing 24-bits of filesize info in each inode rather than 25. The 8,847,360 number obtained above was the result of calculating it with 4 byte addresses, which is obviously incorrect given the definition in the manual. Vkgfx (talk) 06:00, 7 April 2010 (UTC)

CoLinux

CoLinux is a port of the linux kernel. It allows running Linux natively under Windows. Therefore it is possible to use XFS, ReiserFS and ext3 in Windows as described here. Maybe this is mentionable? --Olytibar (talk) 05:42, 30 June 2010 (UTC)

Windows already has the ability to use XFS, ext3, etc. if by "use" you mean "connect to a linux box on the network that is running Samba" CoLinux makes it possible for that Linux box to be the same box that is running Windows, but it is still accessing a network share. We don't count as being supported filesystems that are accessible by connecting to an OS running on a virtual machine, so we shouldn't count them under CoLinux.

It might be worthwhile mentioning in the article that support for non-native partitions is often available through these methods. That is very useful information for someone who doesn't know the trick. Guy Macon 13:24, 19 September 2010 (UTC)

Why Isn't There More Information On Amiga OS?!

I am going to add more information on Amiga OS. It has information on the first table but none on the others. If anybody has objections to this, post them here and soon. In-Correct (talk) 00:05, 12 July 2010 (UTC)

GEORGE 2 & GEORGE 3

I notice that "George 2" appears as a file system, though without any reference or link. I don't know anything about GEORGE 2 but I did use GEORGE 3 and so I know that its filestore was very significant, having automatic volume management with backups, versioning etc. Were these the same filesystem or not? The GEORGE 3 one should certainly appear in the table, IMHO.

There is a wikipedia entry about GEORGE - GEORGE_(operating_system) - that refers to online GEORGE 3 documentation including a description of the filestore http://www.icl1900.co.uk/g3/filestor.html 131.111.85.79 (talk) 09:40, 1 September 2010 (UTC)

Modern System Only Option

Many people coming to the page are only interested in comparing current Files Systems to decide which to use. However, because all of the comparison tables are multiple screens long and compare every file system that has existed, they find the page to be mostly useless. We need a way to show only current information for those who want it, in order to increase utility. A method for allowing the viewer to sort information and suppress what they don't need would also be good.

This is a general comment applicable to all comparison articles. —Preceding unsigned comment added by 136.142.206.28 (talk) 22:40, 15 October 2010 (UTC)

Original Operating System

The purpose of the field 'Original Operating System' is not clear. I would assume that it applies to the Operating System/s the Filesystem first appeared in. However, the field does not currently appear to reflect this. I have removed some anachronisms ie Windows pre NT (Windows v1 - 3.1 were not operating systems), and Mac OS X pre 1999, Linux pre 1990. There appear to be some other issues, eg Joilet support was not originally present in Mac OS and required an extension to be added, ISO9660 was not included in the Amiga OS until OS3.1 (released about 1992) but was available as a third party add on), XFS was originally IRIX only and then later ported to Linux (and by this logic, virtually all the FS could have Linux listed), and no doubt more. The solution may be to have two fields, one called Original Operating System, and another listing OSes which support the filesystems. 138.25.11.181 (talk) 03:04, 16 October 2010 (UTC)

Maximum file size and Maximum volume size format

Why aren't the values in these two columns in the scientific notation? This way the sorting by each of the columns would work correctly (now it doesn't).

512upload (talk) 22:38, 18 November 2010 (UTC)

-

Still undone - very annoying!!!

iOS (Apple)

What is the maximum file size for Apple iOS, which is used in the iPhone and iPad? I've been trying to find this official fact. • Sbmeirow • Talk • 22:02, 23 December 2010 (UTC)

iOS uses HFSX, which is HFS+ with a few minor tweaks, none of which affect the maximum file size. Foxyshadis^(talk) 09:26, 10 December 2011 (UTC)

Request for extra information about metadata space efficiency (percentage use of drive capacity)

I would, personally, like to see comparison data between the efficiency of differing file systems, particularly in the context of what percentage of the absolute total capacity is needed for file system metadata in order for it to represent the file system itself. For example, a less space-efficient design would use a larger percentage just to store metadata, rather than actual files, and vice versa. I realise that there are often more important factors than pure efficiency; such as discoverability for diagnostics, scalability, reliability, redundancy, et al. Notes on original design goals would be useful, too, if known, such as design for file storage, database, streaming media, sequential vs random access, et al. — Lee Carré (talk) 14:01, 27 December 2010 (UTC)

Most modern filesystems do not use a fixed reservation for filesystem metadata; the number you ask for will depend on the size, structure, and number of files stored, and in many cases also on the modification history, presence of snapshots, use of journaling, stride length, and size of the underlying disk sectors. So what you ask for really cannot be defined rigorously without a precise specification of the contents of the filesystem (and even there, the results would likely not be realistic). For filesystems with integrated volume management, like ZFS, it would also depend on the configuration of the underlying storage pool. 121a0012 (talk) 22:24, 28 December 2010 (UTC)

Feb-2009 vandalism needs stripping out

I was wondering about the {{Contradict-other|File Allocation Table|date=February 2010}} hatnote as there was no talk thread. I tracked the addition of the hatnote down to this massive edit on 16 Feb 2009. A couple of minutes after that edit is this small one by the same user. I took a look at Special:Contributions/Gzpguest and am quite concerned about that user's edit's to this article as he/she was blocked for edits to other articles and some of the user's contribution to this article was clearly an attempt to vandalize it.

I don't know if it was WP:AGF at work or the edits were overlooked. Someone corrected Gzpguest's change of ReiserFS to MurderFS but an edit battle of sorts started with people attempting to re-insert MurderFS wording and it looks like most of the Gzpguest contribution snuck through including the hat note that got my attention today.

I don't have time to do a blow-by-blow check of what Gzpguest modified in those two edits against the current article but believe we need to revert all information that this user added/removed to the article. Hopefully someone's got the time for that thankless task. I'll start by removing the hat note. --Marc Kupper|talk 07:34, 31 December 2010 (UTC)

Allowed characters in NTFS file names

The articles says all Unicode character except NUL and \ / : * ? " < > | are allowed, but in Linux NTFS files can contain any Unicode character except NUL and /. —Preceding unsigned comment added by 193.150.222.25 (talk) 13:49, 20 January 2011 (UTC)

IlesfayFS?

Is it mentioned outside its inventors' site and this page? Notability? 195.98.165.2 (talk) 20:42, 8 February 2011 (UTC)

Remove HPUX

Besides being an essentially dead OS, the column is currently useless, which all unknowns except for one single Yes. If no one objects or fills it in, I'll remove it until someone comes in with better data. Foxyshadis^(talk) 09:27, 10 December 2011 (UTC)

ICT/ICL 1900 file systems

A previous commenter has mentioned the inappropriate inclusion of George 2, which was in fact an operating system. The file system underlying George 2 (and all ICL 1900 executives/operating systems prior to George 3/4) was originally BDAS (Basic Direct Access Standards) and later UDAS (Unified Direct Access Standards). UDAS was noteworthy in providing a standard which meant that applications did not need recompilation, whatever type of direct access device they were accessing, anything from a small Twin EDS (about 1.5 megabytes, as I recall) to a large fixed disk. I am unclear to what extent the George 3 filestore was founded on UDAS, but on balance I think it was. 86.139.4.232 (talk) 20:39, 1 January 2012 (UTC)

ExFAT correction...

Why ExFAT's "year introduced" column has two dates? 2006 and 2009? it makes no sense. It was introduced in 2006 Cainamarques (talk) 02:35, 23 August 2012 (UTC)

Merger proposal

Template:Merge discussion A merger proposal was made by Ruud Koot in January to merge List of file systems into this article but no discussion was started, so in before merging by silence...

Oppose - The differentiation between list and comparison works, they have different scopes so there is no overlap and also the resulting article would be too long Cainamarques (talk) 05:00, 25 August 2012 (UTC)

handling small files

please someone add how well the different file systems are at handling many many small files. i understand that reiserfs is good at this, and jfs is also alright, but that most file systems are not. please add this information. 41.204.77.67 (talk) 09:04, 18 October 2012 (UTC)