This way, we get double the bandwidth, that is 200Mbps, when using Mode zero, which does a round robin scheme.

Practically, we got over 200Mbps! 100Mbps should’ve given us 12MB/s, but instead we achieved 30.1 MB/s using bonding.

Finding the proper parameters for Ubuntu’s was not an easy task, and we found a few guides, unfortunately, none of them had full correct information! We had to collect stuff from each guide to make it work.

I’ll post the whole thing on a dedicated page, for those who are interested.

I told 3baid to use super-glue, but he didn’t take me seriously. I think I’ll super-glue the bloody cable to the port when 3baid is not in the dewaniya…
Data corruption is not a friendly thought…

As for assigning static names to disks, one of the guys in #linux (DALNet) suggested using /dev/disk/by-serial which identifies each hard disk by its vendor, model and serial number, and further more, detects each partition, which is exactly what we need.
I’ll poke around this weekend and see how to do it with udev.

We were having problems stopping the RAID arrays after un-mounting the logical drive. Always got an error that the device is busy or being used.
I suspected that the Volume Manager is the one hogging the arrays, and I was right. I looked around on how to stop the volume group manager, and the solution was:
vgchange -a n

-a is for volume group availability, and “n” is for no. To re-activate, use “y”

I haven’t tested it, since the guys are abusing Adam, but I will tomorrow morning when they are snoozing in their mothers’ basement. I mean their beds.

user@Adam:~$ blkid /dev/sd[abcef]1
/dev/sda1: UUID=”0796d046-37e3-eeab-b132-d6d5278b5397″ TYPE=”mdraid”
/dev/sdb1: UUID=”0796d046-37e3-eeab-b132-d6d5278b5397″ TYPE=”mdraid”
/dev/sdc1: UUID=”0796d046-37e3-eeab-b132-d6d5278b5397″ TYPE=”mdraid”
/dev/sde1: UUID=”0796d046-37e3-eeab-b132-d6d5278b5397″ TYPE=”mdraid”
/dev/sdf1: UUID=”0796d046-37e3-eeab-b132-d6d5278b5397″ TYPE=”mdraid”

user@Adam:~$ blkid /dev/sd[ag]1
/dev/sda1: UUID=”0796d046-37e3-eeab-b132-d6d5278b5397″ TYPE=”mdraid”
/dev/sdg1: UUID=”98d7c538-1f5e-5131-e164-0bd68cf09905″ TYPE=”mdraid”

In the first group, you can see that they all have the same UUID. This is nor a mistake. This is the UUID of the array they belong to, and this is what helped us keeping the data intact, when the device names changed.

In the 2nd run, you can see that there are 2 different UUIDs. This is because these 2 devices are from 2 different arrays.

So, how to get the UUID of the device itself, and not the array it belongs to?
I have no clue. Yet.

But I noticed that the UUID of the device is not the same as the superblock UUID, but all devices of the same array have the same… Check this:
mdadm -E /dev/sda1 | more
/dev/sda1:
Magic : a92b4efc
Version : 00.90.00
UUID : 46d09607:abeee337:d5d632b1:97538b27

For other partitions of the same array, the UUID is the same, but it’s different than the one reported by “blkid” o_O

I’d love to hear an explanation, although I’ll be more interested in finding a solution to get the UUID of each partition (assuming there is one).

From the Goolgizing I’ve been doing, I noticed that SCSI disks do have UUIDs, but there’s no mention of SATA. Maybe they don’t have any?
If that’s the case, then the whole idea is down the drains…

Knowing our luck, it was inevitable to go through hell. For some reason, the BIOS didn’t like the new disk, and decided that the disk order should be changed, too.
3baid figured out that the BIOS changed the order of disks, which is why we couldn’t boot up for over an hour. Unfortunately, we faced much more problems.

When the system booted, the new disk partitions were added as spares to both arrays, and on the first array, we marked one 500GB disk as faulty to remove it later. The recovery process proceeded as it should.

Later that day, 3baid tells me that all disks are marked as spares on the first array, and that it’s no longer active!!!

We tried to bring it up, but it refused. Also, the disk names changed again, and a disk disappeared from the arrays.

Today, we were able to bring up the arrays again and the data is intact (since we disabled Samba to not allow anyone to write to the disks).

We still have one disk missing. It could be either the disk’s fault, or some problem with the SATA port or cable.

Either way, to prevent future problems with disk naming, we’re cooking a plan to assign static names to disks by using their UUIDs.

Details will come up later.

Yes, DC++ is considered as P2P traffic unfortunately :/

Yes, I was able to get the entire file from you.

Here’s a question.. Does DC++ count as P2P traffic?

So there wasn’t a problem with transferring files? Did you get the file list in one piece?

I’m working to get a client running on my pc at home to share off the NAS.

Awesome work guys.

The tech support sent us a beta firmware via email :]
We’re beta testers now :P