How does readahead(2) affects a iscsi device
Hi folks, Sorry but not so firm in kernel hacking and structures, but if I've understood this correctly it should perform normally?! The problem is that I do a readahead (the tool) on a iscsi device with infortrend iscsi san as backend to warm up caches and my connection died, correctly the whole controller died and have to be reseted. Has anyone an idea? Cheers Maddin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
strange behavior on kernel update
Hi, i'm using centos with dm-multipath and iscsi as a database system. All packages are normal centos packages from their mirrors. This night I was updating centos to the current release (5.3, previous version was 5.2). So the first thing I have done was stopping the multipathd and iscsi. After this I was doing the normal update stuff (yum check-updates, yum clean all, yum update glibc\*, yum update). During the last yum update the new kernel was installed (2.6.18-128.1.6.el5, previous was 2.6.18-92.1.22.el5). During the installation process of the kernel, the yum process hangs. Looking with ps for the hanging processes, I see that the kernel package was building the initrd. After killing this process and repeating the yum update process (this time only the kernel-package) about 5 times, the same strange failure occurs (process hangs on building initrd). The sixth time I was stracing the whole update process and see that the mkinitrd process does a wait-syscall for sth.. After killing this process again I went down to the server room to reboot the system and try another update process. I reboot the systems, stops multipathd and iscsi and starting the update process. On this update I could see that during the mkinitrd process, a kernel message device-mapper: failed path x:x:x:x occurs. Hmm this is strange I thought, because I've stopped multipathd and iscsi, so why means the kernel that a path is failed? Once again killing the mkinitrd process and then starting multipathd and iscsi I've tried another update process. And, yeha, it works??? I could reproduce this behavior on 2 machines, both centos with standard packages. So can anybody comprehend this failure or any ideas? Cheers Maddin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
AW: iscsi udev problem
Hallo, thanks for your help but i've fixed this problem. After reinitializing the luns on san, it was possible to get a block-device, which I can mount. Thanks maddin -Ursprüngliche Nachricht- Von: open-iscsi@googlegroups.com [mailto:[EMAIL PROTECTED] Im Auftrag von Konrad Rzeszutek Gesendet: Dienstag, 14. Oktober 2008 15:23 An: open-iscsi@googlegroups.com Betreff: Re: iscsi udev problem On Tue, Oct 14, 2008 at 11:53:25AM +0200, Mega Mailingliste wrote: Hi dudes, i've got a problem with iscsid (2.0-868) under centos (5.2) and a infortrend iscsi san (s12e-r1132-4). After mapping some partitions of a logical volume to our server, I can login via iscsiadm to this luns. The problem is that udev (or anything else, but I think it's udev) won't make a mapping from /dev/sgx to /dev/sdx, thus I The sg devices are very different from the sd ones. Or when you say mappings are you referring to the /sys/block/sdX/device/generic link? (and vice- versa)? That is the kernel constructing those. can't mount that device. I have no idea why :/ You can't mount the /dev/sdX device? Or is it that the /dev/sdX don't exist but only the /dev/sgX show up? Can you provide the 'lsscsi -v' output? Some strange behavior before was, that I've got the same problem on another test server, but after some reboots the block-device /dev/sdx exists. Cheers Martin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
