No filesystem is same as no Operating System?

Question

Some legacy computers/controllers don't have the filesystem with them is that because these devices don't have an Operating System? If files cannot be saved to these devices, how can the factory control logic/program and other data get saved to the device?

Answer 1

Filesystem is basically the method for storing files in memory.

Memory devices, such as hard disks, flash drives, optical disks, memory cards etc. can store a fixed number of bytes. An empty, erased, 48-byte memory contains this:

00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

Now, let's say I have two text files

1. First one is called Greetings.txt and contains the word Hello.
2. The other is called Username.txt and contains the word gronostaj.

Files are encoded using ASCII, so each letter corresponds to one byte. After encoding using ASCII, the files' bytes are:

1. Name 47 72 65 65 74 69 6e 67 73 2e 74 78 74

   Contents 48 65 6c 6c 6f

2. Name 55 73 65 72 6e 61 6d 65 2e 74 78 74

   Contents 67 72 6f 6e 6f 73 74 61 6a

(I'm using hexadecimal values from the second column in table on that website.)

I can put first file's contents in our memory like this:

48 65 6c 6c 6f 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

There are some issues, though.

• What if I want to place a second file in the memory? How will I know where one file ends and the other begins?
• Files have names, how do I store these?

To solve these, we can invent a simple filesystem. Let's say that we interleave file names with their contents, so that every file name is followed by content of that file, and separate them with zero bytes. Two sequential zero bytes mean "no more files".

47 72 65 65 74 69 6e 67    <- first 8 bytes of name 1
73 2e 74 78 74 00 48 65    <- next 5 bytes of name 1, then 00, then 2 bytes of content 1
6c 6c 6f 00 55 73 65 72    <- next 3 bytes of content 1, then 00, then 4 bytes of name 2
6e 61 6d 65 2e 74 78 74    <- next 8 bytes of name 2
00 67 72 6f 6e 6f 73 74    <- 00, then 7 bytes of content 2
61 6a 00 00 00 00 00 00    <- 2 bytes of content 2, then 00 00, so no more files

Or the same thing, but without ASCII encoding: (we can't store it in memory like that, it's just for the sake of readability)

 G  r  e  e  t  i  n  g
 s  .  t  x  t 00  H  e
 l  l  o 00  U  s  e  r
 n  a  m  e  .  t  x  t
00  g  r  o  n  o  s  t
 a  j 00 00 00 00 00 00

A real filesystem would also:

• Store file creation and modification dates, attributes, permissions, metadata and other stuff
• Contain some sort of table of contents so that files can be accessed almost immediately, without scanning entire disk until they are found
• Support directories
• Support files and file names that contain 00 bytes
• Be able to recover from some failures
• Support changing length of file without moving following files

But you get the idea.

Now, operating systems. Operating systems for most computers consist of files, so you need a filesystem to store operating system in it. But you could create a monolithic OS that doesn't have to work with persistent files and isn't stored in a file. FreeRTOS is one example. So while filesystems and operating systems are usually tightly coupled, they can actually exist without each other.

By "monolithic" I mean "a single piece of binary code". It would be a so-called blob: a sequence of bytes without a name, creation date or any other properties. After all, CPUs just process sequences of instructions. They don't care about file metadata or filesystems, they just want to be fed with tasks to execute. And if you can express these instructions as bytes, then blobs are sufficient!

And blobs can easily be stored in memory without any kind of filesystem. Actually we did that in our first example, when we just put content of file 1 in the memory.

I hope this answers your question!

Answer 2

The bios, operating system, and file system are distinct and separate elements, and an operating system can exist in read only memory on the device. So no the messages are not equal, but the operating system has one job, to be the interface between programs and the hardware. If the device does not have an operating system then the program or programs running on the device are the operating system.

It sounds likely that the system does not have an operating system if it is reporting no file system or a broken or incomplete partition/file system; But

... It may be that the mass storage device is mis-configured; or more specifically that the number of heads and tracks that bios is configured to use is not the same as the number of heads and tracks that the device has been formatted to use. When that happens the bootstrap can not load the complete file allocation system. Does the system have a battery that ran out resulting in the loss of setup information. If so correctly matching the bios settings to the formatting will recover the system ...

Bios is the basic interface to hardware. The operating system is the interface for programs to use which has been standardized so programs do not need to care about what specific hardware is being used. The file system is the standard data table to access a mass storage device.

The bios loads first from read only memory on the driver interface device sets up interrupt points for access. Int 13 is the access point for the mass storage devices.

https://en.wikipedia.org/wiki/INT_13H ... the bios then loads the partition table, from track 0, sector 0 of the device and a bootstrap routine. http://www.ntfs.com/fat-partition-sector.htm

The partition table tells everything how large the hard drive is and the bootstrap routine at machine address partition table+3E hex, (if I recall my reverse engineering correctly this is at 0000:063E hex on the machine), normally loads the operating system, and drivers which are able to be more advanced.

If the computer's OS does not have mass storage support you can still hook into this bios's support and build a extension to the system based on mass storage device. But be advised the OS may be turning interrupts on and off to keep the requests to the bios sequential.

The bios itself can not handle multi-threaded operations. Specifically a call is made to the bios to instruct the hard drive to get ready to read or write at a specific location. The read write operations then take place on a second call to the bios. An more advanced operating system is needed because something has to prevent one program from getting ready to read data while another program wants to write data or data will be overwritten.

A file system is needed for programs to use the mass storage device without risking overwriting data or locking other programs out of using the hard drive or bios.

---

The operating system used by Altair basic in the days of the 8080 was very Minimalist. You could save files to the hard drive, by specifying what head and track to begin saying the file at. No file system was used, the user had to remember the head and track number the file was saved at, himself.

Not much of a disk operating system but it worked. The routines for reading the keyboard and sending information to the display were minimal as well.

Answer 3

I think there are two points to address here:

• Some systems don't have a filesystem - does that mean they don't have an OS?
• Where can configuration be stored if there is no filesystem (or it's read-only)

Baremetal

Some systems do not have an operating system - there is one application, and that application software interfaces directly with the hardware. This is common with small microcontroller systems, where the complexity is low. In this scenario the software will typically be bespoke, with the development team writing the drivers and abstraction from scratch, or using vendor code to facilitate their design goal.

This being said, such systems may support a filesystem. Simple filesystems such as FAT are commonly used to store logs and provide firmware update functionally.

Configuration will often be formatted and written directly to raw non-volatile storage, without using a filesystem.

Embedded Systems - Scheduler

Going up a level, we find slightly larger systems and an increase in complexity. At this point we will find Real Time Operating Systems (RTOS) - though not all have real time requirements - that are designed with a specific set if features. These systems will be built with a set of "tasks" that are scheduled for execution - usually other / arbitrary tasks cannot be run. It is common for these systems to readily support filesystems, networking, etc... by using vendor or community-produced code.

Configuration may be written to raw storage, or stored as a file in a filesystem.

Look into FreeRTOS, ThreadX, etc...

Embedded Systems

Now we find embedded systems that are even larger. Complexity has risen, and at this level we find a dependence on a filesystem to organise the system configuration and applications / software. We are now able to execute arbitrary applications, and the kernels will come with a whole load of drivers for various hardware.

Here we're looking at Linux, QNX, "Windows Embedded Compact", etc...

Software will typically be built for the system, calling on projects like busybox to provide much of the functionality, and using projects like buildroot and Yocto to build the various applications and produce an image.

Configuration will most likely be written to a file - though the is nothing to stop the developers from using raw storage like before, as these systems will usually run on custom hardware.

The filesystem is required, but may not be writable, and may be purely "in-memory" - limited in size, and all changes (if RW) are lost on a reboot.

Full User / Server Systems

Here we are looking at desktop PCs running a windowing system, read-write filesystems (usually on large disks), arbitrary code execution galore, configuration is definitely stored as a file - this is the type of system you're familiar with. Servers are generally quite similar to desktop PCs in the terms we're discussing here.

In the Linux world this would be a "distribution". You'll usually find some form of package management, so installing / uninstalling an application is a matter of downloading and unpacking (compiling too if you're using the likes of Gentoo).

Here we are looking at Linux, Windows, Windows Server, etc...

---

Above I've mentioned that smaller systems typically store configuration in raw non-volatile storage. This is done by deciding what you want to store, collating the data, and writing it into storage.

For example, we may want to store the following simple configuration:

• The flange has precicely 52458 steps of rotation
• The flange must be rotated to position 5547 at 05:00
• The flange must be rotated to positron 49885 at 18:00

The numbers all fit into a 16-bit integer, so let's use that to represent steps. For the times, we decide to store in BCD for better compatibility with an RTC, so that's that.

We have the following data:

• 52458 --> 0xCCEA
• 5547 --> 0x15AB
• 05:00 --> 0x0500
• 49885 --> 0xC2DD
• 18:00 --> 0x1800

There values can be collated and written to storage as 10 bytes:

0x00000000    CC EA 15 AB 05 00 C2 DD 18 00

The application knows how to interpret this, so needs no support. By support I am referring to locating the storage area by name (e.g: filesystem and file name), and sharing understanding of the configuration with a human (e.g: JSON / XML / YAML / TOML).