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.
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.
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.
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.
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.
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".