globalc

That, and if not possible one can try to get the used kABI symbols graylisted at Red Hat, to get informed when they change.

Let's take a task like "uncompressing a file".

It's clear that a Raspi is uncompressing slower than a new and shiny Thinkpad.. but the Thinkpad also uses much more power. Who is more energy efficient?

The article compares the energy efficiency of ARM/x86/RISC-V/AppleSilicon. The created framework can be used to easily compare energy efficiency of other tasks, i.e. kernel compilation.

AppleSilicon with #asahi #fedora remix shines for the uncompress task I looked at.

I played through more scenarios with the "I have a laptop, and want seamless switching between ethernet and wireless".

shadowsocks proxy seems like the best choice, allowing transparent proxy for TCP applications, but also needs 2 helper systems for the setup.

Next best choice seems bonding, just needs helpers on the LAN.

Details: https://fluxcoil.net/wiki/software/mptcp

You should pay attention to make the ethernet the preferred interface.

If aggregation of bandwidth over the various underlying media is important for you: depending on the exact mode, aggregation might not work. Even if working, via bonding you might only get aggregation if the traffic goes over multiple TCP channels, while MPTCP also aggregates for a single TCP channel.

Nice, was not sure how stable such a setup would be. The applications will not need further modification and just need to be sent over the bond.

For MPTCP, as of today the applications over the mptcp-stream (which has subflows over the 2 media) need to be modified to use MPTCP, or an additional layer like with shadowsocks needs to be used to transparently encapsulate traffic over the link.

Ah, valid point, mea culpa. I have not used nbd, but I'm aware of it. Was very impressed to see even a NetBSD implementation. There is just so much around in that area.

In my defense, the storage related PM and colleagues who reviewed the article did not bring up nbd either.

+1

I use the older one which uses the kernel from the stock firmware. To my understanding done by the guys who worked also on the original firmware. I have seen just a single issue, it's minor: fast forward/rewind does not work properly. It does forward/rewind, but slower than expected.

The new native port lists quite some downsides/TODO's, so I did not yet switch over.

I can recommend the FiiO M3K, especially loaded with https://www.rockbox.org/ . There is now a native Rockbox build (with some caveats), I use the older one from https://forums.rockbox.org/index.php/topic,52952.0.html - works very nice.

Of course, besides simply supporting recovery from bit rot, one would also want to have confidence in the implementation. I think the vendors which provide production support for btrfs do so just for a few features.

I know someone who did setup ceph just for it's healing capabilities.. but of course one has to familiarize with all of it's administration aspects for that.

Setups with RAID1 could help fixing bit rot, but I think these setups are not full stack tested, so one would have to play and test by oneself (and after soft ware updates verify the whole stack again..).

Maybe easiest remedy is to keep all files in a second directory, and hope that when bit rot invalidates one version of the file the second one is ok. rsync could in cycles sync the 2 directory trees.

- XFS: can use checksummed metadata, changed data (bit rot) will not be noticed, unless extra layers like dm-integrity are used

- ext4: same as XFS

- btrfs: can with checksums detect bit rot, not heal it by itself it seems

- ceph: can detect bit rot, not repair. Ceph is for networked systems, no local file system like xfs/ext4/btrfs.

With the current code, your data becomes unmountable in that case. There is a workaround for getting the data accessable: leave a bit of the underlying blockdevice unused, so when creating VDO ontop give it not the full blockdevice. Then, in case the filesystem ontop completely fills up, the last part of the blockdevice can be used to grow the VDO device, and the filesystem can be mounted.

Should be tried out before relying on it. The current behaviour seems to be considered a bug, https://bugzilla.redhat.com/show_bug.cgi?id=1519377 has details.

The capacity is not changing 'rapidly', instead the whole VDO device is thin provisioned. Let's assume a 1TB harddisk, then when creating a VDO device ontop, you can have that directly appear as 3TB, so 'thin provisioned'.

The filesystem ontop always sees 3TB, unless you explicitly modify the VDO device. Of course, you have to monitor the VDO status tightly: if you happen to store data on the filesystem which is absolutely unique, has no zeros and is uncompressable, then dedup/compression can not do anything. The VDO device can only consume up to ~1TB of such data. Your monitoring should detect the low space on the VDO backend before, and you should then either stop writing or extend the backend device.

Yes, VDO is transparent for the layers above, like filesystems. XFS+VDO might be preferable to BTRFS, if it has the features you need. - LVM could be used for snapshots, but the snapshots from BTRFS might be preferable in corner cases where many snapshots are done (snapshots in XFS are being worked on AFAIK, these could then be comparable) - XFS+VDO combination might be more reliable, it's a completely supported combination on RHEL, whereas BTRFS is just techpreview - only missing feature coming to mind is checksums over data blocks, XFS is only providing checksums over meta data

Nothing prevents you from running VDO ontop of ZFS, apart of that not being in focus/tested at Red Hat. I do not expect issues from purely running both layers, but maybe things like proper mounting/umounting via fstab might not be in place.

If ZFS gives you block level checksums, then you could use compression/dedup from VDO. Just activating i.e. compression on both layers would be waste of cycles.

If your data directories have much redundancy (so deduplication can help), or are nicely compressable, then VDO can also make sense for home setups. Like companies, you would consider things like "does it make sense for my kind of data", "do I have enough CPU cycles/ram to spend on getting storage down to some degree" and "am I ok with the additional layer, so more complicated setup".