HN user

rdc12

328 karma
Posts5
Comments362
View on HN

With C in the embedded world it is very common to write entire applications that never only use static memory and the stack. Sometime programmers will allow dynamic memory during init only, other times not even then (I tend to favour the never approach, as I can verify that malloc is never called anywhere).

For the codebase I was working on today (in C). At first it was just } so filtered those out, then it was /* (no comment detail on that line) so again filter them. Then it was a bunch of #includes.

Not surprising but not insightful at all unfortunately

FPGA's also have billions of transistors now, but adding more block memory means removing transistors from something else, such as LUT's, registers, DSP blocks etc.

As always it is a tradeoff, and given many designs don't need much block memory, or need so much memory that external memory is a better choice anyway.

Recently at work I developed a small suite tools (in a mixture of python and shell, running in WSL) that left my boss impressed when he saw me debugging a customers system (IOT).

Then he started asking me to make them accessible to non programmers, and suddenly those tools seemed a lot more than I bargained for.

Different volcano, but back in the 50's the natural tephra damn on the crater lake of Mount Ruapehu (New Zealand) collapsed triggering a lahar, that ultimately took out the piers of rail bridge near Tangiwai minutes before a passenger train tragically attempted to cross the bridge, resulting in mass casualty's.

So certainly possible for non-expulsive activities to trigger a lahar and for consequences that sound like they are more from a disaster movie then real life to occur.

That is correct, if the first few records (a virtual block size sorta) (not sure how many off the top of my head) don't compress well, it assumes that the file is not compressible and just writes the data out skipping the compression step.

It isn't required (in the strict sense) to keep the dedup table in memory, the problem is that performance is dire when it doesn't. It would be pretty similar to virtual memory thrashing, when the table is not fully in memory.

You could use some sort of disk quota system, to make the filesystem artificially smaller than it actually is (trim after applying this change). Or simply insure that you don't exceed 80% - 90% used space.

It it is also worth noting that many SSD's are over-provisioned by the manufacture anyway, in those drives manual over-provisioning might achieve very little anyway.

The SSD maintains a translation table for all the virtual addresses exposed by the drive, that maps to the underlying flash physical addresses. Any physical address not in that table, is unallocated and the drive can use freely.

OpenZFS 2.0 6 years ago

Directly no, but if you moved the data to a new dataset, with a command that preserves the timestamp that would work (rsync -a or zfs send/recv), which could be run from a cronjob.

Compression settings are set at a per dataset level, so applying this to only some files in a dataset isn't practical.

From what I have heard, the amount of work needed in porting native encryption to the original FreeBSD port of ZFS was actually what led to this project.

Is the design files available for the rack mounted version (in particular the clip/holder parts).

Been quite keen to build something similar (albeit less nodes) for a little while. I find the homebrew blade style cluster amusing for some reason.