inodes | Bash/Shell script to count inode usage | Command Line Interface library

So every directory, file, queue or whatever in Linux creates it's own inodes that can be accessed in one way or another.

False. Directories, files etc. do not create their own inodes. They are stored with use of inodes belonging to the filesystem on which they are stored. The inodes are not even created specifically for particular files -- all inodes are created as part of filesystem creation, before there are any files stored on it.^*

How would I go about implementing my own inode type that doesn't quite fit any of the existing descriptions?

It's unclear why you think you need a custom inode type, but if you do, then you need a whole custom filesystem. You will need to write either kernel drivers or FUSE drivers implementing it, plus all the needed utilities for formatting a device with that FS, mounting and unmounting it, checking it for errors, etc.

A custom something that is visible in the file system but isn't a file? Do I have to extend the kernel or is there some simpler approach?

Everything is a file. This is one of the principles of UNIX. But perhaps you mean something that isn't a regular file. Unfortunately for you, even a custom file system and inode wouldn't be enough to give you a custom file type. The partition of filesystem entries regular files, directories, character and block special files, etc. is deeply ingrained in the kernel and the standard file management APIs and utilities. You would not only have to extend the kernel (beyond writing filesystem drivers), but also modify the C standard library, several standard utilities, and probably a bunch of other libraries and utilities affected by those changes. In the end, you basically have your own whole operating system.

But maybe your premise is wrong. UNIX has been going along just fine with pretty much its current file model for a very long time. It's unclear why you want what you say you want, but there are at least two simpler options that might suit you:

• Write a kernel driver for a character or block device with a filesystem interface, and use the system's existing facilities to link one or more device instances to the filesystem as a character or block special file.

• Embed what you want to do in regular files / directories / etc.

^*More or less. I ignore special administrative actions that may in some cases be able to expand a filesystem and add inodes to it in the process.

Please use C5 Bare Metal. Yet the issue is not resolved as I got new error after using this instance type. However, bare metal is the only solution.

How would I go about loading something like this in VMware?
Would it even be possible due to architecture differences?

VMware simulates an x86 desktop PC.

You can attach floppy disk, CD-ROM or DVD images to VMware to simulate such a media.

If you have installed some operating systems in your virtual machine (that runs inside VMware) that contains a tool (similar to 7z) that can extract firmware image files, it makes sense to copy the firmware image to the virtual machine - in this case the file is just a "regular" file for VMware (just like a text document or a PNG image).

However, VMware itself cannot do anything with a Firmware image for ARM or MIPS.

I am able to extract the files with 7zip from the binary, as stated. But this removes the ... files ...

Looking at your screenshot, I doubt if I understood your question correctly.

If I understand the "binwalk" output correctly, the first file begins at offset 8212 (which is hexadecimal 0x2014), the second one at offset 8276 and the SquashFS image begins at offset.

So if you want to have the file 2014, you can use the dd tool to extract that file from the firmware image:

Your comment expression isn't valid Go, so I can't really interpret it without guessing. With guessing, I interpret it as correct, but have I guessed what you actually mean, or merely what I think you mean? In other words, without showing actual code, I can only imagine what your final code will be. If the code I imagine isn't the actual code, the correctness of the code I imagine you will write is irrelevant.

That aside, I can answer your question here:

(what's 'unprivileged' user go to do with filesystem blocks?)

The Linux statfs call uses the same fields as 4.4BSD. The default 4.4BSD file system (the one called the "fast file system") uses a blocks-with-fragmentation approach to allocate blocks in a sort of stochastic manner. This allocation process works very well on an empty file system, and continues to work well, without extreme slowdown, on somewhat-full file systems. Computerized modeling of its behavior, however, showed pathological slowdowns (amounting to linear search, more or less) were possible if the block usage exceeded somewhere around 90%.

(Later, analysis of real file systems found that the slowdowns generally did not hit until the block usage exceeded 95%. But the idea of a 10% "reserve" was pretty well established by then.)

Hence, if a then-popular large-size disk drive of 400 MB¹ gave 10% for inodes and another 10% for reserved blocks, that meant that ordinary users could allocate about 320 MB of file data. At that point the drive was "100% full", but it could go to 111% by using up the remaining blocks. Those blocks were reserved to the super-user though.

These days, instead of a "super user", one can have a capability that can be granted or revoked. However, these days we don't use the same file systems either. So there may be no difference between bfree and bavail on your system.

¹Yes, the 400 MB Fujitsu Eagle was a large (in multiple senses: it used a 19 inch rack mount setup) drive back then. People are spoiled today with their multi-terabyte SSDs. 😀

As you mentioned in your comment, the issue is on the (application) server side.

Turns out its Rails itself that caches the app in memory - but for prod environment only. Both docker (configured as prod) and host (as dev) is on my local machine, so no other server inbetween. But I did some digging in config/environments/production.rb and set "config.cache_classes = false".

This seems to have fixed the unsupported architecture and openssl issue now:

As Barmar's pointed out wrap ${drives} in double quotes so the whole 'line' is read into variable val otherwise the line is split on white space and processed one 'word' at a time.

Other items you'll run into once you get val populated correctly:

• readarray is used to read an entire line (from a file) into an array
• I'm assuming what you want to do is read each 'word' in val into separate array elements in which case ...
• try read -a to split val into individual array elements
• since fields is an array, and assuming the intent is to display all contents of fields on a single line ...
• you want to replace echo $fields with echo "${fields[@]}"
• as is echo $fields prints the contents of fields[0]

Pulling all of this together:

Posted community wiki based on Github topic. Feel free to expand it.

Personally, I have not found any equivalent of this call (/api/v1/nodes//proxy/stats/summary), and as it is still working and not deprecated in the Kubernetes newest versions ( 1.21 and 1.22), I'd recommend just using it and wait for information about replacement from the Kubernetes team. Check below information:

Information from this GitHub topic - # Reduce the set of metrics exposed by the kubelet #68522 (last edited: November 2020, issue open):

It seems that /stats/summary/ does not have any replacement recommendation ready:

[TBD] Propose out-of-tree replacements for kubelet monitoring endpoints

They will keep the Summary API for the next four versions counting from the version in which replacement will be implemented:

[TBD+4] Remove the Summary API, cAdvisor prometheus metrics and remove the --enable-container-monitoring-endpoints flag.

In Kubernetes v1.23 changelog there is no information about changing anything related to the Summary API.

I'd suggest observing and pinging Kubernetes developers directly in this GitHub topic for more information.

Turns out the latest helm chart has some bugs, so I reset to an earlier tag and tried again and all good! I didn't learn anything though, other than that helm charts can have bugs.

Let me try to explain it to you. Generally, you shouldn't use the latest tag at all. Helm needs an image and a specific version of it. Look at this example for the alpine image:

The latest docker tag is the latest release version (https://github.com/helm/helm/releases/latest)

Please avoid to use latest tag for any production deployment. Tag with right version is the proper way, such as alpine/helm:3.1.1

You can also learn a lot from this article: What's Wrong With The Docker :latest Tag?. It is related to docker, but in Helm you use these images. Note what can happen if you use the latest tag.

You can also read this good article. It explain how to proper create helm charts:

We will use AppVersion as the Docker image tag for our application. That allows us to upgrade Helm chart with new version of Application by just changing value in Chart.yaml