DOS ain't dead

Hard disk LEDs and noisy machines
The little annoyances that alerted us developers of performance problems

---
Forum admin

Yes, I was also used to listen HDD heads crunching as an indicator of something is happening. Now with fast and silent SSD some ransomware can encrypt your whole disk within few minutes without a notice :)
But there are many of systray monitor tools that are always visible. E.g. I have coretemp there to see CPU temps (corelated with loads), network trafic monitor and so on...

---
DOS gives me freedom to unlimited HW access.

Many modern laptops don't have a hard disk light, and it is impossible to know when the computer is busy because of that. Hard disk reads cannot be buffered like writes can, so having an I/O indicator for hard disks makes sense. Even with multitasking operating systems everything just works faster if the user waits until the disk I/O is finished before giving new orders to the computer.

So I don't agree that removing the hard disk light improves usability. In fact the hard disk light is even more important with modern SSD disks, because the user cannot even hear the disk I/O happening anymore.

>
> So I don't agree that removing the hard disk light improves usability. In
> fact the hard disk light is even more important with modern SSD disks,
> because the user cannot even hear the disk I/O happening anymore.

Since an SSD is up to 10 times the speed of an HDD... even with a disk activity LED
it would blink once for a split-second for the same operation that would take a few seconds on an HDD.

Even an operation that would take a minute on an HDD would be done in only 6 seconds on an SSD

And what users EVER sit there watching for a minute or more for the HDD LED
to go out before starting another operation ? ;)

---
--
http://glennmcc.org/

> ...
> Hard disk reads cannot be buffered like writes can ...

Not true. In fact, the default for most disk caching programs is to ONLY cache/buffer reads. Writes are not buffered at all -- they are simply "passed through" in real time and not delayed. Read caching of the FAT area of the disk can make a HUGE difference in speed on large disks and floppies.

> Since an SSD is up to 10 times the speed of an HDD... even with a disk
> activity LED
> it would blink once for a split-second for the same operation that would
> take a few seconds on an HDD.
>
> Even an operation that would take a minute on an HDD would be done in only
> 6 seconds on an SSD
That does not change anything. Having the indicator led still makes sense.

> And what users EVER sit there watching for a minute or more for the HDD
> LED
> to go out before starting another operation ? ;)
If some operation is very heavy in disk I/O and takes a minute to complete, it makes very much sense to wait for that operation to complete before starting anything new.

> > ...
> > Hard disk reads cannot be buffered like writes can ...
>
> Not true. In fact, the default for most disk caching programs is to ONLY
> cache/buffer reads. Writes are not buffered at all -- they are simply
> "passed through" in real time and not delayed. Read caching of the FAT
> area of the disk can make a HUGE difference in speed on large disks and
> floppies.
You are confusing buffering and caching. If a program makes a read() syscall, the syscall always blocks _until the data has been read from the disk_. If there is a disk cache and the requested data can be found from the cache (in which case the data has already been read from the disk before the syscall), then the kernel just copies the data from the cache and no disk I/O operation is needed. But that is caching, not buffering.

On multitasking operating systems the kernel can usually give CPU time to other processes while one process is waiting a disk I/O operation to complete, but usually only one disk I/O operation is possible at a time, so things become very slow if the user asks the computer to do two simultaneous tasks which both require disk reads.

Writes are usually almost always buffered on modern operating systems, and the kernel does not immediately flush the buffers to the disk, so a write() syscall usually returns immediately, unless the program is writing very large amounts of data and the buffers cannot fit into the memory.

> > And what users EVER sit there watching for a minute or more for the HDD
> > LED
> > to go out before starting another operation ? ;)
> If some operation is very heavy in disk I/O and takes a minute to complete,
> it makes very much sense to wait for that operation to complete before
> starting anything new.
>

Whether or not it makes sense is not the question.

The question is, does anyone ever actually do it ?

I can only speak for myself, but I _can_ say that in over 45yrs of using computers,
I've never once sat there watching for the HDD LED to go out
before doing something else.
But rather the moment the command prompt is back, I proceed with the next task.

And of-course now on Linux, I'll have several disk-intensive operations going at the same time.

---
--
http://glennmcc.org/

> I can only speak for myself, but I _can_ say that in over 45yrs of using
> computers,
> I've never once sat there watching for the HDD LED to go out
> before doing something else.

I definitely did that, when my PC still had rotating disks.

---
Forum admin

> You are confusing buffering and caching.

Buffering and caching are essentially the same thing (or are at least trying to accomplish something similar), though they do it in different ways. Every application that I know of (including the OS) reads from the disk into memory and manipulates what's in memory before writing back, or manipulates the memory before writing something new to disk. They don't work with the data while it's still on the disk. Part of the reason for that is that the data is stored on the disk in blocks (sectors/clusters) and you may only need to manipulate the data in bits or bytes, or at least something much smaller than a sector/cluster. There are other reasons as well, but that is an important one.

Any OS worth its salt will never simply buffer/cache data in memory before writing to disk. The problem with that approach is that if there is a crash in the middle somewhere ALL the data is lost. That's why they invented Journaling File Systems (JFS). In a JFS, the data is not simply stored in memory waiting to be put on disk later. The data is written to disk right away, but is stored in a temporary "holding space" called the Journal. What is stored in the Journal is enough information (the data and/or metadata) so that it can be moved to the correct place on the disk later, but while it's stored in the Journal it's "messy". If there is a crash between the Journal write and the "real" write, the data can still be put on the disk where it needs to be. If there is a crash while writing to the Journal, the data will be corrupted. The point of the Journal is to get _something_ relevant out of memory and onto the disk as fast as possible and worry about cleaning up the details later. Also note that in a JFS the disk is used a lot more than in a "regular" file system since the data is written and then moved (written to a new location and then deleted from the old location).

BTW, that's similar to how databases work. When you update a record in a database it gets written to disk right away -- it is not simply stored in memory waiting for a "batch update" to happen later.

I used a TSR in DOS (years ago) that would simulate an LED activity light (probably found in 80xxx snippets).

DOS (before SmartDrv) had very primitive buffering via CONFIG.SYS's BUFFERS=n,m. (Tim Paterson [mirror] had a small writeup about some of that.)

While it's true that SSDs are fast, USB flash drives are slow. IIRC, they are allegedly 2x slower to read and 5x slower to write. So yes, modern OSes do cache writes to them, hence requiring an explicit eject command in order to flush pending data to disk (else you risk corruption). I use a bootable FreeDOS jump drive a lot, and I usually do most work on a 200 MB RAM disk for testing, then copy the finished programs to "hard disk" later.

> I used a TSR in DOS (years ago) that would simulate an LED activity light
> (probably found in 80xxx snippets).

This is not the one I meant, and I haven't tested it, but I thought some of you might find it interesting:

* https://github.com/MobyGamer/softhddi