I've heard that the EMACS Shell that interfaces to the EMACS OS works very good for many things. Especially text and word processing, with macro functions shared throughout the EMACS community.

But, I never hear about it's file system. In order to be considered modern, it would have to support something like BCacheFS, Hammer2, or BTRFS.

So, what file systems does the EMACS OS support?
Or does it support native Linux file systems directly?

I would not think so, because Linux OS file systems are embedded into the kernel source code. And I'd have to guess that the EMACS OS won't bring in foreign kernel code.

In a way, you are right.

The point I was trying to make is that at present, this newly proposed Linux file system does not protect directory information. It is right their in the original posting, which quoted. Now of course, if they added protection to the directory, all the way up to the top of the file system, then great, all good.

However, without that protection, entire directory trees, (or in rare cases, the whole file system), could be lost due to corruption in a directory.

Perhaps this mSATA drive was bought before that was implemented. (It was bought about 2014 or early 2015.)

Exactly.

If an error is recoverable for a few months, BUT, is ignored too long, (because the data was not read), and more bits go bad, making the sector un-recoverable, then ZFS would record a read error.

However, if the error is recoverable, and IS read, the HDD, SSD or NVMe, would re-write, (or wear level it for SSDs), the block upon recovery. At least that is my experience with consumer storage.

As for sector degradation on a HDD, my miniature media server has a laptop drive, probably even SMR. In the past, that pool reported perhaps 15 failed blocks over about 4 years. Most were on the laptop HDD, though some were on the Samsung mSATA drive. Don't know why the sectors were bad, in someways I don't care since I knew un-RAIDed storage could fail.

Years ago I built a miniature PC to act as a media server and store master copies of scripts, help files and act as a print server. A year or so after I built it, I moved all the file systems to ZFS. However, with only an 1TB mSATA SSD and 2TB laptop HDD I could not Mirror everything. So I Mirrored the OS only. Then used ZFS to concat / stripe the remaining space for my media.

This worked reasonably well. A few times a year, I got a corrupted file in the media. Pretty straight forward to restore from backups. Not really a problem. Mostly video files because they are large, and would statistically be higher percentage of used space.

However, whence I implemented ZFS scrubs every 2 weeks, the corruption stopped, COLD. I have not had to restore any file, (due to on disk corruption), in over 6 years!!! And yes, I really mean that non-redundant media pool that has 2.1TBs used. My conclusion is that reading the used storage blocks caused the mSATA SSD & laptop HDD to find any marginal blocks. Then apply their internal ECC, before bad data could be supplied to ZFS.

Eventually I wrote about this here:
Arwen Star's blog - Self correcting storage

Now do I believe this is a workable solution for production data?
Of course not. Any serious data need should have some form of Mirroring or RAID.

Nor do I believe this is something others should do...

Plus, in the case of ZFS, it stores 2 copies of standard Metadata, by default. (Also covered by checksums...) Even without any Mirroring or RAIDing. (Standard Metadata is things like directory entries, access control lists and extended attributes. There is even 3 copies of more critical Metadata.)

To be clear for those that don't know, with the defaults and a simple 2 way Mirror, ZFS will have 4 copies of standard Metadata. 2 per Mirror, and 2 way Mirror is 4 copies, (of standard Metadata).

So that case of:
except once, when a flip hit a pointer to the file's data and it refused the read.
would not affect ZFS unless both copies, (and any redundancy if available), are damaged.

That really brings forth the point of why the pointer to the file's data was not also covered by error detecting and correcting code.

This should, (but won't), highlight the failure of processes.

Even with the supposed need to manage the fridges & freezers remotely, safe guards can be put in place. Like others have mentioned:

* Don't connect anything directly to the Internet, unless its purpose is for the Internet. Like a shopping site.
* Use a VPN gateway, with changing credentials. Including changing the credentials early when staff leave.
* Make the remote access Read Only by default.
* Have authorized onsite personal verify requests for remote R/W access. Then they, (onsite), enable such for a limited time, like 1 hour to update firmware.
* Allow onsite personal to return access to R/O by request. Thus, shutting down R/W access when remote work is complete.

That does not cover the actual firmware, which should have a good, solid team behind it:
* Planned features, bug fixes or security fixes should be discussed by original vendor.
* Code review before testing to make sure it should do what the new code should accomplish.
* Testing for both original features and the new code, (feature, bug or security fix).
* Staged roll out. Don't send it everywhere at once. This kind of code should have a prior version good enough to allow at least a week for roll out of new code.

I am sure their are 100 things that could make this better.

It has been a long time coming, but the time is at hand. We will have our new Pig-Human Overlords to rule us. They will either rule from afar, or take over our bodies by further combining our 2 superior species. All hail the new Pig-Human Overlords!

I know some have been waiting / wanting their new animal totem hybrid humans to be our new Overlords. They are now to be the Pig-Human Overlords! Animal & human hybrids will accomplish everything, you can take my word for it. Pig-Human is the future for us!

Thank you.

While I am up to 6.18 on my desktop, it's only 6.18.18, so it will need another update. The others, (laptop and media server), will need a jump to a new kernel series. They are all older kernels.

Also use Gentoo. Everytime I think it's too much work to trouble shoot a problem, I figure it out and make the updates better. Now Gentoo updates run pretty much problem free. Even when they do go south, I use ABEs, making recovery brain dead simple: Boot the prior OS. (ABE = Alternate Boot Environment, basically keep the old OS prior to the update around until I decide to delete it...)

One thing that has made a difference in my Linux updates, is to use a second boot environment. It could be a 2nd OS partition, 2nd LVM, or a BTRFS snapshot. I've used both the 2nd OS partition and BTRFS for that function. They worked perfectly, though obviously the 2nd OS partition doubled the OS disk usage, while BTRFS only increased usage based on the amount changed. Even tested the LVM method, which worked for testing. Note you can't really use LVM snapshots for this purpose, as they are not meant to be kept for weeks or months.

With updated Grub entries, this allows booting the old OS without the updates.

So the process would be:

1. Create new boot environment, (BTRFS supports more than 2). Or prepare the alternate partition or LVM for the update.
2. Mount up the alternate boot environment.
3. Perform the update to the ABE.
4. Update Grub to boot this new BE by default.
5. Prompt use that a reboot is now needed to activate the update.

All of that can be automated as part of the update, (well, even the reboot if that is what the user wants).

No user likes a broken update. Especially when it is something he/she may not understand as well as MS-Windows. Further, while MANY, MANY Microsoft Windows updates had problems, they generally were so obvious and got enough attention that when a fix was available, users were able to implement it soon. Without much poking around and Internet searching.

The inability to leave an via an automated path, reminds me of the short story "Intent to Deceive" by Larry Niven. In it, customers in an automated restaurant can't leave due to a fault in computers. Not even paying customers. They had to wait until the place closed, (as I recall).

Of course, their was Intent to Deceive in the story, as well as cannibalism, along with robots gone wild. Larry Niven had such a range of abilities.

Actually the second company WAS Sun Microsystems. The first company, where I originally worked, was StorageTek, which had 3 Class A sub-nets.

At the time Sun acquired STK, Sun had 2 Class A sub-nets, as far as I remember. Thus, the extreme desire by the North American IP allocating authority to claw back as much as they could. So, when it was all done, Sun did not end up with 5 Class A sub-nets. Not sure how many Sun had to give up, but if I remember correctly it was at least 2. When we transferred all the STK servers to Sun that were to be kept, they all ended up with 10.x.x.x IPs. Or one of the other internal only reserved IP ranges.

A while back I worked at a company that had 3 public Class A IPv4 sub-nets allocated to it. They obviously got them early on, but ended up using all of them, including in one instance for phone home devices, (well, network send home). After a few years working there, that company got bought by an even larger company. This other company had at least 2 public Class A IPv4 sub-nets, and was one of the original users / founders of the Internet. (You have three guess, just don't cheat and look up during the day...) Of course trying to get those 3 Class As ownership transferred to the new company found that the organization that handled IP allocations, wanted to claw back some of those Class As. I mean, what company needs 5 public Class A IPv4 sub-nets, that is not an Internet service provider?

If you understand what that means, I don't have to tell you. But, for others, their are 24 million IPv4 addresses in a Class A sub-net. To be fair, it can't be broken down too far. But, in theory, you can TONS of Class C sub-nets out of a Class A. Each of those Class Cs could be allocated to a different company, country or individual. Like 64K Class C sub-nets out of a Class A, (in theory).

Any way, we got to the IPv4 shortage because the Internet was not designed for the future. Nor was IPv4 sub-net allocations done in a forward thinking mode. Thus, NAT at home, NAT at work, NAT at a much larger scale.

In reality, companies don't need public IPs inside their own networks. In fact, it could be considered a security breach to use such. So a company could have a simple public Class C at each location for external access. Or even just a few IPs at smaller sites. However, no one knew this Internet thing was going to take off in the way that it did.

Over the last 10 years it has become quite apparent that really active development does not belong in the Linux kernel source tree.

As an example, BTRFS has started to stagnate in development. Nothing really ground breaking has happened with BTRFS. In someways, it is a dead file system and headed for the scrap heap, (note I said SOMEWAYS). I personally used BTRFS, both because it was supposed to be the replacement for EXT3/4, had data integrity features, plus snapshots. Even went so far as to write up a local procedure to use snapshots as alternate boot environments for distro updates. That worked VERY well and I had little to no problems. But, after years and years, BTRFS never stabilized, so I moved on.

In my opinion, part of the problem stems from the requirement that the kernel module match user land code, for things to work right. Any kernel update may end up requiring matching user land updates of the file system utilities, (which might also require updated libraries!). Have both user land and kernel module developed out of the Linux kernel source tree is actually a benefit, (again, in my opinion). BTRFS or BCacheFS can then support a range of kernels, and yet still make kernel update requests to add new features, or fix odd behavior. Maybe eventually getting stabilized to the point of releasing source into the kernel.

One disadvantage of this software development method, is that new Linux kernels need to be added. But, in reality, that always had to be done. So the disadvantage is that a user of BTRFS or BCacheFS using out of kernel tree development would have to wait on any kernel update until their file system has been both updated and tested with the new kernel.

The 600 series terminators had rubber skin, but the 800 used artificial blood and skin to pass as human. Sweat, bad breath, everything. Very hard to spot. So this blood is the first step for Skynet's best infiltration unit! The world is ready to be destroyed!

I welcome our new overlord - Skynet, (please don't kill me!).