File Systems: Difference between revisions

Undo revision 28897 by Drkeph (talk) duplicate line removed
[unchecked revision][unchecked revision]
No edit summary
(Undo revision 28897 by Drkeph (talk) duplicate line removed)
 
(25 intermediate revisions by 11 users not shown)
Line 3:
{{Filesystems}}
 
File systems are the machineoperating system's waymethod of ordering your data on readablepersistent and/orstorage writabledevices medialike disks. They provide aan logicalabstracted wayinterface to access thedata stuffon thatthese youdevices havein downsuch ona disk soway that youit can be read or modifymodified itefficiently. Which file system youis useconvenient depends uponon whatthe youtarget wantapplication toof dothe withoperating itsystem. For example, Windows uses the FAT32 or NTFS file system. If youra disk ishas reallya hugelarge capacity, thenFAT32 there'sis no point using FAT32inconvenient, because the FAT system was designed inconsidering the days when nobody hadsmaller disks asavailable bigat asthat we do nowtime. At the same time, there'san noNTFS pointfile usingsystem ais NTFSnot file systemconvenient on a tiny disk, because it was designed to work with large volumes of data - the overheadthere would be pointlessexcessive for,overhead say,when readingusing devices such as a 1.44 MB floppy disk.
 
For details on specific filesystems, browse [[:Category:Filesystems|this list]] of filesystems.
Line 11:
{{In Progress}}
 
A filesystem provides a generalized structure over persistent storage, allowing the low-level structure of the devices (e.g., disk, tape, flash memory storage) to be abstracted away. Generally speaking, the goal of a filesystem is allowallowing logical groups of data to be organized into ''files'', which can be manipulated as a unit. In order to do this, the filesystem must provide some sort of index of the locations of files in the actual secondary storage. The fundamental operations of any filesystem are:
 
* Tracking the available storage space
Line 78:
=== "Beginners" filesystems ===
There are only five filesystems that are both relatively easy to implement and worth to consider. There is no general recommendation as the choice depends largely on style and OS design. Instead you can read the comparison and make your own educated decision.
 
'''[[USTAR]]'''
* <code>+</code> Of these beginner "filesystems", this is the simplest by far to implement
* <code>+</code> Incredibly simple,: a sector with meta datametadata followed by data sectors
* <code>+</code> Widely used,: utilityutilities to create tar images are available for every mainstream OS and many minor ones
* <code>+</code> Supports special files (like devices and symlinks)
* <code>+</code> Supports Unix permissions
* <code>-</code> Not a filesystem in the common understanding of the term
* <code>-</code> Generally read-only, was never designed for in-place modifications
* <code>-</code> No support for fragmentation
* <code>-</code> No standard partition type for it, (not that you'll haveshould even consider using toUSTAR pickas onea ondisk yourpartition ownformat)
* <code>-</code> Not actually the format used for ramdisks by things like Linux - that's CPIO
 
'''RAMFS/TMPFS'''
* <code>+</code> High flexibility of implementation
* <code>+</code> Minimal overheadFast
* <code>+</code> Will allow you to test out your VFS API without having to rely on filesystem specifics
* <code>+</code> *Highly* recommended as a starter filesystem to avoid morphing your VFS interface around a specific filesystem
* <code>+</code> Ideal to unpack a [[USTAR]] or [[CPIO]] [[initrd]] image into
* <code>-</code> Changes are, obviously, not persistent, and only in memory, to be wiped after a reboot
 
'''[[FAT]]'''
Line 87 ⟶ 107:
* <code>-</code> No support for large (>4 GB) files
* <code>-</code> No support for Unix permissions
 
 
'''[[Ext2]]'''
Line 97 ⟶ 116:
* <code>-</code> Very large overhead
* <code>-</code> Of these beginner filesystems, this is the most complex
 
 
'''[[SFS]]'''
* <code>+</code> Supports large files
* <code>+</code> By far the easiest to implement
* <code>+</code> Can be put on floppies and harddisks
* <code>+</code> Minimal overhead
* <code>-</code> New, and therefore unsupported. The only operational utility is available for Windows.
* <code>-</code> No support for fragmentation
* <code>-</code> No support for Unix permissions
 
'''[[BMFS]]'''
Line 116 ⟶ 125:
* <code>-</code> Does not support fragmentation
* <code>-</code> Less control over the source code
 
'''[[USTAR]]'''
* <code>+</code> Uses 512 byte sectors just like floppies and disks
* <code>+</code> Incredibly simple, a sector with meta data followed by data sectors
* <code>+</code> Widely used, utility to create tar images are available for every mainstream OS
* <code>+</code> Supports special files (like devices and symlinks)
* <code>+</code> Supports Unix permissions
* <code>-</code> No support for fragmentation
* <code>-</code> No standard partition type for it, you'll have to pick one on your own
 
 
'''[[ISO 9660]]'''
The defined standard for CDs. If you boot from CD then this is the way to go. If not, don't make it your first filesystem.
 
'''[[SFSPureFS]]'''
* <code>+</code> By far the easiestEasy to implement
* <code>+</code> Supports large files
* <code>+</code> Supports nested directories
* <code>-</code> No support for Unix permissions
* <code>-</code> It can be journalable, provided that the OS takes care of this task itself
* <code>-</code> The maximum length of the file name is 255 characters
* <code>-</code> The maximum number of volumes is 40
* <code>-</code> NoDoes not support forUnicode fragmentationnames
* <code>-</code> Takes up a lot of space
 
=== Rolling your own ===
There are many different kinds of filesystems around, from the well-known to the more obscure ones. The most unfortunate thing about filesystems is that every hobbyist OS programmer thinks that the filesystem they design is the ultimate technology, when in reality it's usually just a copy of FAT with a change here and there, perhaps because it is one of the easiest to implement. The world doesn't need another FAT-like filesystem. Investigate all the possibilities before you decide to roll your own.
 
If despite of this warning you decide to create your own file system, then you should start that by implementing a [[FUSE]] driver for it. This gives the advantage that you can mount your file system image as any other storage device, and you can lists its contents, create new files and directories etc. with standard tools. FUSE is available for Linux, MacOSX and Windows as well.
 
==== Guidelines if you do decide to roll your own ====
<br />
* Consider carefully what it will be used for.
* Use a program to figure out the layout (e.g. a spreadsheet). The basic areas needed are:
** Bootsector. This is essential for booting on some systems such as BIOS-x86 and Atari ST, unnecessary for others such as UEFI and OpenFirmware. Even if you don't intend to boot on systems which require it, reserving the first sector will allow your OS to be ported to them at a later time. Note that reserving space for a MBR-like partition table is needed to allow the filesystem to work in "logical partitions".
** Bootsector. Unless you are booting with UEFI, this is a must. Even then, I'd recommend including it in the specs for compatibility with older file systems. This section should contain at a minimum the disk size, location of the file table, hidden sectors for multiple partition disks, and a version number. I'd be leaving plenty of reserved space for features you don't think of. Don't forget to leave space for a jmp instruction and the boot code!.
** Partition metadata. This could fit into the first sector with the boot code, or be a separate group of sectors at a specific location. (FAT puts it in the first sector, calling it the FAT parameter block. ext* use a separate location, calling it the superblock.) At a minimum, this should contain the filesystem size, location of the file table, and a version number. Leave plenty of reserved space for features you don't think of. If you put it in the first sector, don't forget to leave space for a jmp instruction, the boot code, and a partition table!
** File table. Don't think of this as just a simple table containing a list of files and their locations. One idea I've had and never implemented is, instead of storing files, the system would store file parts, and the file table would list the parts in each file. This would be useful for saving space if many files on the disk are the same or similar (for example, license agreements).
** Data area. Files will be stored here.
* Create a program to read and write disk images with your filesystem. Parts of this will be portable into the fs driver.
* It is strongly recommended to create a [[FUSE]] driver for your file system.
* Implement the fs into your OS.
 
Line 146 ⟶ 159:
Once you have a beginner's file system under your belt you might want support for more advanced ones. Here are some:
*[[NTFS]] - (Windows) New Technologies File System. It's hard to find documentation. Try [http://www.opensource.apple.com/source/ntfs/ Apple NTFS (open source)].
*Btrfs - B-tree file system. It's a Linux file system with features such as copy-on-write and transparent compression.
 
== See Also ==
* [[I use a Custom Filesystem - What Bootloader Solution is right for me%3F]]
=== Wiki Pages ===
 
[[I use a Custom Filesystem - What Bootloader Solution is right for me%3F]]
=== WikiExternal Pageslinks ===
* [https://blog.koehntopp.info/2023/05/05/50-years-in-filesystems-1974.html 50 years in filesystems] -- an approachable account of the history of file systems. Includes, among other information, some real-world examples of heuristics one can use to avoid fragmentation.
 
[[Category:OS theory]]
Anonymous user