I was wondering if a file system on a storage device is part of OS?

I don't think it is. Instead it is part of the storage device, and exists outside of any OS although was created by an OS. Is my understanding right?

However in Wikipedia:

Most operating systems provide a file system, as a file system is an integral part of any modern operating system.

For LVM, is it part of the OS? If yes, then the virtual filesystem built on LVM is part of the OS?

  • Since the OS itself resides within the file system, I would say it is an integral part of the OS, no way around it. – Moab Jun 4 '11 at 1:50
  • According to your reason, isn't OS part of file system more suitable than the reverse? – Tim Jun 4 '11 at 1:54
  • Actually I think a file system is a requirement of the storage medium, since an OS can reside in memory without using a hard disk or other storage device. – Moab Jun 4 '11 at 3:38

The filesystem itself, represented by the physical order of information on a storage-representation, is independent of the OS. The OS contains a driver that allows it to work with the filesystem. Some filesystems may only have one OS that can talk to it, and that OS has that filesystem hardcoded into it (think Novell NetWare's original filesystem); but that doesn't stop some enterprising person from writing such a driver for another OS just because.

LVM isn't a filesystem, it's a volume manager. Volume managers, like filesystems, rely upon data stored on a logical storage presentation to further define how to access that storage for further logical volumes. In the case of LVM, both Linux and the BSDs can use the same on-storage format for their respective LVM implementations.

The Windows volume manager is the Dynamic Disk, and some enterprising people have created Linux drivers for accessing them.

If you were to take a set of disks, install a Linux of some kind, set them up with LVM, install several ext3 filesystems on the logical volumes and then place the drives in a FreeBSD machine, that FreeBSD machine would be able to read the disks. Probably. This is because FreeBSD has drivers that understand the physical layout of both LVM and ext3, and implement required in-OS memory and access structures required to interact with them.

The drivers required to interpret storage layout are almost always "in the OS", but the actual storage layout itself is not considered to be.


I answered this over on ServerFault. Here's the answer again:

The problem here is the word "filesystem". In the POSIX/Unix/Linux worlds, it is used to mean several different things.

  1. The "filesystem" is sometimes the entire system of files, rooted at / and as presented to applications softwares by the operating system kernel. With this meaning, people talk of POSIX operating systems having a "single filesystem tree", for example.
  2. A "filesystem" is sometimes one (or more) slice(s) of a (or several) direct-access storage device(s) or DASD(s) — one or more collections of contiguous disc sectors formatted as a single volume with a given format — as demarcated by some disc partitioning scheme. With this meaning, people talk of, say, "formatting my /usr filesystem".
  3. A "filesystem" is sometimes an abstract joinable tree of files and directories, presented by a filesystem driver (i.e. the VFS layer) to the rest of the system. With this meaning, people talk of, say, "mounting the proc filesystem on /proc".

Wikipedia's prose is meaning #1. This is, indeed, part of the operating system, as it is an operating system supplied, and operating system specific, abstraction provided to applications software that run on the operating system.

Meaning #2 is not part of the operating system. It is an on-disc data structure that one or more operating systems are capable of understanding. The on-disc data structures for LVM, specifically, provide ways to slice up one or more DASDs into one or more volumes. They aren't part of the operating system per se. (But, similarly, "LVM" has multiple meanings, and can mean the LVM drivers and utilities in the operating system as much as it can mean the on-disc data structures that those drivers and utilities manipulate. e.g. "I ran LVM from the rescue disc.")

Meaning #3 is an operating system specific abstraction provided by operating system specific filesystem drivers. The filesystem drivers are, indeed, part of the operating system, although they are usually distinct and separate from the operating system kernel.


A file system is created, maintained, and used by an operating system but you are right to conclude that its representation can exist independent of an operating system.

  • All the responses are worthwhile, this one is the major take away. – conner.xyz Nov 20 '15 at 15:45

There is no formal definition of "operating system". Some used to maintain that "operating system" and "file management API" were one and the same, with the OS having nothing else to do other than provide a command analyzer. (After all, this is all that MS-DOS did, originally.)

I've always maintained that DOS wasn't a real operating system -- that an operating system's job is to abstract and virtualize the hardware, and to manage hardware resources. DOS did essentially none of that.

As to whether a file system is a part of the OS or a part of the "storage device", a lot depends in turn on what you mean by "file system". There is the physical layout, such as the layout on a floppy disk or CD, and there is the file system FUNCTION, which depends on having some intelligent entity (CPU or peripheral processor of some sort) to take the nonsense on the disk and return it as a meaningful sequence of bytes. The layout presumably conforms to some standard, so you can, eg, record a CD on one device and read/play it on another. The question is whether this layout is a "file system", or whether the "system" resides in the devices clever enough to read/write the layout.

In most computer contexts, one uses the term "file system" to refer to the APIs that allow you to read/write files, and the combination of CPU and peripheral devices, operating under the control of some OS, that implement those APIs -- the term does not usually refer to the physical format of the media, or individual media, whether removable or not.

  • Interesting points. – Maxpm Jun 4 '11 at 4:39
  • Even in MS-DOS, the OS was MSDOS.SYS, and the command-line shell was COMMAND.COM. – user1686 Jun 4 '11 at 8:48

The particular implementation is part of the OS. The abstract idea, specifications, and stored data aren't.


Disk drives and disk drive-like devices are "dumb." You ask it for an LBA, it gives you back the 512, 2048, or 4096 bytes that it contains; vice versa for writing.

A filesystem layer lets you say "I want c:\users\public\documents\whatever.doc" and perform streaming operations on that (open, read, write, seek, close) - it translates from name-addressable locations to a series of requests to read/write LBAs.

So the filesystem layer has two sides, the one side that communicates with the disk drive-like (or block) device, and the other side that talks to the operating system. This is where specificity to the operating system comes into play. Usually the block device side of the filesystem is a device driver, and the operating system side is an API useable by applications. But these are just interfaces and don't really have to affect the underlying operation of the filesystem layer.

All filesystems cause additional data to be written and read outside file data, in order to keep track of information about files, i.e. to record permissions, attributes, etc.

There is a bit of chicken-and-egg problem with booting - as operating system files are stored on the filesystem, but how are they loaded if the filesystem layer is not active yet? Linux solves this issue with either an initial ram disk or by building in the filesystem code as part of the kernel. Windows solves this issue by giving the Windows bootloader the ability to read FAT and NTFS partitions. Bootloaders can be dumb, like most classic BIOS bootloaders which only load LBA 0 and execute it and expect that code to pick up afterwards, or fairly intelligent and with small filesystem layers of their own, such as UEFI, U-boot, etc.

LVM is not a filesystem. It takes one or more block devices and abstracts it into another "virtual" block device (in /dev/mapper - anything in /dev/mapper is a virtual block device). You put a filesystem "on top of" an LVM in the same way you would put a filesystem "on top of" a partition. LVM is another layer in between one or more device drivers and the filesystem, converting reads and writes to LBAs on the virtual block device to one or more other block devices. Yes, an LVM can be a virtual block device and you can have a cascade of them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.