jhfrontz's questions

I want to update my ~/.ssh/known_hosts with the host key information for a newly created GCE instance. But I'm not sure how to securely retrieve that information.

I thought something like

gcloud compute ssh <GCEUSER>@<GCEHOST> --command='ssh-keyscan 127.0.0.1'

might work. But that (per the gcloud compute ssh documentation) appears to just be a wrapper for ssh (and, based on seeing StrictHostKeyChecking=no in the parameters listed in the associated log file under $HOME/.config/gcloud/logs/, apparently isn't doing any sort of checking on the host's identity).

There does seem to be a way to use the web console to launch a browser-based ssh session (and interactively/manually run ssh-keyscan), but 1) I can't see the internals to know if it really is as secure as it should be and 2) isn't an effective API for script integration.

Is there an API/gcloud mechanism for securely retrieving the GCE instance's host key?

I'm trying to construct an experiment to measure the effect of ionice. What I'd like to do is to (per another answer on serverfault) cause frequent enough I/O that a sufficiently "niced" process is starved of any I/O.

Based on another answer on serverfault, I think I need to cause at least one actual I/O operation to a common cfq-scheduled device every 250ms. My thought was to write a trivial program that does has a loop that

• writes to a (configurable) file on the common device,
• does an fsync() (to force a definite I/O operation),
• uses usleep() to delay a configurable amount of time
• periodically uses lseek() to truncate the file (so that I don't fill the file system)

I then start up one instance of the program using ionice -c3 (idle scheduling class) against one file on the common device. I simultaneously run various instances with the default (best-effort) scheduling class, specifying a different file on the common device (varying the delay values).

My hypothesis was that for delay values of 250ms or more on the "best-effort" process, I would see progress made by the "idle" process; for values less than 250ms, I would see little to no progress made by the "idle" process.

My observation was that there was no difference in performance of the two processes; they both made similar progress. Just to be sure (in case the wall-clock indications that "best-effort" process was performing I/O much faster than every 250ms), I started multiple simultaneous instances of the "best-effort" process, specifying no (zero) delay. Still, I saw no difference in performance between the processes in the two scheduling classes.

Just to be sure, I re-checked the scheduler class:

$ cat /sys/block/xvda/queue/scheduler
noop anticipatory deadline [cfq] 

What is it that I'm missing about how the cfq scheduler works?

If it matters, this is on a 2.6.18 kernel.

The ionice man page says

A program running with idle io priority will only get disk time when no other program has asked for disk io for a defined grace period.

Where is this "grace period" defined? Is it visable/tunable (perhaps via /sys)?

I have an application that unpacks an archive into /tmp, restoring the extracted files' modification and access times. Sometimes these files and the enclosing archive are many years old. After the files are extracted (sometimes many minutes or hours later), the unpacking software will selectively use/modify some of the files. Once its done, the application will remove the extracted files/tree. This operation can happen any time of the day (e.g., at times when tmpwatch is run by cron).

Every so often, the application will freak out because it can't find a file that it knows it has recently unpacked. What I think is happening is that tmpwatch is descending into the unpacked tree after when atime/mtime is adjusted (by unzip or tar that is driven by the application) to the distant past but before the application can access the relevant file. Since tmpwatch is by default looking at atime, it thinks the file is decrepit and removes it.

Arguably, the unpacking could be done elsewhere or the application could use appropriate flags to not reset the timestamps to the past. However, neither of those approaches is viable for various reasons.

I think I might be able to modify the tmpwatch cron script to take all of this into consideration (and make the most conservative decision regarding removing the files) by specifying the --ctime argument as well as --mtime (and the previously implied --atime). I'm a bit confused by the term "maximum of these times" used in the tmpwatch man page, though -- my initial reading (until I looked at the C source and thought otherwise) was that it took the maximum of the differences (meaning that it was more liberal in removing things). Does it actually mean "latest of these times" (and thus tmpwatch will leave alone files that were just unpacked as their inode was only recently touched)?