Forever Cached

20 May 2014

It took some time to get it working; if the 'activation' step in the mobile application keeps failing, do this:
Log into the Keytrade web site and go to 'Cards' -> 'Card Security' -> 'Activate Card for Online Payments'.
That's it.

19 March 2014

Quick one: catching a trap in bash is fairly easy with bash' trap command (search for 'trap \[' in bash' man page) but how to clear a set one?
It's in the man page, of course, but who reads those, right? I'm betting the answer is bound to be found on some blog through Google in 0.76 seconds flat ;)

"If arg is absent (and there is a single sigspec) or -, each specified signal is reset to its original disposition (the value it had upon entrance to the shell)."

05 February 2014

I was having some problems with loop back device creating & almost immediately detaching; it seems sometimes a kernel thread holds on to the device and the detach fails.
I decided to have a look what's going on so I created a script which automates the creation, attaching and detaching of loopback devices:

So if done fast enough the pool quickly gets depleted as giving back (detaching) the device fails.
A second or so later it might work, though. But let's test how much time exactly is needed to free the device?
I modified the script to keep trying to detach/free the loopback device and see what happens:

So it varies. The device might get released instantaneously, but that doesn't happen too often, or it might take 10 consecutive tries.
Let's see if allowing half a second's worth of pause in between creating and detaching fix the problem,

It does, but what's holding on to the device exactly?
I modified the script again to look up the did in the process table.
This takes time of course, so the detaching phase took less tries to complete:

Right, so it's Linux that's holding on to it and I'm not sure if I like this behavior.
I realize losetup can only request Linux to free up the device and it does cleanly report a 'Device or resource busy' but I don't understand why it just doesn't wait a bit until the resource is cleared from the kernel, or at least provides the option to the user to do so.
I thought about pathing losetup but now I can't be bothered anymore, so I'm just putting it out there :)

18 December 2013

So I wanted mdadm to not go interactive, ever, but instead just bail out whenever something happens it doesn't understand; you'd think the developers would have thought of that, right? Turns out they haven't.
The 'fix' is easy enough though: pipe /bin/false through mdadm by default so it'll get a 'false' every time it would be looking for user input; effectively making it bail out whenever something's off:

04 December 2013

I've been using dd(1) for as long as I can remember to create sparse files but for some reason I keep forgetting how to use dd's argument options so I set out to find something better... and found it: truncate(1):

From the man page: "Shrink or extend the size of each FILE to the specified size. A FILE argument that does not exist is created." -looking good:

Awesome!
So then I set out to find me something to quickly allocate 'real' files:

fallocate(1):
"fallocate is used to preallocate blocks to a file. For filesystems which support the fallocate system call, this is done quickly by allocating blocks and marking them as uninitialized, requiring no IO to the data blocks. This is much faster than creating a file by filling it with zeros."

01 October 2013

So, I was looking at unionfs alternatives and I wanted to try overlayfs.
You'd think a project almost begging to be merged into mainline Linux would be interested in getting some traction amongst the "regular" Linux crowd and actually provide some patches making it relatively easy to try out the code until the time finally comes they're part of mainline, right?
Well, apparently you'd be wrong assuming that: getting a clean OverlayFS patch requires distilling a diff from a patched Linux source tree on git and that is left as an exercise to the user... or simply use Ubuntu's or SuSE's kernels (no...fucking...way) as those are already patched it seems.
Anyways, this is how to do it:

From the git log I got they merged Linux 3.10-rc7 so that's the branch we're going to diff to.
Adding a new remote repo to the overlayfs.v18 local repo and fetching the v3.10-rc7 branch from it (git fetching won't actually change the local code!):

So what's happening here is that 'patch-3.10.4' from kernel.org actually is a diff from 3.10 to 3.10.4, not from 3.10.3 to 3.10.4.
This'd be fine except that you've already applied patch-3.10.3 the day before yesterday and you don't want to keep track of which patches are already applied and stuff, you just want to see whether or not the new 3.10.4 patches apply without problems.
Plus you've got other patches applied as well so you really just want to have a patch with the changes form one minor release to the other, right?
So that's where interdiff comes into play:

interdiff patch-3.10.3 patch-3.10.4 > patch-3.10.3-to-3.10.4

Now we have a patch that only includes the changes from 3.10.3 to 3.10.4 and that can be applied directly and cleanly to our already patched-with-the-previous-version-and-other-stuff-as-well Linux tree.