Skip to main content
added 85 characters in body
Source Link
Petr Skocik
  • 29.6k
  • 18
  • 90
  • 154

The way I see it, a filesystem, in the UNIX sense, is a way of implementing a directory tree (directory structure), or more precisely, a way of implementing the UNIX filesystem API. The root file system is backed by one particular implementation, and whenever you enter a mountpoint directory, you enter a subtree that's backed by something different.

The interface is always the same, but in one case, you have a particular disk partition at the back end, in another case, there will be a program that never even writes to a storage device. The proc filesystem will be backed by software that exposes kernel internals; an tmpfs will be backed up by software that writes to RAM, and other file systems might write to the network or elsewhere.

In the non-UNIXy sense of the word, a file system is a way of organizing data storage. ext4, btrfs, fat, and ntfs are file systems in this sense, but also in the UNIXy sense—they implement the filesystem API. proc wouldn't classify as a filesystem within this, more limited, paradigm as it doesn't organize data storage.

TL;DR:

  • directory structure/tree = front end
  • file system = back end

The way I see it, a filesystem, in the UNIX sense, is a way of implementing a directory tree (directory structure), or more precisely, a way of implementing the UNIX filesystem API. The root file system is backed by one particular implementation, and whenever you enter a mountpoint directory, you enter a subtree that's backed by something different.

The interface is always the same, but in one case, you have a particular disk partition at the back end, in another case, there will be a program that never even writes to a storage device. The proc filesystem will be backed by software that exposes kernel internals; an tmpfs will be backed up by software that writes to RAM, and other file systems might write to the network or elsewhere.

In the non-UNIXy sense of the word, a file system is a way of organizing data storage. ext4, btrfs, fat, and ntfs are file systems in this sense, but also in the UNIXy sense—they implement the filesystem API. proc wouldn't classify as a filesystem within this paradigm as it doesn't organize data storage.

The way I see it, a filesystem, in the UNIX sense, is a way of implementing a directory tree (directory structure), or more precisely, a way of implementing the UNIX filesystem API. The root file system is backed by one particular implementation, and whenever you enter a mountpoint directory, you enter a subtree that's backed by something different.

The interface is always the same, but in one case, you have a particular disk partition at the back end, in another case, there will be a program that never even writes to a storage device. The proc filesystem will be backed by software that exposes kernel internals; an tmpfs will be backed up by software that writes to RAM, and other file systems might write to the network or elsewhere.

In the non-UNIXy sense of the word, a file system is a way of organizing data storage. ext4, btrfs, fat, and ntfs are file systems in this sense, but also in the UNIXy sense—they implement the filesystem API. proc wouldn't classify as a filesystem within this, more limited, paradigm as it doesn't organize data storage.

TL;DR:

  • directory structure/tree = front end
  • file system = back end
added 37 characters in body
Source Link
Petr Skocik
  • 29.6k
  • 18
  • 90
  • 154

Directory structure seems a little ambiguous to me. I think "directory tree" is less so.

The way I see it, a filesystem, in the UNIX sense, is a way of implementing a directory tree (ordirectory structure), or more precisely, a way of implmentingimplementing the UNIX filesystem API). The root file system is backed by one particular implementation, and whenever you enter a mountpoint directory, you enter a subtree that's backed by something different.

The interface is always the same, but in one case, you have a particular disk partition at the back end, in another case, there will be a program that never even writes to a storage device. The (a procproc filesystem will be backed up by software that exposes kernel internals, a tmpfsinternals; an tmpfs will be backed up by software that writes to RAM, and other file systems might write to the network, etc) or elsewhere.

In the non-UNIXy sense of the word, a file system is a way of organizing data storage. (ext4ext4, btrfsbtrfs, fatfat, and ntfsntfs are file systems in this sense, but also in the UNIXy sense--theysense—they implement the filesystem API;API. /procproc wouldn't classify as a filesystem within this paradigm as it doesn't organize data storage).

Directory structure seems a little ambiguous to me. I think "directory tree" is less so.

The way I see it, a filesystem in the UNIX sense is a way of implementing a directory tree (or a way of implmenting the UNIX filesystem API). The root file system is backed by one particular implementation, and whenever you enter a mountpoint directory, you enter a subtree that's backed by something different.

The interface is the same, but in one case, you have a particular disk partition at the back end, in another case, there will be program that never even writes to a storage device (a proc will be backed up by software that exposes kernel internals, a tmpfs will be backed up by software that writes to RAM, other file systems might write to the network, etc).

In the non-UNIXy sense of the word, a file system is a way of organizing data storage (ext4, btrfs, fat, and ntfs are file systems in this sense, but also in the UNIXy sense--they implement the filesystem API; /proc wouldn't classify as a filesystem within this paradigm as it doesn't organize data storage).

The way I see it, a filesystem, in the UNIX sense, is a way of implementing a directory tree (directory structure), or more precisely, a way of implementing the UNIX filesystem API. The root file system is backed by one particular implementation, and whenever you enter a mountpoint directory, you enter a subtree that's backed by something different.

The interface is always the same, but in one case, you have a particular disk partition at the back end, in another case, there will be a program that never even writes to a storage device. The proc filesystem will be backed by software that exposes kernel internals; an tmpfs will be backed up by software that writes to RAM, and other file systems might write to the network or elsewhere.

In the non-UNIXy sense of the word, a file system is a way of organizing data storage. ext4, btrfs, fat, and ntfs are file systems in this sense, but also in the UNIXy sense—they implement the filesystem API. proc wouldn't classify as a filesystem within this paradigm as it doesn't organize data storage.

Source Link
Petr Skocik
  • 29.6k
  • 18
  • 90
  • 154

Directory structure seems a little ambiguous to me. I think "directory tree" is less so.

The way I see it, a filesystem in the UNIX sense is a way of implementing a directory tree (or a way of implmenting the UNIX filesystem API). The root file system is backed by one particular implementation, and whenever you enter a mountpoint directory, you enter a subtree that's backed by something different.

The interface is the same, but in one case, you have a particular disk partition at the back end, in another case, there will be program that never even writes to a storage device (a proc will be backed up by software that exposes kernel internals, a tmpfs will be backed up by software that writes to RAM, other file systems might write to the network, etc).

In the non-UNIXy sense of the word, a file system is a way of organizing data storage (ext4, btrfs, fat, and ntfs are file systems in this sense, but also in the UNIXy sense--they implement the filesystem API; /proc wouldn't classify as a filesystem within this paradigm as it doesn't organize data storage).