Talk:File system/Archive 1

message: The tables show that the Reiser and ext file systems (and others) do not store file creation timestamps. I believe this is not true. A recent discussion on a Linux mailing list turned up the following:
any file on any filesystem has a creation date and time and if necessary, you can "touch file" so it updates the date and
time to now.
# vi abcd
# ls -l abcd
-rw-r--r--  1 root root 9 2005-08-19 12:39 abcd
# touch abcd
# ls -l abcd
-rw-r--r--  1 root root 9 2005-08-19 12:45 abcd
Any comments or thoughts?
Yes,
Creation time is not supported by the standard infrastructure unix/linux supplies for file manipulation.  Without resorting to non-standard extensions you will not specifically find a permanent "creation" time for a file.
This Unix FAQ states:
3.1)  How do I find the creation time of a file?
:You can't - it isn't stored anywhere.  Files have a last-modified
:time (shown by "ls -l"), a last-accessed time (shown by "ls -lu")
:and an inode change time (shown by "ls -lc"). The latter is often
:referred to as the "creation time" - even in some man pages -
:but that's wrong; it's also set by such operations as mv, ln,
:chmod, chown and chgrp.
:The man page for "stat(2)" discusses this.
The aforementioned mailing list discussion appears to have confused the modification time with a creation time. -- Guy Harris 00:44, 22 September 2005 (UTC)
thread_title:  Information about Reiser and ext (and other FSs) not storing creation timestamp? 

message: Question: I know that NTFS internally uses GMT/UTC for
all timestamps, while most other filesystems supported by Windows use
localtime.  I know that most Unix-like platforms do their internal
timekeeping in UTC/GMT.  I do not know how MacOS and other platforms
handle these issues.  Somebody who does know, please edit this table
accordingly, because particularly at times of the year when millions
of people have recently switched between summer and winter local time,
this can make ambiguities when files are copied between partitions
that use universal time and partitions that use local time.
MacOS 9 and earlier operate on localtime, MacOS X uses GMT, HFS uses localtime, and HFS+ uses GMT. From HFS Plus Volume Format,
 Google is your friend. --Martin Rudat(T|@|C) 09:11, 18 February 2006 (UTC)
thread_title:  NTFS and Timestamps 

message: Would it be worth mentioning in the table whether the file system supports journaling all data or just metadata? --Yamla 00:18, 2004 Dec 15 (UTC)
I added it --80.99.61.48 02:53, 11 Apr 2005 (UTC)
thread_title:  Journal types 

message: Novell is tight-lipped when it comes to actual descriptions of the features of their NSS filesystem.  I had to dig around on quite a few different sites to get the data I did.  Anyone with corrections or additions is welcome to add.  Thanks, MARQUIS111 Feb 1, 2005  11:00am EST
The Novel Open Entrerpise Server for Linux beta comes with a linux port of NSS deliver in source form and under GPL.
The code is completely unreadable though, I doubt it'll help you a lot ;-)
I've tried to find a good definition of Block Journaling but cannot find a definitive answer. I assume it means dat both data and metadata are journaled. If that's the case then NSS does not support Block Journaling (current status is '?'). JoetjeF 21:56, 26 August 2005 (UTC)
thread_title:  NSS 

message: I noticed with the last change I saved, that there was a nastygram about the page being ~31k in size, and that something should be done to pare it down before it hits 32k.  Should we split the page into currently-used and not-so-currently used filesystems?
Sample list would look like this (not all-inclusive):
Common file systems
http://en.wikipedia.com/File_system_comparison
* NTFS
* ext2 and 3
* Reiser 3 and 4
* NSS
* FAT32
* OS X UFS
:Rem: HFS+ is much more commonly used on OS X than UFS!
Not-so-common file systems
http://en.wikipedia.com/Not_So_Common_File_system_comparison (I'm only semi-joking)
* HPFS
* NWFS
* ODS5
* BeFS
* FAT12 (floppy use==current, hd use==not current)
I'll probably get shot down for this, but Wikipedia is the one who is complaining about the page size.
Thanks
MARQUIS111, Feb 23, 2005, 12:34pm EST
* No.  Split it by topic, not by filesystem.  (The points to split the table by rows are pretty obvious, since it is split at those points already.  ☺)  We already have a split by columns, effectively, in the individual filesystem articles.  What is important about this article is the rows. Uncle G 00:16, 2005 Feb 24 (UTC)
* Having said that, there are a couple of rows that I have my doubts about, that we could potentially eliminate, to keep the table size down.  There's only one filesystem for which maximum pathname length applies, for example, and I suspect that even that is only because of a misunderstanding.  Similarly, as pointed out before, there's some doubt about Mac OS X UFS actually having a separate identity of its own, which could be addressed. Uncle G 00:16, 2005 Feb 24 (UTC)
* Finally: Consider putting the table into a section and using section editing to edit the table by itself. Uncle G 00:16, 2005 Feb 24 (UTC)
:That warning exists because some very old browsers are not able to deal with pages than 32 kilobytes.  Given that the front pages of many major sites (including the English Wikipedia, Google News, and Excite) are already larger than this, I think it's a really nonsensical warning.
:—Ghakko 15:54, 12 Jun 2005 (UTC)
thread_title:  Page is getting too big? 

message: Are you sure that HPFS does not have Last entry change timestamp?
I see timestamps for last change, creation and last access.
--Error 23:35, 12 Jun 2005 (UTC)
thread_title: HPFS

message: I just added the "block fragmentation" column, but it occurred to me that this may be what the editor who added "block suballocation" meant but didn't explain very well.  The block fragmentation policy implemented in all FFS derivatives works like this:
* Data blocks are either full blocks or fragments.
* Only the last block of a file may be a fragment.
* The ratio of block size to fragment size is set at initialization, and is a property of the entire filesystem (this distinguishes fragmentation from variable block size).
: 121a0012 05:12, Jun 23, 2005 (UTC)
** Block suballocation is (currently) a Netware NWFS-only feature, whereby the wasted space at the end of the filesystem block, typically 64k, can be subdivided into smaller blocks, typically 512B to 8KB, which can be used for other files.  Sounds a lot like block fragmentation, but it has a Novell-only twist. MARQUIS111
Be careful with the use of the term fragmentation as it is badly overused.  Even fsck in FFS used both meanings.  I prefer block suballocation over block fragmentation, as it is less ambiguous.  Allocation fragmentation could be expressed as either internal fragmentation (when a file is scattered) or external fragmentation (when the files in a directory are scattered).  BSD handles all three.  Linux does all but suballocation (last I checked).  NTFS does none of them, but has a defragmentter that fixes internal fragmentation while making external fragmentation worse. --ssd 15:06, 6 January 2006 (UTC)
thread_title:  Block suballocation vs. block fragmentation 

message: It would be nice if the layout table actually said something about the layout policies of individual filesystems.  In order to do so, it would be necessary to develop a succinct vocabulary to characterize the salient policies of each.  There are two major axes we want to characterize: how much does the layout algorithm know about the physical layout of the disk (geometry), and how does the layout algorithm decide where to put related objects.
Geometry terms: oblivious (FS takes no account of geometry; disk is just an array of sectors), rotational geometry (FS uses classical cylinder/head/sector layout rigidly), zone geometry (FS uses information about modern ZBR disk layouts), zoned oblivious (FS does not use C/H/S layout but divides disk into a fixed number of zones or groups with the assumption that accesses within a zone are faster)
Layout terms: first fit, next fit, interleave (models platter rotation to put next block under read head at "right" time), append-only
Additional policies: directory preference (put files close to directories referencing them), zone preference (put related things in same zone), non-overwriting (always allocates new block for updates)
Examples:
* FAT: oblivious, first fit (older implementations) or next fit (newer implementations)
* FFS: rotational geometry, interleave, zone preference
* UFS derivatives (including ext2): zoned oblivious, next fit, zone preference, directory preference
* UFS/LFS: oblivious, append-only, non-overwriting
* JFS (AIX implementation): zone geometry, zone preference
* ZFS: ???, non-overwriting
: 121a0012 05:40, Jun 23, 2005 (UTC)
::I could be wrong but aren't some of these OS/file system implementation specific rather then file system specific? Perhaps there are recommendations in the file system spec (if one exists) but I think for some of them, it's up to the OS/file system driver/implementation. Surely a file system implementation could put the files next to the directories or not, it wouldn't matter, it would still  be understood and arguably completely legal and in many cases I suspect may not even be corrected by another implementation (even the 'official' implementation). Similarly with other policies and I suspect layout terms as well (even though I don't completely understand this). Even geometry terms I'm not sure whether it's file system specific. Perhaps in some cases but it doesn't have to be?
::BTW, I believe some Windows defraggers for NTFS and FAT do in fact practice directory preference (not sure about MS defrag)
:::60.234.141.76 17:22, 17 September 2005 (UTC)
thread_title:  Layout policies 

message: The article currently gives the incorrect impression that filesystems were invented in 1980.
While not every operating system includes a file system,
I suspect that at least *some* of the pre-1980 operating systems included a file system:
* 1964 ? Multics
* 1970 Unix
* 1974 CP/M
* ? RT11
* 1978 Apple DOS
* ? Multiuser DOS
* ? MP/M
(I've seen mainframe computers with their huge disk packs --  Early IBM disk storage -- did any of them have a file system ? Or did applications always directly write to cylinder,head,sector locations ?)
--DavidCary 30 June 2005 06:22 (UTC)
:Even CTSS had a filesystem of a sort (at a level of functionality which remained common among Big Iron into the 1980s).  I think this page rightly concentrates on filesystems which are still in active use (or at least it did; I see a few obsolete ones have been added).  18.26.0.5 22:39, 20 July 2005 (UTC)
thread_title:  file systems before 1980 

message: What filesystems can lookup filenames from a binary tree or similiar to avoid scanning through all files sequentially to find the one they're looking for? Especially important in large directories, eg. mail files in maildir.. I know ext3, reiser and xfs at least has them.
HFS+'s directories are implemented with a big B-tree, the Catalog File, the key being a combination of the file name and the Catalog Node ID (CNID, think "inode number" from a UN*X standpoint) of the parent directory.  See the "Design" section of the page on HFS. -- Guy Harris 01:03, 22 September 2005 (UTC)
thread_title:  Directory indexes 

message: The NWFS/POSIX cell displays '?' and I'd like to change it. But I'm not sure if it's a 'Yes' (with a Note?) or a 'No'. NWFS does have a ACL capabilities, called Trustees and similar to NSS, but no POSIX interface. JoetjeF 20:54, 26 August 2005 (UTC)
thread_title:  NWFS 

message: NTFS has this feature called sparse files. Basically, rather then storing a incomplete/file with lots of zeros as a full size file, you only store the data you have. Of course, this does result in a lot of fragmentation, especially if you use it with P2P where you get lots of different portions in different areas, which is probably it's most common use nowadays (although I think it was added long before P2P). I don't know if anything else has it but it would be worthy of inclusion. Perhaps data compression can do the same thing as well but sparse files is somewhat different and simpler! 60.234.141.76 16:47, 17 September 2005 (UTC)
replies: text: Most UN*X file systems support sparse files; support for them dates back at least to the Sixth Edition file system.  (HFS+ is an exception, although it didn't start as a UN*X file system.) -- Guy Harris 00:54, 22 September 2005 (UTC)
replies: text: I do not understand what you mean to indicate about HFS+. I believe that HFS+ does support sparse files on the volume level (just the OS may not be providing API calls for it, but that's not the point here, right?). Also, UDF supports them (I am very sure of that). Tempel 23:27, 16 March 2006 (UTC)
replies: text: OS X definitely provides API calls for creating sparse files - lseek() and write(); it's a UN*X, after all.  However, all the extents of an HFS+ file are assumed to be adjacent (the data in extent N+1 comes immediately after the end of the data in extent N), so there's no provision for holes in the file, and the HFS+ implementation has to put zeroes in a hole. Guy Harris 00:39, 17 March 2006 (UTC)

text: Most unix file systems will allocate blocks if you write to them -- even if you write zeros.  ZFS with compression enabled will (as a special case) compress an all-zeros block out of existence, turning it (back?) into a file hole.  Finding hole edges is another issue with hole API's.  Shortly before ZFS integrated, Solaris also grew two new lseek() opcodes: SEEK_HOLE and SEEK_DATA to permit holes to be found efficiently. --Sommerfeld 20:01, 1 May 2006 (UTC)
thread_title:  Sparse files 

message: How is that defined?
At least in FreeBSD, UFS1 and UFS2 support extended attributes as short named data items; I think at least some Linux file systems do so as well.  How does that differ from what HPFS, for example, offers?  Perhaps no desktop environments on FreeBSD or Linux use extended attributes for that purpose, but that's not a file system issue.  Should "Rich file-type meta-data" be called just "extended attributes", perhaps with a footnote explaining what that means? Guy Harris 08:10, 29 December 2005 (UTC)
replies: text: I think so, yes --80.98.38.69 12:50, 6 January 2006 (UTC)
thread_title:  "Rich file-type meta-data" 

message: To what does the item for "FS" refer?  The file system that was used in Version 6 Unix, and possibly some earlier versions (I don't know how far that file system goes back)?  The file system that was used in Version 7 Unix, which came out in 1979, and which was different from the V6 file system (it added triple indirect blocks, for example, to allow larger files), and which was the basis of the file system used in 4BSD up to 4.1BSD (with a 1024-byte block size and some other small tweaks; 4.2BSD introduced FFS) and System V (which I think also went to a 1024-byte block size)? Guy Harris 08:22, 29 December 2005 (UTC)
replies: text: The 'FS' filesystem in unix was the first unix filesystem.  The 'FS' stands for (surprise!) File System. --ssd 14:44, 6 January 2006 (UTC)
replies: text: Note that "the first unix filesystem" wasn't the file system in V7 or SIII or SV - there was a significant change between the earlier file systems and the one in V7, the latter being the one on which the SV file system is based. Guy Harris 21:03, 6 January 2006 (UTC)
thread_title:  UNIX "FS" file system 

message: How is tail packing different from block suballocation? I presume that block suballocation splits a block into even-sized sub-blocks, whereas ReiserFS's tail-packing packs fragments contiguously? --Martin Rudat(T|@|C) 09:36, 18 February 2006 (UTC)
replies: text: Yes, that's how I understood it. However, technically tail packing can be seen as a special case of block suballocation where the suballocation block sizes are always 1 byte long. Does anyone else think that tail packed filesystems should also have a  on block suballocation? -- intgr 14:29, 26 September 2006 (UTC)
replies: text: I'll create a new footnote for that; anyone who objects, feel free to revert it after responding here. -- intgr 14:33, 26 September 2006 (UTC)
thread_title:  Tail packing vs Block suballocation 

message: Just wanted to point out that 'ECC' for the column checksum/ECC goes only to a disambiguation page.  —The preceding unsigned comment was added by Deeahbz (talk • contribs) 11:43, 5 March 2006  (UTC)
:Just wanted to point out that, as the "Wiki" in "Wikipedia" suggests, you can fix problems such as that yourself, as I just did for the ECC problem (see that for an example of how to go past a disambiguation page). :-) Guy Harris 20:09, 5 March 2006 (UTC)
thread_title:  Metadata chart 

message: For completeness, have started adding the FATX filesystem, as used in the Xbox and Xbox 360.  Info on this filesystem appears to be sketchy, but sites such as http://www.free60.org/wiki/Main_Page are proving useful. --OscarTheCattalk 22:38, 7 March 2006 (UTC)
thread_title:  FATX 

message: IBM GPFS filesystem is missing in this chart. Would anybody like to add it? Thanks. 69.225.127.198 01:25, 15 March 2006 (UTC)
replies: text: Would you like to add it? :-)  That is, after all, what the "Wiki" in "Wikipedia" suggests....  Guy Harris 01:40, 15 March 2006 (UTC)
thread_title:  GPFS is missing 

message: Though I would cringe to do the work, these filesystems should probably be listed alphabetically rather than chronologically.  65.94.60.61 07:16, 27 March 2006 (UTC)
replies: text: Nah, I prefer chronological. It makes more sense to see the progression of ideas. CTRL-F works well to find things alphabetically. Morcheeba 20:21, 26 April 2006 (UTC)
thread_title:  order 

message: Compression, maybe, but not encryption.  An indication of whether the file system supports encryption might be useful, but it doesn't belong in that particular table. Guy Harris 03:07, 28 April 2006 (UTC)
replies: text: I've made a bold edit and removed that new column.  Suggest we discuss here whether it's worth featuring, and if we decide it's worth having, we only then add it when we can have less "dunno" answers in the column.  --Oscarthecat 06:21, 28 April 2006 (UTC)
thread_title:  Transparent encryption is an allocation and layout policy issue? 

message: At least two common and/or important filesystems are missing from the list:  Irix EFS and the Minix filesystem.  EFS, contrary to its own article, was the default filesystem in and beyond Irix 5.3.  I ran an EFS filesystem for a long time on my Irix 6.2 machine, and that is the way that I received the machine.  XFS was available but not commonly used, to my knowledge, for "smaller" filesystems.
As to the Minix filesystem, its importance comes not only from the Minix operating system but also from its use in early versions of Linux, before such novelties as ext2fs were invented.
Someone with more time and knowledge than I have might want to add these. :) Ari 17:38, 1 May 2006 (UTC)
thread_title:  Missing 

message: I filled in a few blank boxes for ZFS.  I think I guessed correctly what was meant by "tail packing".  If someone explains what they meant by "block suballocation" I'll figure out whether ZFS uses it.  --Sommerfeld 19:54, 1 May 2006 (UTC)
thread_title:  Block suballocation? 

message: This section really needs to be cleaned up and checked. I made a few edits and clarifications but it still needs work. Article seems to assert Windows (in general) only uses FAT32 and NTFS, and derived those from FAT and HPFS. Obviously this is not true. We should also mention FAT12. Dsav 04:54, 28 Apr 2005 (UTC)
thread_title: Filesystems Under Microsoft Windows

message: HFS+J is now case-sensitive (selectable). Edited to reflect that
66.115.245.120 02:51, 25 June 2006 (UTC)
replies: text: You're right, but unfortunately people here have a misunderstanding about what HFSX is. For whatever reason,  people think it is a new format rather than just HFS+ rev 2. It'll probably get reverted. -- Steven Fisher 14:27, 25 June 2006 (UTC)
thread_title:  HFS+ is Case Sensitive 

message: People usually use both "filesystem" in one word, or "file system" in two words and even within one and the same text, you very often see those two variants mixed.  If there exists something interesting to say or some recommendation about which to use, then add it.
The same could be said about filesize, filetype, etc.
--by anonymous user 83.78.187.157
:i prefer seperation into two words which makes it imo easier to read and seems to better fit into the common usage of the english language. --Pythagoras1 15:59, 12 February 2006 (UTC)
replies: text: Linguistically spoken, the two words may be more correct. However, in common informatics language, the single word is much more in common use. Unlike Pythagoras, I even find the single word easier to read as it comes forward as one specific term. I would thus prefer the single word as title for the article! LHOON 11:11, 14 December 2006 (UTC)
thread_title: Filesystem or file system?

message: A table of the available tools is missing. Tools that come to my mind are: shrink / enlarge (offline or online), defragment (online/offline), undelete, shred.--Hhielscher 23:09, 29 June 2006 (UTC)
replies: text: I'd like to second a request for adding tools, especially whether or not a filesystem can be grown or shrunk.  I was all jazzed to pick XFS until I learned that XFS filesystems can only be grown, not shrunk, so this information would be helpful.  --Trixter 16:46, 12 October 2006 (UTC)
replies: text: Sounds like a request for the comparison of file systems article. No comparison tables on the file systems article itself, please. -- intgr 17:15, 12 October 2006 (UTC)
thread_title:  Tools (resize,defrag,undelete) 

message: I'd like to see columns "number of files per directory" and "number of files per filesystem" added to the limits section --WhiteDragon 20:19, 9 August 2006 (UTC)
thread_title: Question about Limits

message: The second paragraph of the introduction says that it’s debatable whether a file system is a special-purpose database. But that seems to be the article’s only mention of that debate. If it’s so important to warrant a mention in the introduction, then the article address the topic in more depth. And could someone please provide some citations (say, one anti, one pro) regarding the debate? --Rob Kennedy 04:23, 15 September 2006 (UTC)
thread_title:  Special-purpose database 

message: FAT's Unicode support is 16-bit, and for some periods in history the use of UTF-16 surrogates was unsupported or prohibited.  I think that under XP there's a registry setting that enables UTF-16 filenames, and I'm not sure that the default state is set (I expect this would affect NTFS as well).  Whatever the specifics, I think that the assertion that Any Unicode character is supported is under-qualified. --ToobMug 11:14, 13 October 2006 (UTC)
thread_title:  FS comparisons; FAT and Unicode support