JZerf

I also do not like that Apple has completely removed all USB type A ports on the newer MacBooks. USB type A plugs are still very common and I wish Apple left one or two on the newer MacBooks in addition to the USB-C ports. Yes, you can use USB-C to USB type A adapters but it is annoying.

I also do not like that Apple has removed the Ethernet and microphone jacks. Both jacks are still useful to have on modern computers. I'll make an exception for removing the Ethernet jack on the MacBook Air to accommodate a thinner chassis but wish the MacBook Pro chassis was kept thick enough to accommodate the Ethernet jack.

I'm currently working on setting up disk encryption for a new home server and as an additional precaution I'm also working on getting the initrd to do a few additional sanity checks prior to decrypting a LUKS partition and prior to mounting the root file system within. One check which I think will be highly effective is that prior to decrypting the LUKS partition I have the initrd hash the entire LUKS header and make sure it has the expected value before allowing the boot to continue. So far it seems to be working OK but hashing the entire LUKS header is overkill which will require some care to make sure the expected hash value is kept updated if the LUKS header changes for some reason (like changing encryption passwords). I can not recommend this idea for everyone consequently.

Yes, there will be much more going on than the simple test I was doing. The server will be hosting several VMs running a mix of OSes and distros and running many types types of services and apps.

I don't believe that zfs_txg_timeout setting would make much of a difference for the test I described where I was doing synchronous writes.

> On Linux, I think journald would be aggregating your logs from multiple services so at least you wouldn't be incurring that cost on a per-program basis.

The server I'm setting up will be hosting several VMs running a mix of OSes and distros and running many types types of services and apps. Some of the logging could be aggregated but there will be multiple types of I/O (various types of databases, app updates, file server, etc...) and I wanted to get an idea of how much file system overhead there might be in a worst case kind of scenario.

> I sure hope I've upgraded SSDs by the year 2065.

Since I'll be running a lot of stuff on the server, I'll probably have quite a bit more writing going on than the test I described so if I used ZFS I believe the SSD could reach its rated endurance in just several years.

I'm in the process of setting up a server at home and was testing a few different file systems. I was doing a test where I had a program continuously synchronously writing just a single byte every second (like might happen for some programs that are writing logs fairly continuously). For most of my tests I was just using the default settings for each file system. When using ext4 this resulted in 28 KB/s of actual writes being done to the drive which seems reasonable due to 4 KB blocks needing to be written, journaling, writing metadata, etc... BTRFS generated 68 KB/s of actual writes which still isn't too bad. When using ZFS about the best I could get it to do after trying various settings for volblocksize, ashift, logbias, atime, and compression settings still resulted in 312 KB/s of actual writes being done to the drive which I was not pleased with. At the rate ZFS was writing data, over a 10 year span that same program running continuously would result in about 100 TB of writes being done to the drive which is about a quarter of what my SSD is rated for.

-The programs could have been written by someone who prefers to make small iterations and perform many submissions instead of someone who likes to make bigger changes with fewer submissions.

-The programs could be submitted by a novice who needs to make more submissions than would be required by a pro.

-The programming language may be older and has had more submissions.

-The programming language may be more actively changing and requires more updates in order to fix old programs.

-The programmers may also be making more submissions to improve other characteristics like memory usage, code size, code readability, compatibility, etc... that are unrelated to performance.

  delete class!
  class Player {} // Error: class was deleted

  delete delete!