Talk:File system

Section "Too-long file names and file paths" makes wrong claims

Quote: If any of the parent directories above "x" are renamed to be longer than 2 characters, "x" becomes inaccessible to the file system ... which is wrong. It is inaccessible to the Win32 subsystem unless the file name/path is prepended with \\?\ and the respective code uses the wide Win32 APIs (as opposed to ANSI). Neither kernel mode drivers nor code (including Win32 programs) using the Native API will have trouble accessing it. Since this is utterly misleading, I am going to remove this part from the article. --Assarbad (talk) 22:12, 26 June 2011 (UTC)

It's not a limitation of the OS as the original suggested, nor is it a limitation of the FS. Just to clarify that. --Assarbad (talk) 22:46, 26 June 2011 (UTC)

The "Win32 subsystem" is part of the operating system, yes? So it is a limitation of the combined file system and operating system, and is worth documenting. Trying to open exceedingly long paths in Explorer usually results in strange messages or Explorer completely hanging. Who uses "\\?\" as a file path in Windows? that appears to be some obscure hacker-equse comment on limitations. I suppose I should mention that while Windows doesn't allow reserved characters in file names, you can technically force them into the names anyway using a disk sector editor tool, so should any mention of reserved symbols in file names be deleted from Wikipedia?

Not formally, no - it's not "part of the OS". It's perhaps worth documenting, but not as a limitation of the file system or the OS. And you'd be surprised just how many applications internally use the "\\?\" and still show to you as the user the more natural form without that prefix. Your comparison with using a disk editor is not even a good attempt. --Assarbad (talk) 00:44, 30 June 2011 (UTC)

I think I should elaborate. You wouldn't write in the File System article that certain limitations a particular SUS-compatible shell (say Bash) imposes on the file/folder name is is a limitation of either the OS or the file system, would you? That's the point I'm trying to make. --Assarbad (talk) 01:04, 30 June 2011 (UTC)

The problem of too-long parent names also affected the old Macintosh System 6 and System 7. I don't recall the max pathname for System 7, but it was very easy to shoot yourself in the foot renaming parent folders and rendering children inaccessible. DMahalko (talk) 02:45, 27 June 2011 (UTC)

Oh and testing this just now in Windows 7 shows what you are claiming to be invalid.

* Windows Explorer response to a path of "\\?\" -- Windows can't find '\\?\'. Check the spelling and try again.

* Windows 7 command prompt response to "dir \\?\" -- The filename, directory name, or volume label syntax is incorrect.

DMahalko (talk) 02:51, 27 June 2011 (UTC)

Your point being? What's that comparison with Mac got to do with it? I just pointed out that the claims made (originally) in that paragraph are technically wrong. Please consult the respective documentation from Microsoft. While MAX_PATH for Win32 (i.e. APIs compatible back until Windows 3.1) is 260 and includes the drive specifier, the documentation (for example here, section "Maximum Path Length Limitation"), is pretty clear on the matter. What you are trying to point out are nothing but limitations of the Win32 subsystem (which is not the same as the OS or the file system) w.r.t. the traditional file path syntax and limitations of particular implementations in programs. Whereas the issue with Windows Explorer is in addition that it accepts names from the shell namespace (including those in the file system). And I'm not saying this example must not be inserted - on the contrary. If inserted with the right context and proper description, it may well be an interesting fact. Although I would argue that such information is better suited in some Windows-specific article rather than in this one. However, the way it was given, it was misleading at best. --Assarbad (talk) 00:58, 30 June 2011 (UTC)

Archive

I exhaustively archived this talk page. Someone may want to split that into multiple archives, as archive one is very long. Also, someone with extra free time might want to resurrect any posts in there that are worth keeping here, as that discussion archive is quite a time capsule of this page.

--SuperLuigi 31 15:59, 22 March 2007 (UTC)

Transactional NTFS

Shouldn't it point to WinFS? countryhacker 11:52, 11 December 2005 (UTC)

Only if it's the same thing as WinFS. WinFS, from all I've seen (including stuff on MSDN), runs on top of NTFS; perhaps the database for the items in WinFS uses transactional features in "NT 6.x"'s NTFS, but I don't think they're the same thing. —The preceding unsigned comment was added by Guy Harris (talk • contribs) 08:57, 12 December 2005 (UTC)

So is "Transactional NTFS" really the same thing as "WinFS"? Microsoft's MSDN information on Transactional NTFS seems to indicate that it's just a scheme to let applications construct transactions on NTFS; it "allows an application to group multiple operations on multiple files as a single unit—a transaction", so that "an application can then commit or roll back the entire group of changes as a single unit".

And is WinFS really a file system in the same sense as other file systems here? Or is it a storage system built atop SQL Server, with the SQL Server database stored in ordinary NTFS? Guy Harris 05:08, 29 December 2005 (UTC)

WinFS is not a file system in the vein of NTFS, HFS+, ext3, etc. The WinFS article has received a number of updates recently which should help clarify the difference. Warrens 01:16, 14 January 2006 (UTC)

Transactional NTFS is not WinFS, it is a mode of operation of NTFS where an application can attach multiple file handles to a transaction object, then perform a series of operations, and NTFS will guarantee either they all commit, or none of them complete. It provides full transactional integrity of both the filesystem metadata and user data involved. --Aaaaa0 13:45, 2 February 2007 (UTC)

Transactional Reiser4

AFAIK Reiser4 have full transaction support (not only modifacition to single file, but also multiple files, directories, all operations, read,write,modify,create/delete,move, metadata changes are spanned by transaction). Currently there is no direct API available for this, do to the lack of VFS infrastructure. But it supports it, and have been working very well. —Preceding unsigned comment added by 91.213.255.7 (talk) 19:38, 27 June 2010 (UTC)

folder vs. directory vs. sub-directory

Readers need to understand that these three terms all refer to the same thing. *** I was surprised to see the term "folder" specifically mentioned in relation to Windows -- I thought it was more of a Mac thing originally? 69.87.200.105 14:25, 22 January 2007 (UTC)

Facilities

The example given "interprocess pipes in Unix have to be implemented outside of the file system because the pipes concept does not offer truncation from the beginning of files.", seems a bit specious, since file-system FIFO pipes ARE present in Unix. It would make more sense here to give a functional reason (with references), probably one or more of omitting such symmetry in service to performance, faster implementation, or some other constraint. Certainly both prepending and arbitrary insertion CAN be implemented in a filesystem keeping tracks of data blocks by, say, doubly-linked lists. The problem is that read speed would be terrible after a while with the read head having to run all over the disk drive to find the scattered blocks. Etc. —Preceding unsigned comment added by Siodhe (talk • contribs) 16:58, 11 March 2008 (UTC)

move Plan 9

I am impressed with the article, at first sight -- but the Plan 9 material seems excessive, in context; seems like it should move to its own article, and be briefly summarized here. 69.87.200.105 14:25, 22 January 2007 (UTC)

article Talk redirect confusion

There are two separate articles, File system and Comparison of file systems, but the talk for Comparison redirects here! Very confusing!! I don't think it is good, but if the two articles are going to be so joined at the hip, they each need to say so at the top and the bottom of each, and the combined talk page needs to clearly explain what is going on, at the top and the bottom. 69.87.203.23 23:48, 22 January 2007 (UTC)

Split: this has confused me, too. Someone ought to archive and/or split this page, and remove the redirect from Talk:Comparison of file systems. Even though the articles are related, they are still separate articles and ought to be discussed separately. -- intgr 14:58, 23 January 2007 (UTC)

What happened (which you apparently were not around for) was that the File system and Comparison of file systems articles were briefly merged around the middle of 2006, and then hastily unmerged when this turned out to be a controversial idea. However, because of the way the merge was done, the history of Talk:Comparison of file systems was lost, and the rediret pointing to Talk:File system was never undone. I think this mess requires an admin's attention to untangle. 121a0012 03:12, 10 February 2007 (UTC)

I have split the page now, as there have been no disagreements for two months, and this has only been causing confusion. See Talk:Comparison of file systems. -- intgr 11:35, 29 March 2007 (UTC)

正确的如上！ —Preceding unsigned comment added by 221.182.46.36 (talk) 02:41, 13 September 2009 (UTC)

{{editprotected}} request

{{editprotected}} I think, that phrase "The /mnt directory exists on many Unix-like systems (as specified in the Filesystem Hierarchy Standard) and is intended specifically for use as a mount point for temporary media like floppy disks or CDs." better say as "The /mnt directory exists on many Unix-like systems (as specified in the Filesystem Hierarchy Standard) and is intended specifically for use as a temporary mount point."

FHS directly said (http://www.pathname.com/fhs/pub/fhs-2.3.html#MNTMOUNTPOINTFORATEMPORARILYMOUNT), that /mnt is a point for temporary mounts. But mount point for temporary media is /media (http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT).

P.S. Sorry for my poor English, I'm not a native speaker.

I've removed protection. Cheers. --MZMcBride 23:07, 9 June 2007 (UTC)

History section?!

Is there somebody knowledgeable && enthusiastic enough to add a good history section?
217.236.209.212 20:57, 27 June 2007 (UTC)

I was actually going to request the same thing. -- Beland 22:19, 8 October 2007 (UTC)

Me too! File systems have emerged and inspired each other instead of popping out of the nowhere. And there are people behind it. -- JakobVoss (talk) 21:48, 23 March 2010 (UTC)

Definition

I have a problem with the reference to hierarchical organisation in the formal defintion: "More formally, a file system is a set of abstract data types that are implemented for the storage, hierarchical organization..." While most file systems employ tree-like organisation I don't see why file systems are formally defined to not be able to use other methods. --The Extremist [User, Talk] 08:17, 12 September 2007 (UTC)

Seems that definition is still like that. I really have to propose it be removed or re-written. I don't agree with the words "special purpose" or the hierarchical part. And I'm also a little bit against including navigation in that list too (that's sort of more an OS presentation thing). Supertin (talk) 10:41, 18 July 2008 (UTC)

NTFS/FAT table

The table at the bottom of the page showing NTFS and FAT filesytem limits, etc is not accurate.

• There are multiple versions of NTFS, and it's been around a lot longer than since 2000.
• FAT16 is missing.
• NTFS is listed as being readable only by Windows but writable by Linux and OSX aswell... In fact the 2 rows should probably be merged into "supported OSes" (with a "*" note for readonly support if required).

Supertin (talk) 01:03, 24 January 2008 (UTC)

Crash Counting Merge

The crash counting merge tag on this article has been there forever. Why doesn't an administrator go ahead and do the merge already? Just how long is this process supposed to take? Public Menace (talk) 19:23, 26 January 2008 (UTC)

IMHO this (File system) article is already difficult to navigate and understand (it's a complicated topic).

Crash counting is a technique used to preserve file system consistency not a file system .

The article on the SPAD is mostly a reference to a PDF (very unsuitable for reading online)

I would think that adding it to List_of_file_systems would be more appropriate, I will do that.

DGerman (talk) 23:07, 6 February 2008 (UTC)

Since crash counting is not covered anywhere I can find, and certainly not here, I removed the redirect to here and restored the crash counting stub. --Treekids (talk) 21:17, 25 July 2011 (UTC)

Filesystem = Specialized Database

There seems to be some confusion here about the relationship between file systems and databases. A file system is a database since it stores records (files) in a structured way. This is the definition of a database. I am not aware of anyone ever suggesting that a file system is not a specialized database, and there is no citation disputing this. It seems a little silly to say that Berkeley DB is a database and MySQL is a database but that somehow hierarchical access makes a file system lose its database credentials. On the other hand, the common use of "database" is a RDBMS, and neither Berkeley DB (which is a flat mapping of record keys to records) nor a file system qualifies. So saying that it is "debatable" whether to call a file system a "specialized database" is not correct at all, and calling a file system a database (without qualification) is a matter of convention and preference, not a real debate.169.229.200.176 (talk) 19:51, 9 June 2008 (UTC)

What database and file system are are words. They are abstractions. What kind of abstraction they are, how they got there, is the purpose of the article. Using one to describe the other is possible in simile. All writing is debatable, and improvable. The bigger the article, the more improvement room it has. Lucidity is the drum beat of a concept with various orchestral instruments. If I want to profess file system, one of the instruments is database, another is the phrase "sequence of bytes". The history of file systems can best describe a file system: A file system is a reel of magnetic tape. The more we write, the more ways we sayit, the more things begin to make sense, and the more the path to rebuilding becomes clear. — CpiralCpiral 06:50, 14 December 2009 (UTC)

Removal of material copied from Microsoft's knowledgebase

I just removed content copied by 70.124.61.67 (talk · contribs) back in April from this KB article. I came across the funny formatting in the 'File systems under Microsoft Windows' section so I checked through the history and found this anonymous editor's contributions. A quick Google search found the KB article, from which most of the text had been copied.

Why did no-one notice this copyright violation? Always be suspicious of edits adding large chunks of well-written text, especially if it's coming from an anon or new user. The use of HTML formatting tags is also a good indicator. All it takes is to copy a sentence or two into Google Search to find the source. --Imroy (talk) 17:54, 3 July 2008 (UTC)

Generic name for 'file allocation table'?

Is there no generic name for systems of allocating the different parts of a file? The article speaks of "a file allocation table of some sort, such as the FAT in a DOS file system, or an inode in a Unix-like file system". And in other sources I have also found references to "a file allocation table". Which suggests that there are several, not just FAT. Is that true? And if so, what is the generic name? DirkvdM (talk) 08:02, 2 August 2008 (UTC)

You are correct. FAT (1977) is Microsoft's version of an older and more generic filesystem structure called a block map, or much more commonly, block bitmap. The RT-11 filesystem (1970) was such a filesystem. So was the CP/M filesystem (1974). Block bitmapping is a type of filesystem where there is a data structure on the disc that is an index to all the blocks on the disc. Each block (or cluster) is marked used (or allocated), or not, to keep the data from being overwritten. A computer science lecture note from UCLA uses "block bitmap" [1]. BTW, FAT is really an filesystem architecture, with a family of filesystems: FAT12, FAT16, FAT32, (and now) FAT64. Although FAT12 was originally called simply FAT, before the increased size of discs required extending the FAT architecture. One major difference between RT-11 and FAT filesystems is that under RT-11, file allocation had to be one contiguous allocation of blocks, while FAT can have noncontiguous block allocations, since it uses a linked list of allocated blocks. Both tend to lead to disc fragmentation. Also, it has been said that FAT was conceptually based on RT-11. The more one digs into inventions, the more often one finds out that "new inventions" are mostly built on previous ones. — Becksguy (talk) 12:40, 2 August 2008 (UTC)

You mean to say I am correct in assuming that file allocation table is the generic term? Or is it block map or block bitmap? Neither has an article, and the closest I can find is Block allocation map, which says next to nothing and then refers to file allocation table. This article has a lot of general info that should be in a more general article. But the question remains then what the general article should be called. Block allocation map seems a bit archaic (is it?). And it's also incorrect, because what a file system does is allocate files (which is why it is called a file system :) ), right? Since the most used generic term that I have come across is 'file allocation article', this should become the generic article. Unless Microsoft came up with the name 'file allocation table', in which case there is a conflict between custom and historical accuracy. But if this becomes the generic article, then what should the microsoft-version be called? msFAT? FAT (Windows)? DirkvdM (talk) 18:16, 4 August 2008 (UTC)

The article on BAM has been updated with a link to Commodore DOS. It no longer just leaves you asking for more, and with no more to give you, sends you back to FAT. By the way, the sector size on the PET 4040, CBM 1540/1541 and CBM 1571, has nothing to do with the BAM like it does on a PC drive using a FAT. It is not possible to locate old files using a BAM, as the only reason to use the BAM, is to find a place where there is not yet a file. Paradoxically, the BAM was also used quite frequently as a repository for storing executable code. Dexter Nextnumber (talk) 21:46, 7 December 2009 (UTC)

As far as I can tell, "file allocation table" can't be the generic term simply because file system data structures vary a lot; most modern file systems don't use a table for keeping track of block pointers. "Block map" sounds more accurate, but it doesn't convey the meaning well. -- intgr [talk] 20:31, 4 August 2008 (UTC)

"file allocation table" is a generic term, it is not a filesystem!! this MUST be fixed. Read Operating System Concepts - Avi Silberschatz, Peter Baer Galvin, Greg Gagne - John Wiley & Sons, Inc. ISBN 0-471-69466-5--Jperelli (talk) 23:39, 2 July 2009 (UTC)

A FAT is a type of directory. It allocates files in their entirety. If the file is fragmented or not, the directory scheme points to the first fragment. It is up to the first fragment to point to the second fragment, and so on. A directory is a computer science "structure" known in C programming as "struct". Unix directories use an inode struct, and DOS directories uses a FAT structure. A directory is a file itself, located near the boot block and other system areas "at the beginning". 97.126.30.185 (talk) 16:13, 16 December 2009 (UTC)

Each of your statements is wrong in some context. A FAT is not a directory, it is a table of blocks allocated somewhere on the device. A directory is not a C struct, it is a collection of directory entries (files and possibly subdirectories). Unix directories contain i-node numbers within their entries. A FAT "structure" is not a C struct. A directory may or may not be a file itself, depending on the OS; in Windows and recent Unixes, they are not. Where a directory (or FAT) is located on the device is extremely device-dependent; some directory schemes spread file block allocation maps across the device space, while others keep it (and sometimes a duplicate copy) located in a reserved area, which could be on the inner tracks or in the center of a disc surface. Devices such as flash drives don't even have surfaces, so how do you describe where the block map is kept in relation to the rest of its memory space? — Loadmaster (talk) 23:00, 16 December 2009 (UTC)

"File Allocation Table" (FAT) refers to a particular data structure used at the heart of a family of filesystems developed by Microsoft. This family contains FAT12, FAT16, FAT32, and FAT64. The File Allocation Table is a list of elements with each element in the list representing the state of each block on the storage media. (Strictly each element represents a "cluster" which is a fixed size block of contiguous space in the partition.) Conceptually this list is similar to a bit array, but each block can be in more than two potential states. The File Allocation Table can accurately be described as a map since each element in the list has a direct correspondence with a single data storage block on the media. In the FAT family of file systems the File Allocation Tables for the filesystem are stored on the storage media in central location near the start of the usable storage area. {Thanks to 121a0012 for pointing out a misleading statement in an earlier version of this comment.}

Actually, it's a linked list: it not only shows which blocks are allocated and which are free, but also the address of the next allocated block. A directory is simply a file that gives attributes of a bunch of files -- one of which is the address of the first block. The FAT is used to find the remaining blocks (if any). 121a0012 (talk) 01:56, 1 April 2011 (UTC)

In contrast, an inode is an alternative approach to designing a filesystem. In filesystems based on inode data structures a "root" inode is stored at a defined location on the storage media. As directories and files are added to the media new inodes structures are allocated to these directories and files as needed. Data pointers (or references) are updated in the existing inodes to integrate the new inodes into the existing filesystem tree.

A key difference between the family of FAT filesystems and inode-based filesystems is that an inode-based filesystem distributes the filesystem index across a wide area of the storage media. In contrast, a FAT filesystem uses a central area to store the index for the filesystem.

A possible "generic term" for FAT filesystems and similarly designed filesystems might be "Centralized Index Filesystem" or "Table-Indexed Filesystem" if the generic term is being used to classify filesystems based on the key data structures used in their implementation. — Mrichmon (talk) 00:41, 1 April 2011 (UTC)

Unused Blocks

It states: Erasing blocks: Flash memory blocks have to be explicitly erased before they can be written to. The time taken to erase blocks can be significant, thus it is beneficial to erase unused blocks while the device is idle.

However, this would simply deminish the life of the cells. The flash memory has its own wear levelling, typically, and therefore writes to unused cells before going back to previously written ones. ALSO, the controller is smart enough to check to see if the data in the cell is the same as the data being copied, and if it requires, will erase and rewrite. With MLC, 2 bits are stored per cell. So if the stored data is 01 (or 10), it can modify it to 11 without erasing, which would decrease the life of the cell. If, however the data stored is currently 01, and 10 needs to be written to the cell, the entire cell would need to be erased and rewritten (taking extra time)

The first sentence

The first sentence reads: "In computing, a file system (often also written as filesystem) is a method for storing and organizing computer files and the data they contain to make it easy to find and access them."

I think this definition is circular. Isn't it the file system that creates the concept of files in the first place? A storage device is, after all, just a big ol' collection of bits (yeah, yeah, blocks and sectors, but you get my point). The file system is what organizes the disk into files. Without a file system, we programmers would have to bit-twiddle on the drive itself (actually, that sounds kind of fun).

I propose the following instead: "In computing, a file system (or filesystem) is a method for organizing blocks of related binary data into abstractions called files, for the purpose of making it more accessible and usable." Mbarbier (talk) 19:41, 10 June 2009 (UTC)

I disagree. It should read "In computing, a file system (or filesystem) is a software system designed to organize data in computer storage drives to be accessed, saved, and stored on a computer's operating system more efficiently. — Preceding unsigned comment added by 174.141.208.117 (talk) 21:01, 9 November 2012 (UTC)

Prospero (file system)

I have added all the content (such as it is) from Prospero (file system) per the Merge consensus close at Wikipedia:Articles for deletion/Prospero (file system). There are academic cites (including [2], and [3]) for this filesystem, but I wanted to get this merged first so as to redirect the source article per the merge closure and thus complete that process. I will be citing and revising this content shortly. — Becksguy (talk) 07:44, 11 July 2009 (UTC)

Structure of this article

I am plugging away at what I consider an improvement for the operating system article, when I venture here while doing that work there, and I see this article has a similar need: See the discussion at Talk:Operating_system#Devoting_an_entire_section_to_each_notable_OS. IMHO, prose product sections are magnets for vandalism, spam, WP:COI and the like. and are best presented in a comparison table, while the prose contains lucid theory, with products mentioned in a third tier, under practice, under concept, while giving examples of theory. i.e IMHO, the article should be about file system terminology first, usage of that terminology in as many ways as possible, as learned from how the field uses file system terminology. Second it should use the terms in examples, as dictionaries do. But these examples are not yet products, they are primarily the general practices, shared by products. Third, when necessary, refer to products that are unique, so that the terminology gets a thorough representation of the field.

The size and the vandalism at Operating system got me started thinking this way. The size of of this article is 36kb. It will grow even bigger with the structure the way it is, with products as section titles. BTW, the section titles of this article are not in agreement with WP:MOSHEAD, where it says "Section names should not explicitly refer to the subject of the article". — CpiralCpiral 09:18, 7 December 2009 (UTC)

Tape Formatting and Tape Booting

The "Tape Formatting" and the "Tape Booting" sections do not refer to File Systems.

The contents of the "Tape Formatting" section makes largely correct statements about data tape technologies. However, historically data tapes have not used any kind of file system. This section should be moved to the "Magnetic tape data storage" page

• Historically, data tapes have definitely used a file system including volume names, files names, volume metadata, file metadata in addition to the file's data.DG12 (talk) 00:52, 22 May 2011 (UTC)

Similarly, the "Tape Booting" section makes largely accurate statements about the ability for some systems to boot from tape and the some of the associated drawbacks. Booting these systems from tape does not involve use of any file system with the tape. Instead, booting from tape typically involves manually entering a boot loader or triggering a firmware boot loader. In either case, this boot loader reads raw data from tape and positions the data in main memory of the computer system. When the loading process is complete code execution is started from a well-defined address somewhere within the range of main memory that holds the data read from tape. This section should be moved to the "Magnetic tape data storage" page and/or to the "Boot Loader" page. — Mrichmon (talk) 22:23, 31 March 2011 (UTC)

• I agree with Mrichmon regarding the removing of "tape booting" section and if no one else does I will try to remember to in a month.

DG12 (talk) 00:52, 22 May 2011 (UTC)

A recent concept for file management

The Database file systems section starts with "A recent concept for file management is" and yet that section ends with an external link to a The Register article that was written in March 2002. That is over 9 years ago, which is a long time when it comes to computers, see for instance this timeline. --82.171.70.54 (talk) 14:45, 2 June 2011 (UTC)

conversion / convertfs

I’ve written a section on the (im)possibility of (in-place) file system conversion in this version. It includes a mention of convertfs, a program for in-place conversion via sparse files. The linked technical description is of some interest – it’s a clever idea – but the program itself is very rough and has been unsupported for years, so I want to avoid promoting its use, hence only link to the homepage in a footnote, not in the article text, and include serious caveats. Hope you enjoy!

—Nils von Barth (nbarth) (talk) 12:02, 13 June 2011 (UTC)

There are operating systems other than Linux. 121a0012 (talk) 06:54, 14 June 2011 (UTC)

The section also discusses in-place conversion in Windows. Guy Harris (talk) 16:57, 14 June 2011 (UTC)

Please restrict this article

to general definitions as there are many articles detailing the specifics of individual file systems DG12 (talk) 01:41, 30 July 2011 (UTC)

Yes DGerman, file systems make data understandable by humans

I disagree with DGerman's recent edits removing the material about filesystems being human readable. I am bringing the discussion here rather than start an edit war since he/she has strong opinions enough to do a sudden mass-rewrite.

Computers don't need filesystems and programs don't care about directory/file names. They can just as easily access data directly at the block/sector level, though that is unwieldy for the end-user / operator. DMahalko (talk) 03:22, 30 July 2011 (UTC)

DGerman, do you know what a "sector" is?

It looks like you have no idea what you are talking about User:DGerman about blocks being the smallest unit file systems can address. Lots of editing there that doesn't any sense. Looks like a revert is in order. DMahalko (talk) 03:31, 30 July 2011 (UTC)

DMahalko, I know what a sector is but most filesystems use multiple sector blocks and then there are media which have filesystems and don't have sectors. That is the term sector is too specific a for this article. — Preceding unsigned comment added by DGerman (talk • contribs) 00:49, 1 August 2011 (UTC)

Well, in the BSD fast file system ("Unix File System" or "UFS") there are what are called "blocks" and what are called "fragments", with a "block" containing multiple fragments, and with the fragment, not the block, being the file system's smallest addressable unit. One might consider file system implementations to know about :

• sectors, which are the smallest addressable unit on a disk;

• some unit that's the smallest allocatable unit in the file system;

• some notion of a contiguous collection of one or more "smallest allocatable unit"s.

In some file systems, the latter two units might be the same; in others, you might have "blocks" composed of multiple "fragments", as per UFS, or extents composed of multiple blocks or clusters or whatever the file system calls them. If we're going to use the term "block" for the smallest allocatable unit", we should perhaps note that UFS calls "blocks", in that sense, "fragments".

Sectors are typically not visible to clients of the file system; they're an implementation detail. Guy Harris (talk) 01:16, 1 August 2011 (UTC)

BTW, this means that the discussion of "blocks" and "clusters" in the "Space Management" section appears to contradict itself; the first paragraph says "The block is the smallest individual unit that the file system allocates.", but the second paragraph says "Some file systems allocate storage through an abstraction layer of clusters which contain a number of blocks. Each layer of abstraction results in wasted space when a file is smaller than the smallest allocation unit the file system is capable of tracking." If the first sentence is true, then a file could contain a fractional number of clusters, as per UFS (with "block" meaning "fragment" and "cluster" meaning "block"); if the second sentence is true, then a "block" is really a cluster. Guy Harris (talk) 01:26, 1 August 2011 (UTC)

reworded DG12 (talk) 21:57, 3 August 2011 (UTC)

The article eliminates the level of software abstraction involved:

The article hides the fact that filesystem development is also categorized as software system development, hence, the users will be uninformed that filesystems are actually software. — Preceding unsigned comment added by 174.141.208.97 (talk) 20:53, 9 November 2012 (UTC)

I suspect that User:151.75.122.123 was, in his or her recent changes, noting that "file system" can refer to the layout of data on the storage medium, as per "A fs is a data structure; fs implementations are drivers.". A given on-disk file system layout can have multiple software implementations - the various flavors of the FAT file system have several implementations on several different operating systems, for example. So a given storage-medium-based file system may have a single specification for the on-medium layout and multiple software implementations, a given network-based file system may have a single specification for the over-the-wire protocol and multiple software implementations, and a given pseudo-filesystem may have a single specification for the semantics of the files and directories in it and multiple software implementations. Guy Harris (talk) 22:44, 9 November 2012 (UTC)

The third sentence of User:151.75.122.123 version did say that, "by extension", a file system also included the software that implements the abstraction. However, that buried the "it's implemented by software" (or firmware...) at the end of the paragraph, and abstraction (computer science) went to a page that's a bit technical and that talks about abstractions in a fashion that sounds more as if the API used to access file systems would be the abstraction, abstracting away the details of the particular file system or file systems underneath it. The layer of abstraction at which I see a file system residing has the on-disk data structures or on-the-network protocols or semantics of files and directories in a pseudo-filesystem as part of the abstraction and the software implementations using those on-disk data structures or protocols and implementing those pseudo-filesystem semantics as being what's abstracted away. Guy Harris (talk) 23:23, 9 November 2012 (UTC)

It's incorrect to say that a filesystem is an abstraction (computer science) of something when the filesystem itself is software. The API that accesses the filesystem itself is also software. The software page even states that software is "something that tells the computer what to do and how to do it". Everything on the computer is first seeked and decoded by the processor, so technically almost everything on a computer that is executed is "software" in some tangible sense. It may not necessarily be a "computer program that does a task, or a specific set of tasks" but it is still some form of software that either aids in structuring, maintaining, or guiding some specific details to be done a certain way, and that may be what's abstracted beneath the language. — Preceding unsigned comment added by 174.141.208.108 (talk) 17:15, 11 November 2012 (UTC)

A specification only "tells [a] computer what to do and how to do it" if you have software that, for example, reads a specification and generates software that follows the specification; in general, a specification tells a programmer what to do and how to do it. As such, I, at least, would not consider a specification to be "software" in the same sense that a particular file system implementation is. Guy Harris (talk) 19:31, 11 November 2012 (UTC)

The only "specification" a programmer would need is a way to implement code to abstract hardware device infrastructure. In such a case, however, the "specification" that tells the programmer what to is creating a process known as software development in one form or another to implement this filesystem to work with the kernel's API(or higher-half kernel). There's no getting away from the fact that a file system is software, whether or not it's written in a language such as C. The abstraction doesn't change this, and the article should be better configured to entail this. Also, this article is back-and-fourth confusing and perplexed; it should be rewritten almost entirely in some areas. — Preceding unsigned comment added by 174.141.208.107 (talk) 22:39, 11 November 2012 (UTC)

"The only "specification" a programmer would need is a way to implement code to abstract hardware device infrastructure." If by "a programmer" you mean "a programmer writing an implementation of a file system", that's not the case; if you want to, for example, implement a FAT file system or UFS or HFS Plus or NTFS or ext2 or..., you would also need a specification that tells you what to put into the blocks you're writing to the storage medium (and the hardware device infrastructure has probably mostly been abstracted away from you already, except perhaps things such as "is this a disk or is it flash memory" - you're probably not writing disk controller drivers, you're probably calling disk controller drivers). Nobody here is arguing that file systems aren't implemented in software (or firmware); however, a given file system may have multiple collections of code that implement it. Guy Harris (talk) 00:15, 12 November 2012 (UTC)

No, my friend, an "implementation" of something is not concocted by source code or program data in any rational sense. But then again, seriously, this article is not about the fact that a filesystem follows an implementation or specification, it's about what a filesystem is and does. People here seem to be arguably challenging each other on irrelevant areas. The specification a filesystem must use, or will use, doesn't arguably make a filesystem any less software or firmware than if there was no implementation or guidelines. That's like telling a graphics framebuffer that a set of pixels isn't an image because there's no implementation of a specific image, or rules regarding an image, from a GUI. A filesystem's integral purpose isn't solely based on a specification, nor is the definition or existence of it readily used by a specification only. The software works AROUND THE SPECIFICATION! So it is, again, software following a specification. Why, tell me, my friend, am I seeing an article with a starting sentence telling me that my FAT32 is "an abstraction to do something" rather than "software following a specification to do something along an abstraction"? — Preceding unsigned comment added by 174.141.208.113 (talk • contribs) 22:11, 12 November 2012‎ (UTC)

An implementation is, as the article says, "Implementation is the realization of an application, or execution of a plan, idea, model, design, specification, standard, algorithm, or policy." In particular, "In computer science, an implementation is a realization of a technical specification or algorithm as a program, software component, or other computer system through programming and deployment." So, yes, an "implementation" of something could be source code for a program that implements a specification.

And the specification for a file system is, in many cases, a very important part of what the file system is. If you write some code that purports to implement UDF but that doesn't match the spec, it may be file system software, but it's not UDF - if it can't read your DVD, it's not UDF. If you write some code that purports to implement, say, NTFS, but that incorrectly reads files or incorrectly writes to the file system, it may be file system software, but it's not NTFS. And the spec alone, if never implemented, isn't a file system useful in the real world; it might be an interesting source of ideas for a real-world file system, but it won't be storing any data. So, as User:Loadmaster said, "I would say that a "file system" is 1) an abstraction of some logical (and usually physical) layout of data within a storage device that embodies file and directory structures within that device; and 2) the executing file system itself, i.e., the software that actualizes the file system structure upon or within the storage device." A particular piece of software, by itself, isn't "NTFS" or "UDF" or..., it's one particular implementation of NTFS or UDF or, so the software isn't all there is to the file system; there's also the stuff that the software has to do in order to be a valid implementation of NTFS or UDF or..., regardless of how the software is written.

"A set of pixels" isn't like a file system; it's like a set of bits written to the disk. "A set of pixels showing a button the user can click on" is more like a particular file system - an arbitrary set of pixels isn't a button, and an arbitrary set of bits written to the disk isn't an NTFS or UDF or UFS or... file system. So, whilst an arbitrary set of pixels is an image, regardless of any specification, it's not a button unless it at least matches what people expect GUI buttons to look like.

So FAT32 is a way of storing stuff on a storage medium, and the implementation or implementations, in software or firmware (or conceivably hardware, but purely-hardware implementations of file systems are probably pretty rare; embedded-software or embedded-firmware and perhaps even microcode implementations don't count), of that way of storing stuff. Guy Harris (talk) 22:34, 12 November 2012 (UTC)

I'm done debating with you people - you're all totalitarians giving by to what you and others say. I'm a software programmer with hardware knowledge. Why don't we make a deal and I develop a filesystem on an OS and show you how I implement it, and how it actually works. Until then you people can babble and argue till you're blue in the face about the "specifications" of it, but I know how it all works under the code. Good day in your Wiki lives. I'm done. Also, to add one more thing, my set of pixels was an example to the realization of the filesystem, not an EQUIVALENT to a filesystem; again, I'm a developer, and I don't know what you people do, but I'm done wasting time with you. — Preceding unsigned comment added by 174.141.208.107 (talk) 22:44, 12 November 2012 (UTC)

Definition

NTFS-3g (the software) is not NTFS (the file system). When you create a file system with [your favorite partitioning tool here] or mk*fs on Unix/Linux systems, you are definitely not writing software instructions. NTFS is an abstract data structure defined by a technical specification. Different operating systems use different drivers (thus different instructions) to deal with the same file system. However, a kernel driver is often referred to as 'the' file system, though it is technically incorrect. --151.75.122.123 (talk) 15:42, 10 November 2012 (UTC)

Edit: Sorry, replace "it is technically incorrect", with "strictly speaking, it is not". --151.75.122.123 (talk) 11:35, 12 November 2012 (UTC)

Wrong. On the software article, suffice it to say, implementation of a software instructed "machine" would have to entail the environment of all systems, sub-systems, and "instructions" being carried out by the computer's processor and ISA. Therefore, a filesystem would have to have instructions, since it is a specification to tell the processor how the files should be stored on a storage medium. If it didn't give software instructions then it wouldn't be an abstraction. And a kernel's driver IS NOT a file system. A file system is, believe it or not, a specification of software (or instructions) that aid the processor in a task. As a matter of fact, operating system development sites, kernel-specific development sites, and many high-end computer programmers implement the basics of filesystem development and design through higher-level programming languages such as C/C++. Hobbyists developers implement the basic filesystem structure as software written and compiled through upper-level programming languages. How on Earth can someone tell me this isn't some form of "software"? — Preceding unsigned comment added by 174.141.208.99 (talk) 17:09, 11 November 2012 (UTC)

"A file system is, believe it or not, a specification of software (or instructions) that aid the processor in a task." But it's not software, it's a specification for what software must do. There may be more than one piece of software that implements that specification. User:151.75.122.123 isn't saying file systems aren't implemented in software (I'd add "firmware" to that - some boot ROMs, for example, can read file systems), he or she is saying that a file system is not, in general, solely defined by a particular piece of software. Guy Harris (talk) 19:28, 11 November 2012 (UTC)

174.141, I have no doubt you are editing in good faith, but please, do not offer your own reasoning/speculation as if they were facts. Software instructions are machine-coded operations; rather, a specification gives human-worded instructions to humans on how to write software instructions. As I understand it, your sentence "A filesystem is a software to retrieve files" means that it is the driver, and I'm saying that this is not the case. --151.75.122.123 (talk) 22:28, 11 November 2012 (UTC)

And please scurry away from your speculations about my speculations. I am a developer; I write software, know how computers work, and I'm a computer programmer. I know for a fact that a filesystem is software because I've dealt with people who have written one themselves. There is no driver necessary to interact specifically with software, because drivers are software that helps instruct the processor to interact with other hardware devices. Exactly as you put it: "Software instructions are machine-coded operations". A filesystem carries out compiled and linked (usually) source code to machine code byte(s).

The specification on its part to the developer who must implement the code changes no fact that the existence of a file system is ultimately software from either end. Please refrain from trying to debate with me further if this is how you're going to go about with a discussion. I know what I'm saying, my friend. — Preceding unsigned comment added by 174.141.208.101 (talk) 23:42, 11 November 2012 (UTC)

Again, nobody here is saying that file systems aren't implemented in software (some of the code I've written was part of file system implementations). The question is whether the abstract specification that says "here's the data structures on the storage medium" is "software". I think calling it "software" will confuse people who think of "software" as programs - the abstract specification is not a set of machine-code operations (or interpreted-code operations - as I remember, Open Firmware had code that could at least read some file systems, and it was in interpreted Forth code).

As for "driver", unfortunately the term "driver" is not always used to refer to code that runs hardware (or provides pseudo-device functionality - I've written some of that, although OS X autofs's devices are mainly hacks to let the kernel know when a given process has exited...). Microsoft, for example, calls the kernel modules that implement file systems "installable file system drivers". It might be best if a term other than "driver" were used in this discussion to refer to compiled-in or loadable kernel modules that implement file systems, in order to avoid misinterpretation. Guy Harris (talk) 00:36, 12 November 2012 (UTC)

Having been a programmer on a wide variety of architectures (ranging across IBM S/370, AS/400 (iSeries), Unix, DOS, Windows, and several others), I would say that a "file system" is 1) an abstraction of some logical (and usually physical) layout of data within a storage device that embodies file and directory structures within that device; and 2) the executing file system itself, i.e., the software that actualizes the file system structure upon or within the storage device. So you're both right, but we need to clarify in the article whether we're talking about the logical structure or the executing software as a "file system" (or both). When an OS connects to (mounts) a file system, is it simply reading the "system" (in the sense of "logical abstraction system") of logical data structures (files and directories) on a device, or is it also executing a "system" (in the sense of "operating system or subsystem") of code that interprets the raw data on the device as abstract structures? — Loadmaster (talk) 04:45, 12 November 2012 (UTC)

Quoting the article: By extension, the term also identifies software or firmware that implements the abstraction. It's at the beginning. This does include a C++ implementation!

But you cannot define a filesystem as a software until you show the source code of NTFS - not NTFS-3g or the like. Guy Harris has said the rest (and perfectly understood my thought).

You are stating your personal opinion as if it were the facts: "A file system is, believe it or not" (cit. 174.141, 11 nov 17:09). Please don't take my comment above personally. I'd find it odd if anyone writing a file system implementation didn't call the implementation as the file system, most if not all times, and the article is currently saying that it is fine. On my side, I was wrong to say "it is technically incorrect", I'd have worded it as: "strictly speaking, it is not" --151.75.122.123 (talk) 11:23, 12 November 2012 (UTC)

All device drivers are software that helps interact with hardware per se, and there's no changing that.

You may take the terminology of the word "driver" as far to the etymology or history as you wish, but most people who use the term "driver" in computing mean device drivers, or lower-level software to "abstract" the user and/or developer from such a point. There's no such thing as a "device driver" for a filesystem, as it's not hardware it's a system for organizing files in software ON TO hardware. You can debate on the abstraction of it forever if you wish, but it doesn't change the fact that it's software written(regardless of either program code in firmware or not). This article is confusing by telling a user that a filesystem is a piece of abstraction, when it's simply code that entails some form of abstraction like most other things in user space, or from an interface-perspective. By simply telling people and linking them to an article on computer science and abstractions you're throwing them towards a whole new article that has endless babble on abstraction theories in computing, rather than simplifying the software and abstraction in a more straightforward sense. — Preceding unsigned comment added by 174.141.208.101 (talk) 17:04, 12 November 2012 (UTC)

The person who wrote this page, who presumably works for a company involved in computing given that it's a page in that company's Web site for developers of hardware and software, is using the term "driver" to refer to things that doesn't directly control hardware. (And, as per the paragraph two paragraphs down, at least in Windows NT-family OSes, the loadable kernel modules for file systems are in a directory named "Drivers", so I guess Microsoft likes that term.) Personally, I don't like using "driver" for file systems; for better or worse, User:151.75.122.123 did, and that caused some confusion, which is causing some off-topic discussion. As I said above, it would probably be best if "driver" weren't used in this discussion to refer to the modules that implement file systems in operating systems, so that we don't get bogged down in those off-topic disussions.

And, yes, I think the abstraction (computer science) page doesn't make it sufficiently clear at what level the abstraction for a file system exists above the implementation or implementations (plural) for a given file system.

However, I also think that, for at least some file systems, and arguably for most if not all of them, they exist, in a sense, independent of any software or firmware that implements them. Consider, for example, UDF, the latest version of which is specified by this document. Is this "software"? It is a document separate from, for example, the code contained in C:\Windows\System32\Drivers\udfs.sys on Windows, or the code contained in /System/Library/Extensions/udf.kext/Contents/MacOS/udf on OS X, or the code contained in a directory such as /lib/modules/kernel_version/kernel/fs/udf/udf.ko in a Linux distribution, or.... So, at least in the case of UDF, not only is there no single piece of software that "is" UDF, there's also a document that "is" UDF, independent of all those pieces of software. Guy Harris (talk) 18:21, 12 November 2012 (UTC)

Show the source code of NTSF, 151.75.122.123? That's appalling and ridiculous. Just ask Tom Miller from Microsoft who, by the way, is a SOFTWARE DEVELOPER. The abstraction that follows the design and specification for it mean nothing in this case of the debate when the end result is software(or embedded firmware)that embodies a completed and executed filesystem, mounted or not. — Preceding unsigned comment added by 174.141.208.114 (talk) 17:10, 12 November 2012 (UTC)

I suspect Mr. Miller would indicate that there is an internal specification document for NTFS. It's not, as far as I know, a public document, so the implementations of NTFS other than Microsoft's ntfs.sys were developed by reverse engineering involving looking at what public documents do exist and at the contents of NTFS-formatted disks. However, multiple implementations of it exist, so it's not as if ntfs.sys "is" NTFS in some sense stronger than the internal NTFS document being NTFS; ntfs.sys could be argued to be a reference implementation, but that's it.

For UDF, however, as noted above, there is a public specification, which arguably "is" UDF in a sense stronger than any of the several implementations of UDF being UDF. Guy Harris (talk) 18:29, 12 November 2012 (UTC)

NTFS.sys is a device driver in Windows that is used as an "inbetween" to access, read/write, files to a storage medium capable by providing a bridge between software and the kernel to hardware. The file system's specification follows along the guidelines of how it must perform this action in tangible, suitable, or otherwise realistic sense. So NTFS.sys is a device driver, or just driver as most would refer to it, and it uses the filesystem as an intermediary through low-level system calls to retrieve and store information from the kernel to higher-level abstracted user space. However, if you didn't actually see this coming, the filesystem is still not a piece of hardware, it's just used in a piece of low-level software to accordingly read and write blocks of bytes (or whatever term used) to a medium. Disk controller drivers may be unnecessary altogether in some cases. So what you should be crunching up is a new starting sentence for the article: "A filesystem is software (or system software) following a specification to implement the storage of files on a storage medium. The process may or may not involve disk controller device drivers, and may be accessed through device drivers, as in case with Windows OS's NTFS.sys,", etc., etc., etc. Take it or leave it. — Preceding unsigned comment added by 174.141.208.101 (talk) 22:04, 12 November 2012 (UTC)

So presumably you either disagree with User:174.141.208.99, who said "And a kernel's driver IS NOT a file system.", or you disagree that the software that implements NTFS in Windows, namely ntfs.sys, is a file system. If a kernel's driver is not a file system, and ntfs.sys is a driver, then it is not a file system, as it's a driver (and runs in kernel mode), and thus the software that implements a file system (ntfs.sys is the Windows loadable kernel module that implements NTFS) is not itself a file system.

If ntfs.sys "uses the filesystem", what is "the filesystem"? The code that knows what data to read from or write to a storage medium containing an NTFS file system is in ntfs.sys; what other code would it uses that would constitute "the filesystem"?

Or, to put it another way, if "a filesystem is software (or system software) following a specification to implement the storage of files on a storage medium", the software in question, for the NTFS file system on Windows, is stored in a file named ntfs.sys, so, by the definition given in that sentence, ntfs.sys is "the filesystem". Guy Harris (talk) 22:52, 12 November 2012 (UTC)

The real problem with you bitches is that you're not using machine code instructions to CREATE the filesystem. If you're using higher-level languages you're hiding the abstraction from the machine, therefore, you aren't controlling the machine you're depending and relying on another written program to control the machine per se — Preceding unsigned comment added by A00 H (talk • contribs) 22:36, 12 November 2012‎ (UTC)

If this article is "too technical", one might agree that the starting sentence may be the culprit

Most people will read the first few sentences and expect to somewhat get the idea of what they're trying to understand or learn.

Seeing "a filesystem is an abstraction to store, retrieve and update a set of files does no good to the average reader regarding this perplexed starting sentence.

Perhaps we should aim for something along the lines of:

"A filesystem is an implementation of software that acts as an abstraction to store, retrieve, and update a set of file blocks on a storage drive. — Preceding unsigned comment added by 174.141.208.111 (talk) 16:17, 15 November 2012 (UTC)

I'm afraid that doesn't help at all. Writers, you aim to target people who are looking for information when they don't know the subject (very well). It is no good writing in jargon that the writer understands. If they understand it, they don't need the article. If technical writers write in THEIR language, readers don't understand. This is the greatest flaw in Wikipedia, whether it be people writng about science, finance, mathematics or whatever.

Wikipedia has yet to produce an article that explains the credit crunch, for instance, that anyone, including the authors, can properly understand. Cannonmc (talk) 17:30, 5 January 2013 (UTC)

Well, I rewrote the intro to try to make it more understandable. Further improvements welcome. I'm not sure what credit crunch article you are talking about, but I agree it can definitely be a problem in certain subject areas. Fortunately, this is a "flaw in Wikipedia" you can fix by rewriting jargon into beautiful shiny prose. If you don't have the expertise or time, well, that's what the "too technical" tag is on this article for. Editors who do have subject expertise would benefit if you could help them toward something more comprehensible, perhaps by explaining exactly what you are stumbling over or what sort of statement you are looking for. -- Beland (talk) 20:08, 25 March 2013 (UTC)

Why not add source code examples of filesystem implementations in software?

Perhaps C, C++, C#, etc. Even Java, if you will.

This article is pretty terrible. 2 stars at most I'd give it. Not recommending. — Preceding unsigned comment added by 174.141.208.117 (talk) 19:19, 19 November 2012 (UTC)

unsigned int PTR* NULL;

Happy? — Preceding unsigned comment added by 169.139.19.117 (talk • contribs) 21:48, 10 December 2012‎ (UTC)

OK, here's the source code to the ext2 file system, and here's the OS X 10.8.2 version of HFS+, and here's the FreeBSD version of UFS. Copying and pasting that to the article would make it rather big, and I'm not sure even most programmers would be able to understand much of that (obviously it would be complete gibberish to non-programmers). The Unix Version 6 source has a simpler file system - see, for example, the iget.c, nami.c, rdwri.c, and subr.c files, along with the header files (and any other kernel routines they call or are called by), but even that isn't just a simple piece of code that most programmers would necessarily understand.

For people who want to understand how (local) file systems are implemented, Dominic Giampaolo's Practical File System Design with the Be File System book might be better than just a blob of out-of-context source code. As Dominic notes on his home page, he also makes the "File System Construction Kit", mentioned in the appendix of his book, on-line. Guy Harris (talk) 22:13, 10 December 2012 (UTC)

Why!!!??? Who in their right mind wants to read an article that includes source code when all they were trying to do was find out what the article was about. I'm afraid the 'Talk' is even worse than the article. Is it beyond Wikipedia editors to write in plain language that mortals can understand? Cannonmc (talk) 02:48, 6 January 2013 (UTC)

Those source codes for those filesystems are easy to understand. Any decent programmer with knowledge of storage drives should be able to break that code down in a matter of minutes. It makes perfect sense to me. — Preceding unsigned comment added by 169.139.19.117 (talk) 22:35, 4 February 2013 (UTC)

Then add links to them, maybe, but if you pasted even the source code to the V6 file system, the article would bloat up. And I'm skeptical that "Any decent programmer with knowledge of storage drives should be able to break that code down in a matter of minutes." - maybe those of us who've had some experience with file systems already might, but if all you know about is storage drives, i.e. linear arrays of fixed-size blocks, a little tutorial information, such as Dominic's book, would be better. Guy Harris (talk) 23:15, 4 February 2013 (UTC)

Wikipedia is targeted at a general audience, not merely programmers. For a top-level article, source code is such an intricate level of detail that it would both not be appropriate to a general audience and it would be too detailed for this article (which is already on the long side). I don't think any filesystem-implementing source code is needed on Wikipedia, but I do agree that links to source would be helpful for technical readers who want to know more. I would start with putting them on the articles about the specific filesystem in question, though. -- Beland (talk) 19:59, 25 March 2013 (UTC)

There is a clear consensus that adding source code is not a good idea. I suggest we close this discussion thread. Jjk (talk) 14:00, 19 September 2013 (UTC)

Semantic File System

Why is there no link from this article to https://en.wikipedia.org/wiki/Semantic_file_system — Preceding unsigned comment added by B0ef (talk • contribs) 14:13, 12 March 2017 (UTC)

Because nobody's added one. Guy Harris (talk) 18:18, 12 March 2017 (UTC)

LOL :) Stevebroshar (talk) 17:22, 16 March 2024 (UTC)

Proposed merge with Disk quota

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

To not merge Disk quota given that no consensus for any particular target after more than a year and discussion stale. The is some interest in renaming or restructuring this page. Klbrain (talk) 17:20, 27 April 2019 (UTC)

---

The article Disk quota is largely a WP:DICTDEF. Disk quotas are not discussed at all at File system currently, and they probably should be. power~enwiki (π, ν) 21:58, 24 October 2017 (UTC)

Actually Disk quota and the UNIX part of this article should be moved to Unix_File_System and the UNIX section in File system should be reduced and point to the main article. Disk quotas it seems are a UNIX issue and belong there not here. Tom94022 (talk) 18:18, 8 January 2019 (UTC)

Disk quotas don't seem to be a UNIX issue to anybody familiar with Windows or {Open}VMS, for example. Disk quota#Quotas even mentions those OSes in the last paragraph.

Furthermore, whilst the Unix File System, in the sense of "the file system that was originally called the Fast File System in BSD", was probably the first Unix file system to support disk quotas, it's not the only file system for Unix that supports disk quotas. (Heck, Apple even added disk quota support to the not-originally-designed-for-Unix HFS+

So, no, disk quota should most definitely not be moved to Unix File System - and "the UNIX section in File system" - by which you presumably mean file system#Unix and Unix-like operating systems - shouldn't be reduced and point to Unix File System, given that said section lists a whole bunch of file systems for Unix-like operating systems (whether derived, in whole or in part, from AT&T code, and whether licensed to use the Unix trademark) that aren't UFS. Guy Harris (talk) 19:07, 8 January 2019 (UTC)

For that matter, RSTS-11 had disk quotas at least as far back as February 1975, before even Version 6 Unix, much less 4.2BSD (the first big UNIX flavor with disk quotas), had been released. (One of the earliest Unix implementations of disk quotas was the University of Melbourne implementation; it was the basis of the version incorporated into 4.2BSD.) Guy Harris (talk) 21:00, 8 January 2019 (UTC)

OK, like most users, "disc quotas will either be of no concern, or a fact of life that cannot be avoided." Since they are in multiple file systems then I suggest the disk quota article should remain as the main article with a link from this article. I also suggest that the the UNIX part of this article should be moved to Unix_File_System as the main article with only a link in this article. Tom94022 (talk) 00:46, 9 January 2019 (UTC)

Why should a section that discusses a whole bunch of different file systems, most of which are not the Berkeley Fast File System, be moved to a page about the Berkeley Fast File System?

Are you suggesting that the Unix File System page change from a page about the Berkeley Fast File System, as it is now, to a page about file systems, plural, for Unix? If so, then note that a better choice would be to rename Unix File System to "Berkeley Fast File System" or something such as that, and then create a page called "Unix file systems" or "List of file systems for Unix" or something such as that, and move the stuff in the UNIX part of this article to the latter page.

The name nonwithtanding, there is no such thing as "the" Unix file system, for "file system" referring to a particular design for an on-disk layout of file system data. When the Berkeley Fast File System was being developed, there was already a file system in common use on UNIX - the V7 file system - so the FFS was at best the second file system for UNIX (third if you count the V6 file system; we'll ignore earlier ones as they weren't generally available). Now, there are and have been several on-disk file systems for Unix and Unix-like systems in addition to the V7 file system and the Berkeley Fast File System, such as ZFS, APFS, JFS, ext2/ext3/ext4, btrfs, VxFS, XFS, AdvFS, and HAMMER, as well as HFS+ (which was not originally designed for a UNIX, but was the main on-disk file system for macOS/iOS/tvOS until the switch to APFS).

I think it's reasonable to have a page that discusses the Berkeley Fast File System, including its evolution (UFS2, etc.). I don't think it's reasonable to have that page talk about other file systems designed for, or used as the primary file system on, UN*X systems. Guy Harris (talk) 02:29, 9 January 2019 (UTC)

As for whether disk quota should be merged here or not, the fact that disk quotas are supported by multiple file systems is not sufficient to indicate that it shouldn't be moved here. The question there is whether it's a topic of sufficient interest to be worthy of its own article or if it's just an aspect of a file system or an aspect of space management of a file system that should be moved here. Guy Harris (talk) 02:39, 9 January 2019 (UTC)

@Guy Harris: makes a number of good points:

• IMO Disk quota should remain as a separate article with a pointer in this article to it as the main article.
• Regarding Unix File System article, it probably should be renamed to Berkeley File System with a new article Unix File Systems (plutral) created from the material in this article and linking to all the various articles. Alternatively, I suppose this article's section could be come the main article with a redirect from Unix File Systems (plutral); that's inconsistent with the treatment of other file systems in this article, but a foolish conisistency ...

My 2 cents :-) Tom94022 (talk) 20:11, 25 January 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

References

Comments on "Multiple file systems.." section

I suspect this entire section is beyond the scope of what is needed for the general population. It also has a lot of statements that appear false or misleading if taken at face value.

• Para 2 needs to discuss partitions in general before talking about multiple file systems. Article seems to ignore, or at least gloss over, having multiple disk drives in a system.
• Para 2 discusses having partitions with different allocation sizes. This can also be done with the same file system. See, for example, [4].
• Para 2 mentions that one file system could be read-only and the other writable. This is also unrelated to "multiple" file systems.
• I doubt that the comments in para 3 discussing virtualization, ext4, ntfs, and hypervisor are understandable to anyone who doesn't already grasp these concepts.
• Likewise, it seems to me that almost everything in para 4 can be done with a type of single file system on multiple partitions.

If this section is deemed useful, then at this point I think the simplest approach would be to change the heading to something like Multiple partitions within a single system (ugh) and revise to article to eliminate almost all references to "file system". If that is too simplistic, then IMO this entire section needs to be rewritten with the differences between partitions and file systems firmly in mind.

-Jvasil (talk) 23:24, 12 August 2020 (UTC)

I agree that the section is hard to read, but I think there is good info in there. I just spent a few hours working on this article and am too tired to work on this section rn. ...Maybe the section should be titled Partitions Stevebroshar (talk) 17:20, 16 March 2024 (UTC) Stevebroshar (talk) 17:22, 16 March 2024 (UTC)

The machine on which I'm typing this has several file systems on its SSD, but they're not on separate partition - they share a single free-space pool. The file systems are APFS, but, if I remember correctly, ZFS also supports that, and other file systems may do so as well. Guy Harris (talk) 20:05, 16 March 2024 (UTC)

Interesting that you use 'file system' to mean an instance. I think of file system as a service that acts on storage. To me 'database engine' is to 'file system' as 'database' is a storage configured for a file system. ... Anyway, how can multiple file systems (instances) share the same storage? How do they not clobber each other? Are the multiple instances of APFS configured to co-exist? Or do they share conventions that prevent incompatible access to the same storage? Stevebroshar (talk) 03:12, 17 March 2024 (UTC)

Interesting that you use 'file system' to mean an instance. Apple tends, I think, to use the term "volume", but the term "mounted file system" is one term used in UN*Xland.

Anyway, how can multiple file systems (instances) share the same storage? How do they not clobber each other? They share a common pool of free storage, and use block numbers within the container rather than the volume. See, for example, the "Free Space Is Shared Between Volumes" section of [ the About Apple File System and the "Container" section in the Apple File System Reference.

This is not a concept unique to APFS. In ZFS, multiple datasets (think "volumes", in Apple terminology, or "mountable file systems") can share the same zpool (storage pool). Guy Harris (talk) 21:52, 11 April 2024 (UTC)

"Apple File System supports multiple volumes within a single partition" ... "All of the volumes in an Apple File System partition can grow and shrink independently" ... so, volume is not synonymous with file system. I think a partition can have one and in some cases multiple volumes. I think a partition can only one file system. Stevebroshar (talk) 17:52, 12 April 2024 (UTC)

In "Apple File System", "File System" means "on-disk data structures (and algorithms to implement operations on those data structures)", so there's only one such file system on the planet, with many instances of that file system on my laptop, my cell phone, and all the other watches/eyeglasses/cell phones/tablets/set-top boxes/speakers/laptop computers/desktop computers out there. The same applies to HFS+, UFS, ext2/ext3/ext4, btrfs, ZFS, etc.

On my laptop, there's a hierarchical directory structure that spans multiple volumes:

   $ mount
   /dev/disk1s1s1 on / (apfs, sealed, local, read-only, journaled)
   devfs on /dev (devfs, local, nobrowse)
   /dev/disk1s3 on /System/Volumes/Preboot (apfs, local, journaled, nobrowse)
   /dev/disk1s5 on /System/Volumes/VM (apfs, local, noexec, journaled, noatime, nobrowse)
   /dev/disk1s6 on /System/Volumes/Update (apfs, local, journaled, nobrowse)
   /dev/disk1s2 on /System/Volumes/Data (apfs, local, journaled, nobrowse)
   /dev/disk1s7 on /Volumes/Case-sensitive (apfs, local, journaled)
   map auto_home on /System/Volumes/Data/home (autofs, automounted, nobrowse)
   /dev/disk1s1 on /System/Volumes/Update/mnt1 (apfs, sealed, local, journaled, nobrowse)

with some weirdness (e.g., /Users is on /System/Volumes/Data, but /Users isn't a symlink - this is something Apple added). That directory structure could be considered the "file system" on that laptop.

And, as noted, there are several volumes, which are, in some sense, self-contained sets of files (although some of them share a single free block store with each other, as noted above), each of which is mounted on a given mount point, making them "mounted file systems". In what way are all of the volumes within one partition a single "file system", other than storing a common storage pool?

So it's not clear that there's a single referent for the term "file system". Guy Harris (talk) 20:22, 12 April 2024 (UTC)

exFAT update needed

Please update the section about exFAT. It's already disclosed to public domain and supported by linux kernel 213.228.137.159 (talk) 08:35, 14 November 2023 (UTC)

Edited

In general, this article is too long. Surely it goes off topic. But, I didn't remove much. Just noted that.

Like other pages I've looked at and edited, this one is for a popular tech topic with a long history. It has been edited a zillion times and suffers from drift -- in focus and in quality.

I edited the lede and a few sections after that. By page 20 I lost interest :)

Notes on what was wrong and why I edited:

• A file system is not a data structure even though it does involve data and structure and an implementation surely includes various data structures
• Removed duplicate etymology info from lede since didn't add value (as duplicate) and lede was too long anyway. Also renamed section on etymology as 'etymology'
• The history and market share of HDD is off topic, removed
• Distinguished between local vs distributed file systems throughout

Stevebroshar (talk) 17:12, 16 March 2024 (UTC)