This is not the techblog entry I thought I was going to write. Thatentry would have been a quietly triumphal one about finding andsquelching an interesting and obscure issue that was causing ourbackups to be unnaturally slow. Unfortunately, while the particularissue is squelched our backups of at least our new fileservers are still (probably) unnaturallyslow. Certainly they seem to be slower than we want. So this entryis about the challenge of trying to figure out why your backups areslow (and what you can do about

I've been looking at disk read caching systems recently. Settingaside my other issues , I've noticedsomething about basically all of them that makes me twitch as asysadmin. I will phrase it this way:

Caches should be safe by default .

By 'safe' I mean that if your cache device dies, you should notlose data or lose your filesystem. Everything should be able tocontinue on, possibly after some manual adjustment. The broad purposeof most caches is to speed up reads; write

A while back I wrote Cross-system NFS locking and unlocking isnot necessarily fast , about one drawback ofusing NFS locks to communicate between processes on differentmachines. This drawback is that it may take some time for processB on machine 2 to find out that process A on machine 1 has unlockedthe shared coordination file. It turns out that this goes somewhatfurther than I realized at the time. Back then I looked at cross-systemlock activity, but it turns out that you can see long NFS lock

Under normal circumstances the way you deal with Linux bind mounts on a systemd based system is the same as always: youput them in /etc/fstab and systemd makes everything work justlike normal. If you can deal with your bind mounts this way, Irecommend that you do it and keep your life simple. But sometimeslife is not simple.

Suppose, not entirely hypothetically , thatyou are dealing with base filesystems that aren't represented in /etc/fstab for one reason or another; instead they

One of the types of units that systemd supports is mount units (see'man systemd.mount'). Normally you set up all your mounts with /etc/fstab entries and you don't have to think about them, butunder some specialized circumstances you can wind up needing tocreate real .mount service files for some mounts.

How to specify most filesystems is pretty straightforward, but it'snot quite clear how you specify Linux bind mounts .Since I was just wrestling repeatedly with thistoday,

There's a number of situations where you want to replicate partitiontables from one disk to another disk; for example, if you are settingup mirroring or (more likely) replacing a dead disk in a mirroredsetup with a new one. If you're using old fashioned MBR partitioning,the best tool for this is sfdisk and it's done as follows:

sfdisk -d /dev/OLD | sfdisk /dev/NEW

Under some situations you may need ' sfdisk -f '.

If you

One of the suggestions in response to my SSD dilemma was a number of Linux kernel systems that aredesigned to add a caching layer on top of regular disks; the leadingcandidates here seem to be dm-cache and bcache. I looked at bothof them and unfortunately I don't like either one because they don'twork in the way I want.

Put simply, what I want is the ability to attach a SSD read acceleratorto my filesystems or devices without changing how they are currentlyset up.

In a comment on my entry on FreeBSD vs Linux for me , Matt Campell asked (quoting me in an earliercomment):

I also fundamentally disagree with an approach of distributingapplications as giant self contained bundles.

Why? Mac OS X, iOS, and Android all use self-contained app bundles,and so do the smarter third-party developers on Windows. It's a provenapproach for packaged applications.

To answer this I need to add an important bit of context that may nothave been clear in

I ranted about this on Twitter a few daysago when we discovered it the hard way but I want to write it downhere and then cover why what Intel did is a terrible idea. Thesimple and short version is this:

Intel switched one of their 'datacenter' SSDs from reporting 512byte 'physical sectors' to reporting 4096 byte physical sectors in afirmware update.

Specifically, we have the Intel DC S3500 80 GB model in firmwareversions D20