Fred's questions

I think I messed up pretty bad. On my old system, I had 2 identical drive that were assembled with mdadm as a MD RAID 10 with a "far" layout.

When building my new system and migrating the two disks, I had a total brain fart, and instead of doing assemble and scan, I ran the following command:

mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdd1 /dev/sde1

When /dev/md0 wouldn't mount, I quickly realized that this was not what I intended, but the damage was done, as mdadm had started the sync. I have stopped mdadm (mdadm --stop /dev/md0), and now I can't mount the drives individually (unknown filesystem type 'linux_raid_member'), and parted doesn't see any filesystem on the partitions of the individual drives.

Is there a way to recover the data from either drive, or did mdadm completely destroy both drives in an unrecoverable way?

In the context of init scripts, according to the LSB specification, "Each conforming init script shall execute the commands in the file /lib/lsb/init-function", which then defines a couple of functions to be used when using daemons. One of those functions is start_daemon, which obviously "runs the specified program as a daemon" while checking if the daemon is already running.

I'm in the process of daemonizing a service app of mine, and I'm looking at how other daemons are run to try to "fit in". In the process of looking how it's done elsewhere, I noticed that not a single daemon on my Ubuntu 10.04 machine uses start_daemon. They all call start-stop-daemon directly. Same goes for my Fedora 14 machine. Should I try to play nice and be the first one to use start_daemon, or is there really no point and start-stop-daemon is the way to go since everybody is already using that? Why is there no daemons using LSB's functions?

I have a Ubuntu 8.04 LTS (server edition), and I need to write a udev rule for it to act upon plugging a USB thumb drive. However, I need a different action depending on the filesystem of the drive. I know I can use the ID_FS_TYPE environment variable to check for the filesystem on the drive.

Following instructions found here, I try a dummy udev rule as such :

KERNEL!="sd[a-z][0-9]", GOTO="my_udev_rule_end"
ACTION=="add", RUN+="/usr/bin/touch /tmp/test_udev_%E{ID_FS_TYPE}"
ACTION=="add", ENV{ID_FS_TYPE}=="vfat", RUN+="/usr/bin/touch /tmp/test_udev_it_works"
LABEL="my_udev_rule_end"

However, when I plug in a thumb drive with a vfat filesystem (which should trigger both rules), I end up with a file called /tmp/test_udev_vfat, meaning the first rule was triggered successfully, and that the ID_FS_TYPE environment variable is "vfat", but I don't have the other file, meaning that although I know the ID_FS_TYPE env variable is "vfat", I can't seem to check against it for a match.

I tried googling the thing, but pretty much every result seems to assume ENV{ID_FS_TYPE}=="vfat" works. I also tested the exact same udev rule on Ubuntu 10.04 LTS server, and I have the same result.

I'm probably missing something very simple, but I just don't get it. Does anyone see what is wrong with my udev rule that would prevent it from matching on ENV{ID_FS_TYPE}?

Thanks.

We frequently need to transfer huge files (upwards of 50 GB) between two hosts, and the transfer rate never seems to reach the expected throughput for the network. There are several points which could be the bottleneck, but each of their theorical upper limit are way over the actual transfer rate. Here's a typical setup :

Laptop --> 802.11n --> AP --> CAT 6 cable --> 10/100 Mbits router --> Desktop

In this connection, the bottleneck is clearly the router, which would limit the transfer rate at 100 Mbits/sec. Even then, I rarely see a transfer rate (with scp) exceeding 9.5 MB/s, which represents 76 Mbits/sec, or only 76% of theorical maximum limit.

Can there really be a 24% overhead at the access point, or is there something else limiting the speed? It could be disk I/O (although SATA is rated at 1.5 Gbps), or anything on the motherboard between the disk and the NIC (how can I measure that?).

Is there a way to know for sure(*) where the bottleneck is? If I can't get more than 76 Mbps from a 100 Mbps router, will upgrading the network to gigabit increase throughput or will I still get 76 Mbps because the bottleneck is elsewhere?

(*) or at least in a way convincing enough that a boss would agree to invest to upgrade that one part of the network

I need to setup a local Ubuntu mirror so the whole network doesn't need to hit remote servers in order to update and install new packages. Following a brief tutorial found here, I managed to get a server up and running that correctly mirrors packages from the main and restricted categories. However, when I call apt-get update on a client, I get a couple of errors such as :

Ign http://192.168.1.18 karmic/main Translation-fr
Ign http://192.168.1.18 karmic/restricted Translation-fr

Checking back on the server, I see that apt-mirror only took the binary-amd64 directory of the mirror, and didn't take i18n that would provide Translation-fr.

The manpage for apt-mirror doesn't say anything about i18n, and Google is of no help either. How do I properly mirror i18n?

My current mirror.list file is as follows :

############# config ##################
#
# set base_path    /var/spool/apt-mirror
#
# if you change the base path you must create the directories below with write privileges
#
# set mirror_path  $base_path/mirror
# set skel_path    $base_path/skel
# set var_path     $base_path/var
# set cleanscript $var_path/clean.sh
# set defaultarch  <running host architecture>
# set postmirror_script $var_path/postmirror.sh
set run_postmirror 0
set nthreads     20
set _tilde 0
#
############# end config ##############

deb http://mirror.cc.columbia.edu/pub/linux/ubuntu/archive karmic main restricted
deb http://mirror.cc.columbia.edu/pub/linux/ubuntu/archive karmic-updates main restricted

clean http://mirror.cc.columbia.edu/pub/linux/ubuntu/archive