01-06-2011 01:49 AM
FHWN12,
if you have only basic linux admin skills and don't want to spend much time, you better do not try to install the Debian system. The package has not been tested extensively.
Hajo
01-06-2011 02:32 AM
Hi!!
The performance is good, but not enough to connect to my XenServer.
Anyway these days proves.
Your work is amazing!
Thankssssssssssssssss
01-06-2011 11:21 AM
Hey all ![]()
Wanted to say thanks for the nice work Hajo. I managed to finally managed to get all my data off of the box, so that I could play with it.
Since I haven't seen to many people post about the 420(mainly the 440 and 220).
Your ssh/password solution worked just fine on the 420.
The debian install works as well; there are things I noticed but only one things to do with your custom firmware, but most of them had more to do with the generally layout of the default build of the offical firmware.
The only thing I ran into after installing your custom firmware was when I tried to install webmin, it complained a bit about some dependecies, even though they were on the box. I just did an apt-get -f install, which cleared it right up, and I have had no futher issues.
Here are a couple of notes that might help some others, but as you have noted Hajo this is not for the beginner.
1st thing I did was take and put the unit back to it's default state out of the box. This caused me an issue
right off the bat. I have 4 2TB drives in the unit as opposed to the standard 2 1TB drives is came with.
I tried setting it back to the default state with both the offical procedure, and with cleaning the mbr/gpt regions and letting the box just see them as blank drives.
WARNING DO NOT DO THIS IF YOU ARE NOT COMFORTABLE WITH EITHER OF THESE COMMANDS. THIS WILL REMOVE ALL INFORMATION ON THE DISKS!!!!!
I have found 2 ways to quickly get the drives back to a "blank" state. 1 is to connect them up to a linux box, and do:
dd if=/dev/zero of=/dev/<device name> bs=512 count=2
dd if=/dev/zero of=/dev/<device name> bs=512 seek=<put the total number of blocks, minus 200> *
*Note: This should only have to be done on larger drives, as most smaller drives will not use gpt.
2nd method(windows):
run diskpart in a command window
list disk (find # of disk you want to clean)
select disk <disk #>
clean
exit
This at 1st looked liked it was working, but would fail after about 8 hrs, and tell me that one of the drives were bad, after several days, and multiple attempts, in which I moved the disks around, and found that it would fail on different disks, but always the in the same place. I finally just put 2 of the 2TB drives into the unit, and let it rebuild, then I added the other disks in later(this does cause some extra steps later on to use them)
After finally getting them rebuilt back to the default state, I loaded up your firmware, and it went as it was written in the faq.
I have only put the 3 packages that you suggested and of course webmin, so far everything looks good, and other than one issue with accessing the unused portions of the disks(some manual steps required if you plan on using the disks in a raid 5)
As for the speed of cifs, or anything else, well I have only started playing with this build, this morning, so I haven't done a whole lot yet, as I am stilling getting it tweaked up, and general tests. Will report more later.
Cheers
01-07-2011 12:56 AM
lnxmnky,
thank you for your report and congratulations for beeing BA Debian GNU/Linux user #2 :-)
Cleaning of the disks shouldn't be necessary, as long as you haven't modified the official firmware. Your shared data still exists after Debian installation (side note: I do not guarantee anything, this is alpha software).
Do you have any details on the dependency-issue? The Debian dpkg system is in a clean state after installation and I wonder what was going wrong there.
Hajo
01-07-2011 01:18 PM
I don't have the logs as I forgot to turn them on, as I am just in the playing around stage, but as I am planning on doing a complete rebuild again in the next day or so, I will keep all of the logs, and share out with you anything I find.
From what I do remember however, I ran into the issue after installing the 3 packages you recommended. They installed cleanly, and I did not have any reason to check till I tried installing webmin.
It could just be that I caused the issue by something I did, as I was pretty much just trying tons of things out.
but like I said I will keep track of my steps, and let you know as soon as I get a chance to redo the install.
as for the cleaning of the drives, that was pretty much so that If anything went wrong
, I could try and isolate where the problem was.
btw as of now, I have managed to not only get webmin running without any issues, with the exception of the raid, which I had to do manually, but also getting it to run a full instance of apache, dns, ldap, ampache, all of which installed without issue either from apt-get or installing right from webmin.
I will be doing tests on those later to see how the box handles all of these services while under load of a half dozen boxes.
01-07-2011 02:30 PM
Hajo,
It would be better performance with SSD drives?
24 MBs async mode is too poor to vhd's on XenServer ...
Thanks a lot
01-08-2011 07:30 AM
lnxmnky,
if you install lots of packages you have to keep an eye on memory/cpu consumption. 128MB RAM (BA220) is not that much and if the system starts swapping, performance will decrease badly.
If you install packages via webmin and the Debian package manager, things probably get screwed up because you mix two installation sources. It might be a good idea to use Debian packages only. But I do not know anything about webmin, I've never used it.
ashantonio,
as you can see from the bonnie++ benchmark, local disk I/O speed is up to 50MB/s. I think the bottleneck is the CPU and network card. The network card driver seems to be unstable. It produces lots of kernel errors when stress-tested.
Hajo
01-08-2011 09:39 AM
actually I ran into the problem when installing webmin(debian package), which I am pretty sure that I did right after the 3 packages you recommended(again I don't think these were the problem), but not 100% sure I remembered the order, or if I did anything before installing webmin.
The 420 has a bit more memory (256). I will pull a dump of that box and post it.
Other than some high wait states(which I attribute a lot to the fact that I was still syncing the raid 5), I really didn't see the box getting overwelmed. swap was barely touched, cpu was high, but still pretty resonable given what I was doing at the time. Although I will agree that the cpu on this box is weak. Would be better with a dual core.
01-09-2011 12:01 PM
01-11-2011 11:21 PM
okay, I finally managed to do a full clean install of the firmware. The "problem" that I ran into the last time happened again. Turns out that I was not paying enough attention, and that the problems were just for dependencies that webmin needed to install, so there were no actual errors, just a case of lousy memory, and no logs. ![]()
One thing I did find out however is that the "datastorage" raid volume does not work after installing the firmware, I noticed that it happened the last time I installed this firmware as well. See below
debian-armel:/dev# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md0 1027416 481188 494036 50% /
tmpfs 127676 0 127676 0% /lib/init/rw
udev 10240 796 9444 8% /dev
tmpfs 127676 0 127676 0% /dev/shm
/dev/md2 504932 10283 468579 3% /mnt/md2
debian-armel:/dev# parted -l
Model: Seagate ST32000542AS (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 100MB 1169MB 1069MB ext3 raid
2 1169MB 2239MB 1070MB linux-swap raid
3 2239MB 2773MB 534MB ext3 raid
4 2773MB 2000GB 1998GB primary raid
Model: Seagate ST32000542AS (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 100MB 1169MB 1069MB ext3 primary raid
2 1169MB 2239MB 1070MB linux-swap primary raid
3 2239MB 2773MB 534MB ext3 primary raid
4 2773MB 2000GB 1998GB primary raid
Model: Seagate ST32000542AS (scsi)
Disk /dev/sdc: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 100MB 1169MB 1069MB ext3 primary raid
2 1169MB 2239MB 1070MB linux-swap primary raid
3 2239MB 2773MB 534MB ext3 primary raid
4 2773MB 2000GB 1998GB primary raid
Model: Seagate ST32000542AS (scsi)
Disk /dev/sdd: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 100MB 1169MB 1069MB ext3 primary raid
2 1169MB 2239MB 1070MB linux-swap primary raid
3 2239MB 2773MB 534MB ext3 primary raid
4 2773MB 2000GB 1998GB primary raid
debian-armel:/proc# cat mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md1 : active raid1 sdd2[1] sdc2[2] sdb2[3] sda2[0]
1044800 blocks [4/4] [UUUU]
md2 : active raid1 sdd3[1] sdc3[2] sdb3[3] sda3[0]
521408 blocks [4/4] [UUUU]
md0 : active raid1 sdd1[1] sdc1[2] sdb1[3] sda1[0]
1043840 blocks [4/4] [UUUU]
unused devices: <none>
Installing the firmware was done after returning the nas box to it's default state(had to do this, as I renamed the volume, and the firmware specifically looks for /datastorage/public. removing and rebuilding the volume really didn't make much sense as I use raid5, so it would have taken the same amount of time either way, and I wanted to remove any chance that I introduced an anomaly into the mix.
the only things done to the box at this point were, root password reset, adding in packages (nfs-kernel-server samba vsftpd webmin openssl libauthen-pam-perl libio-pty-perl apt-show-versions)
I am going to recreate the raid5 device manually from the old partitions(sda4,sdb4,sdc4,sdd4), and see what happens.
©2012 Seagate Technology LLC