Introduction & background information NOTE: This content is from an internal talk I gave, thus the reason it may read like a presentation So what is bcachefs? bcachefs is a next-generation copy-on-write (COW) filesystem (FS) that aims to provide features similar to Btrfs and ZFS, written by Kent Overstreet Copy-on-write (COW), with goal of performance being better than other COW filesystems Full checksums on everything Mult-device, replication , RAID, Caching, Compression, Encryption Sub-volumes, snapshots Scalable, 50+ TB tested Why the need for another FS?

The ability to write a C shared library in rust has been around for some time and there is quite a bit of information about the subject available. Some examples: Exposing C and Rust APIs: some thoughts from librsvg Creating C/C++ APIs in Rust (site removed?) Rust Out Your C by Carol (Nichols || Goulding) (youtube video) Exporting a GObject C API from Rust code and using it from C, Python, JavaScript and others Rust Once, Run Everywhere All this information is great, but what I was looking for was a simple step-by-step example which also discussed memory handling and didn’t delve into the use of GObjects.

I firmly believe that security through obscurity is a fail. However, I do believe that all things being equal, making it a bit more obscure is better as long as you aren’t introducing more failure points, like a port knocker that has it’s own security bugs. Thus I’ve always run my sshd service on an alternative port. It’s simple, and keeps my logs clean and shouldn’t cause any additional security risks.

I saw this referenced today on lwn.net

IMHO if you make a language incompatible with previous versions it should be renamed. I’ve thought this many times with the python2 -> python3 change. I suppose some will find this irritating, but I think it would make things less confusing.

I used to like Python. Like others I enjoy the productivity it offers and the vast and plentiful libraries that exist. However, over time that fondness has turned to loathing. The thing that should have been apparent to me long ago is that the Python folks don’t appear to care about end users. They seem to have lost touch with the fact that Python is very popular! Each and every time they make core language behavior changes, API changes, and deprecate things, a lot of code has to accommodate.

Ideally it would be great if a DBUS server side library provided Fully implements the functionality needed for common interfaces (Properties, ObjectManager, Introspectable) in a sane and easy way and doesn’t require you to manually supply the interface XML. Allows you to register a number of objects simultaneously, so if you have circular references etc. This avoids race conditions on client. Ability to auto generate signals when object state changes and represent the state of the object separately for each interface on each object.

Introduction Stratis (which includes stratisd as well as stratis-cli), provides ZFS/Btrfs-style features by integrating layers of existing technology: Linux’s devicemapper subsystem, and the XFS filesystem. The stratisd daemon manages collections of block devices, and exports a D-Bus API. The stratis-cli provides a command-line tool which itself uses the D-Bus API to communicate with stratisd. 1. Installation # dnf install stratisd stratis-cli 2. Start the service # systemctl start stratisd # systemctl enable stratisd Created symlink /etc/systemd/system/sysinit.

Debugging gobject reference leaks can be difficult, very difficult according to the official documentation. If you google this subject you will find numerous hits. A tool called RefDbg was created to address this specific need. It however appears to have lost effectiveness because (taken from the docs): Beginning with glib 2.6 the default build does not allow functions to be overridden using LD_PRELOAD (for performance reasons). This is the method that refdbg uses to intercept calls to the GObject reference count related functions and therefore refdbg will not work.

Continuous integration (CI) support in github is a very useful addition. Not only can you utilize existing services like Travis CI, you can utilize the github API and roll your own, which is exactly what we did for libStorageMgmt. LibStorageMgmt needs to run tests for hardware specific plugins, so we created our own tooling to hook up github and our hardware which is geographically located across the US. However, shortly after getting all this in place and working it became pretty obvious that we provided a nice attack vector…

While working on lvm-dubstep the question was posed if D-bus could handle the number of changes that could happen in a short period of time, especially PropertiesChanged signals when a large number of logical volumes or physical volumes were present on the system (eg. 120K PVs and 10K+ LVs). To test this idea I put together a simple server and client which simply tries to send an arbitrary number of signals as fast as it possibly can.