Device built-in storage warning, ZimaOS disks get crossed

Hardware ZimaBlade
1

I was running ZimaOS 1.6.1, which I upgraded to right after buying my ZimaBlade (with CasaOS already preinstalled on it) a few months ago.

Seemed to work fine until a couple of weeks ago, when I got the dreaded warning that Device built-in storage is almost full, and sure enough, the built-in flash disk (z:, as served to the net) was completely full. I had moved a bunch of music to the Y: drive (a 0+1 Raid volume of 2x2TB SSDs), but nothing to the built-in Z:drive. So I poked around, and it turned out my music appeared to be somehow (but not really, read on) stored in TWO places: the Media directory on the Y: drive, and another copy in .Media on the Z: drive.

So I deleted everything under .Media. And everything vanished from the Media folder on the OTHER drive as well. I lost hundreds of files that I had just put there to sort and clean up my music (that’s what NAS servers are for, right?)

Furious, I decided OK, that version of ZimaOS is completely untrustworthy, so I’ll just lay waste to the entire system and reinstall when I get a chance. Made a USB drive with 1.7.1-beta 2 on it this morning, but can’t figure out how to get the BIOS to boot from the USB - nothing shows up. (I was once program manager for software, including BIOS, for half of Dell’s business units, and a Linux user since 1993, so I’m not a clueless newbie.)

More furious, I decide OK, I’ll do the upgrade in place, which the docs say will step on everything. It doesn’t - the warning about built-in storage is still there, and it’s still full. df shows / and /DATA are both 100% full. Poking around on this forum points to runaway crap filling up the .cache directory. That directory doesn’t exist in 1.7.1, apparently. Back to square one.

I cannot trust ZimaOS or my ZIMABlade until and unless I can *completely* nuke it and reinstall. Preferably with something other than ZimaOS, since it seems to be dangerously unstable and unreliable.

But I can’t even figure out how to do this, if I can’t boot to USB.

Right now, my opinion of Zima, both hardware and software, is “flaky as hell”. Change my mind.

2

Finally figured out how to get the ZimaBlade to boot from USB. It is anything but obvious: You have to select the option that just says “1.27” as the first boot device, then it will boot from USB and allow you to install.

I installed the final 1.7.1 release, but I’m still really not sure I can count on it to properly store and preserve my data after its deadly confusion of mixing up the content of completely separate disks/volumes. (The Windows client may have played a role in this foul-up, I’m not sure…)

We’ll see how it goes. I guess one of the nice things about the ZimaBlade being Intel-based is that there are a lot of other good solid, reliable NAS distros if ZimaOS can’t cut it. I just really don’t want to learn that the hard way again, but I’ll give it one more try.

I would encourage the ZimaOS dev team to make sure everything regarding basic NAS functionality, filesystems, volume management, backups, etc. are fully buttoned down and bulletproof reliable before adding any more new features. Those don’t matter at all if the foundation is not rock solid.

3

Thank you for your feedback. The Media directory and .Media directory point to the same files.

To reduce system disk usage, you can go to Settings - Apps and migrate the app data to another drive.

image
image1566×1440 153 KB

4

The problem was that part of Zima thought those files were on my RAID volume (that is where I am CERTAIN that I put them), but that they were actually on the root volume, filling it up.

What’s odder is that the content showed up in the Media directory on the RAID volume as well as in the .Media directory on the root (or /DATA - not sure, now?) volume.

When the clearly wrong content was deleted from the .Media on the root volume, it also got nuked on the RAID volume. That should NEVER happen. I get that .Media and Media can be pointing to the same place (heck, they could even be hard-linked within a filesystem), but they should NOT be linked across filesystems, and that’s what I encountered.

5

Can you run the following commands in the command line, separately in both /DATA and RAID, to determine if these files are the same? Also, can you take a screenshot of your settings and apps?

ls -la
6

Sorry, I bulldozed everything down to bare disks and built it all up all over again, so there’s no way to do that now.