Hanne's blog

This I have been looking for before:

http://ubuntuforums.org/showthread.php?t=710101

In short:
touch .pine-passfile
and you will be prompted to save password (works for both imaps and smtps).

I still have to press "enter" for smtps via tls since my server seems to insist on a retry. I might figure that out another day.

Update: Add disable-these-authenticators=CRAM-MD5 to .pinerc to get rid of the retry - see http://osdir.com/ml/mail.pine.general/2004-07/msg00088.html combined with how to disable the plain authenticator at http://www.mediusrete.org/progs/calpine.html .

Go to
http://www.promise.com/support/download/download2_eng.asp?productID=185&category=all&os=100

Read the Read me First file.

Download the newest firmware. In my case v2.28:

wget http://www.promise.com/upload/Support/Firmware/Mx10y_SR3.1.zip

- theres is off course a link on the download page. The zip file you get also contains the Release Notes.

From Release notes:
iSCSI host ping might cause watchdog of Mx10i.

Don't know if this should give me hope?

Put the firmware image in your tftp server root. (If you don't have a tftp server running, follow their instructions for Windows, or install a tftp server on Linux e.g. apt-get install tftpd-hpa).

scp ip_ms_all_20080630_15mb.img root@tftpserver:/tftpboot

Log in to the cli with

telnet 10.10.42.1 2300

where 10.10.42.1 should be replaced with your iSCSI SAN management ip address (make sure to enable telnet server on the iSCSI SAN) and run

 ptiflash -t -s 10.10.1.1 -f ip_ms_all_20080630_15mb.img

where you replace 10.10.1.1 with your tftp server address, off course.
This was a bit scary because the ip_ms_all_20080630_15mb.img filename is very different from the one in the instructions and because it took a long time, but have no fear, I boldly tested it and it worked

administrator@cli> ptiflash -t -s 10.10.1.1 -f ip_ms_all_20080630_15mb.img
Start transferring image, please wait ...
Flash image has been successfully transferred.
Start flashing image, please wait ...
  ... 100 percent completed...
Flash Completed.
/islavista/sw/bin/clitest: can't resolve symbol 'pce_quitCLIShell'
Connection closed by foreign host.

Now it got really scary. But the Read Me instructions does say "please be sure to reboot the VTrak" so I went down at power cycled it and voila! Running firmware v2.28.

It still remains to see if it solves the problem.

Oh and BTW it came up as /dev/sdd instead of /dev/sdc so I decided to solve the problem once and for all:

fileserver# tune2fs -U random /dev/sdd
fileserver# dumpe2fs -h /dev/sdd |grep UUID
dumpe2fs 1.38 (30-Jun-2005)
Filesystem UUID:          c5b23b3c-f8bf-47ef-8606-d3b414b4d03d

and put the following in /etc/fstab:

UUID=c64ce53b-b873-4acf-840c-bc0c3d893b3d       /protein         ext3  \
   _netdev,usrquota,grpquota,noauto 0 2

Bought cheap iSCSI device a few month ago. Too cheap, apparently.

Promise VTrak m610i 16-drive RAID iscsi.

I have seen this twice now: The volume goes read only. I can remount the file system ro but when I try to remount it again rw, mount says that the device is read only.

The first time I couldn't get through to the SAN on http, I got connection timed out while loading page. So I went down and reset it all, including the switch. It helped.

This time I could get in via http so I had a look at the event log. I see the following message several times:

Major: The controller is reset by Watch Dog timer

According to http://kb.promise.com/article.aspx?id=10077 the action to take is "Update to the new firmware. If persisting, replace the controller"

My vendor explains to me that the watchdog is a timer watching the internal OS in the iSCSI SAN and if it doesn't answer within the specified time, it resets the controller.

I shall off course upgrade the firmware if a new version is available, I haven't checked yet. But I fear this is a hardware issue.

There was another message in the log: Logical drive writeback cache maybe enabled w/o battery support. Though it did say later "Battery found" or something. So I tried to disable writeback cache. I don't know if that is a good idea or if I did it in the right place:

Procedure for getting it back online without crashing the iSCSI initiator
The last thing I shall share in this post is the order in which to do things when rebooting the iSCSI SAN, so as not to hang the server, which in my case is my file server.

umount -l /protein # and make sure it is unmounted
iscsiadm -m node -u # log out from iSCSI session

Reboot the thing - from http interface or the hard way

/etc/init.d/open-iscsi restart # to log in again
mount /protein 

where /protein is off course the mount point for my iSCSI device, yours would be different.

This is just to mention that TDC 3g works out of the box with Ubuntu 8.10 and Network Manager. Just enter the pin code and it runs happily! This is tested on a friend's laptop.

Problem: ls and writes to disk hangs for a long time, then suddenly executes. Feels a bit like NFS problems for the user except is is a local file system (Dell MD1000 Perc6e controller with 8 1TB SATA disks running RAID6). The file system is ext3 with dir_index enabled. Kernel 2.6.18 from debian etch. Hardware is a Dell PowerEdge R900 Intel Xeon 4 x 6 core, 128 GB RAM.

Quick fix

echo "2" > /proc/sys/vm/dirty_background_ratio
echo "4000" > /proc/sys/vm/dirty_expire_centisecs

The dirty_background_ratio is the percentage of memory that should be dirty before pdflush is called. With 128GB memory the default 10% is a lot.

dirty_expire_centisecs how many 100th's of seconds memory must have been dirty to be written to disk by pdflush. I changed it from 3000 to 4000, i.o.w. let us write a bit more in memory before it is flushed.

I haven't found out for sure which process is causing the problem, it has run fine for 2 months. Well it has crashed but I haven't seen this behaviour before. On the system disk (sda) everything works fine so I assume that some user processes accessing the MD1000 array (sdb) is causing it. And reads seems to work fine once they start:

iris:~# hdparm -Tt /dev/sdb

/dev/sdb:
 Timing cached reads:   5000 MB in  2.00 seconds = 2500.87 MB/sec
 Timing buffered disk reads:  254 MB in  3.01 seconds =  84.38 MB/sec

iris:~#  hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   4900 MB in  2.00 seconds = 2451.44 MB/sec
 Timing buffered disk reads:  378 MB in  3.00 seconds = 125.80 MB/sec

Next step is to upgrade the kernel and see if this gives some improvement, also this will allow me to run iotop.

Links

• http://ccrma-mail.stanford.edu/pipermail/planetccrma/2004-November/006713.html told me that I wasn't looking for a kjournald problem but a vm problem.
• http://www.dba-oracle.com/t_tuning_linux_kernel_2_6_oracle.htm told me which parameters to tune.
• http://www.linuxinsight.com/proc_sys_vm_dirty_background_ratio.html and
  http://www.linuxinsight.com/proc_sys_vm_dirty_expire_centisecs.html told me what they do.

Nice tools atop, iostat, vmstat, sar, hdparm, top, kill -STOP pid / kill -CONT pid.

Update Installed kernel 2.6.28 and selected a lot of options that looked promising for a large machine. Now the machine has been running fine for 3 days - not much but definitely a start. It cannot find the DVD drive anymore, tough Must have forgotten some driver but the sr_mod driver is there alright.