Doug Goldstein wrote:
> > What is the benefit?
> >
> > Regards,
> >
> There is none really. Allow all use flags to exist in metadata.xml. It's
> really more of a clarification to the GLEP if this is allowed.

Agreed, it has no benefit at all plus would lead to some kind of useless
duplication of information. Stating <flag name='png' /> in metadata.xml
for global use flags makes basically no difference to IUSE="png", except
that we already have the latter one.

Tobias

Kees Hoekzema wrote:

Hello List,


I am adding the dm-devel list.

I think you want different settings in your multipath conf. For example
it looks like you are using directio to test paths and you want TUR or
the md3000i specific one which does not cause IO errors to passive paths.


You also want to make sure that you are using the md3000i hw handler or
scsh_dh_module if you are not already. The dm-devel guys can help you out.


You may want to post your multipath.conf on the thread.



Recently we bought a md3000i for our storage needs. This box comes with two
redundant controllers and both controller has two networkports. We connected
all four ports to our testing network, and I let some servers mount the
md3000i. The goal is to have all four connections on the server available
with a redundant network, so that we can failover if one switch dies or if a
controller dies.

However, the controller does not have support an active-active state, which
means that if you open four connections to the four ports, you will get two
faulty connections. With multipath this isn't a big problem as it can see
fairly quick if a controller is offline and it switches to the other
controller:

$ multipath -ll
webdata (36001ec9000d163110000067f484e260c) dm-0 DELL ,MD3000i
[size=2.0T][features=0][hwhandler=0]
\_ round-robin 0 [prio=1][enabled]
\_ 4:0:0:0 sda 8:0 [active][ready]
\_ round-robin 0 [prio=1000][active]
\_ 5:0:0:0 sdb 8:16 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 6:0:0:0 sdc 8:32 [active][faulty]
\_ round-robin 0 [prio=0][enabled]
\_ 7:0:0:0 sdd 8:48 [active][faulty]

(yes, I know the prio's are a bit strange, but that is to test something
else).

This all works quite well, but the problem we have is a massive amount of
spam in dmesg / kern.log / syslog. In syslog we get this every 3 seconds:
Aug 19 14:54:12 abaris kernel: [691035.298493] end_request: I/O error, dev
sdc, sector 0
Aug 19 14:54:12 abaris kernel: [691035.366443] end_request: I/O error, dev
sdd, sector 0
Aug 19 14:54:13 abaris multipathd: sdc: directio checker reports path is
down
Aug 19 14:54:13 abaris multipathd: sdd: directio checker reports path is
down

This is of course useful information, but to get this 28.800 times per day
in your log is a waste of space, beside making it impossible to read other
messages without grepping. Now this can still be reduced by adding some
syslog filters, but the other problem is dmesg:

$ dmesg
[691098.658507] end_request: I/O error, dev sdc, sector 0
[691098.704036] end_request: I/O error, dev sdd, sector 0
[691101.678930] end_request: I/O error, dev sdc, sector 0
[691101.738252] end_request: I/O error, dev sdd, sector 0

And this goes on for every 3 seconds as long as the connection is logged in.

So my questions:
- Is there a way to suppress those messages, either in the iscsi programs or
in multipath?
- If that fails, is it possible to tweak multipath in such a way that it
doesn't check the two failed paths, unless there is no other path available?
These two paths should become available only if the main controller dies.

Thanks in advance,
Kees Hoekzema


--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---



--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Tue, Aug 19, 2008 at 12:20:05PM -0500, Mike Christie wrote:
>
> Kees Hoekzema wrote:
> > Hello List,
>
> I am adding the dm-devel list.
>
> I think you want different settings in your multipath conf. For example
> it looks like you are using directio to test paths and you want TUR or
> the md3000i specific one which does not cause IO errors to passive paths.

He wants the RDAC hw handler and its path checker (rdac). The MD3000i is an
LSI re-branded box and is the same as the IBM DS3300.

>
> You also want to make sure that you are using the md3000i hw handler or
> scsh_dh_module if you are not already. The dm-devel guys can help you out.

Here is the multipath.conf he should be using for MD3000i (or for the DS3300
but will need to modify the vendor/model entry)

# Note: The same as the IBM DS3300
#
device {
vendor "DELL"
product "MD3000i"
product_blacklist "Universal Xport"
features "1 queue_if_no_path"
path_grouping_policy group_by_prio
hardware_handler "1 rdac"
path_checker rdac
prio "rdac"
failback immediate
}

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

> -----Original Message-----
> He wants the RDAC hw handler and its path checker (rdac). The MD3000i
> is an
> LSI re-branded box and is the same as the IBM DS3300.
>
> >
> > You also want to make sure that you are using the md3000i hw handler
> or
> > scsh_dh_module if you are not already. The dm-devel guys can help you
> out.
>
> Here is the multipath.conf he should be using for MD3000i (or for the
> DS3300
> but will need to modify the vendor/model entry)
>
> # Note: The same as the IBM DS3300
> #
> device {
> vendor "DELL"
> product "MD3000i"
> product_blacklist "Universal Xport"
> features "1 queue_if_no_path"
> path_grouping_policy group_by_prio
> hardware_handler "1 rdac"
> path_checker rdac
> prio "rdac"
> failback immediate
> }
>
>

This fixed the problem, although a simple flush was not enough to activate
the changes, so it took a bit longer to get the result I wanted. In the end
I saw that it was still using the direction path_checker and noticed that
you cannot change the 'path_checker' on the fly with just a multipath -F /
-v 2, but that a reload of the modules was needed.

$ multipath -ll
webdata (36001ec9000d163110000067f484e260c) dm-0 DELL ,MD3000i
[size=2.0T][features=0][hwhandler=1 rdac]
\_ round-robin 0 [prio=1000][active]
\_ 0:0:0:0 sda 8:0 [active][ready]
\_ round-robin 0 [prio=1][enabled]
\_ 1:0:0:0 sdb 8:16 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 2:0:0:0 sdc 8:32 [active][ghost]
\_ 3:0:0:0 sdd 8:48 [active][ghost]

That is the output of multipath now, and no more spam in my syslog or dmesg.

(The different priorities you see are because the second path (with a prio
of 1) is a longer path through 1 more switch, so I'd rather not give it a
high priority, and if the '1000' path fails, it just uses the '1' path.)

A big thanks to everyone who directed me on the right path

-kees

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

On Wed, Aug 20, 2008 at 12:57:24PM +0200, Kees Hoekzema wrote:
>
>
>
> > -----Original Message-----
> > He wants the RDAC hw handler and its path checker (rdac). The MD3000i
> > is an
> > LSI re-branded box and is the same as the IBM DS3300.
> >
> > >
> > > You also want to make sure that you are using the md3000i hw handler
> > or
> > > scsh_dh_module if you are not already. The dm-devel guys can help you
> > out.
> >
> > Here is the multipath.conf he should be using for MD3000i (or for the
> > DS3300
> > but will need to modify the vendor/model entry)
> >
> > # Note: The same as the IBM DS3300
> > #
> > device {
> > vendor "DELL"
> > product "MD3000i"
> > product_blacklist "Universal Xport"
> > features "1 queue_if_no_path"
> > path_grouping_policy group_by_prio
> > hardware_handler "1 rdac"
> > path_checker rdac
> > prio "rdac"
> > failback immediate
> > }
> >
> >
>
> This fixed the problem, although a simple flush was not enough to activate

Glad to hear that.

> the changes, so it took a bit longer to get the result I wanted. In the end
> I saw that it was still using the direction path_checker and noticed that
> you cannot change the 'path_checker' on the fly with just a multipath -F /
> -v 2, but that a reload of the modules was needed.

Ohh, you could also do: multipathd -k'reconfigure'

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Am Freitag 25 Juli 2008 01:25:25 schrieb Pierre Schmitz:
> I would like to orphan some packages I don't use anymore.

OK, a month later I will remove the following packages from [community]:

knetworkmanager
php-eaccelerator
php-xcache


--

Pierre Schmitz


Clemens-August-Straße 76
53115 Bonn

Telefon 0228 9716608
Mobil 0160 95269831
Jabber pierre@jabber.archlinux.de
WWW http://www.archlinux.de

On Monday 18 August 2008 12:47, Marko Vojinovic wrote:
> This is a rather old Celeron machine, 433 MHz with 320 MB ram. It was
> working properly up to a couple of days ago, when the first hd started
> dying out (which is understandable, given its age and the conditions it's
> in).
>
> But then at some point the computer stopped booting completely --- bios
> starts (and runs properly, so to speak), then the os (it's windows, I know,
> I know) starts booting and does not pass the bootloader phase. Actually, I
> do not know exactely where it stops, but all I get is a black screen, even
> with no option for a safe mode or anything.
>
> At first I just thought the problem was with the hd dying, but then the
> system failed to boot the fresh-and-tested Fedora 9 dvd. It spins up, the
> menu for installation appears (the text one, saying "type enter to install,
> type linux text to install in text mode" etc), and from that point the
> machine is locked up --- the function keys (which should provide extra info
> and help) do not work, the NumLock button does not toogle the appropriate
> led, nothing. It is frozen stiff, and all I can do is to reset it
> (ctrl-alt-del also does not work). Though, the dvd drive button does eject
> if pressed.
>
> After a minute or two standing, it resets itself automatically, and starts
> over.

Ok, just for the record --- the problem turned out to be a rather rare
situation of both hard drive *and* dvd drive failing simoultaneously. Once
both of them were replaced, the machine came back to life. I figured this out
by using Alan's approach of removing virtually everything unneccessary, and
even substituting vital components with spares (dvd drive, memory and
graphics card) one by one and in combinations, in order to find the failing
component.

Thanks to everyone for suggestions and info, the issue is now successfully
solved. :-)

Best, :-)
Marko

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

On Fri, 2008-08-22 at 11:14 +0000, Marko Vojinovic wrote:
> just for the record --- the problem turned out to be a rather rare
> situation of both hard drive *and* dvd drive failing simoultaneously

Two things dying at the same time makes me suspicious of the power
supply. I'd be concerned that something else might go, too.

--
[tim@localhost ~]$ uname -r
2.6.25.14-108.fc9.i686

Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.



--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

On Saturday 23 August 2008 07:19, Tim wrote:
> On Fri, 2008-08-22 at 11:14 +0000, Marko Vojinovic wrote:
> > just for the record --- the problem turned out to be a rather rare
> > situation of both hard drive *and* dvd drive failing simoultaneously
>
> Two things dying at the same time makes me suspicious of the power
> supply. I'd be concerned that something else might go, too.

Of course, I share that suspicion. :-)

However, since I was to spend a whole afternoon plugging and unplugging
hardware, I took the oportunity to do some upgrading with extra spare parts
as well (more memory, network card, etc). And when I saw that the old power
supply was declared with 135 watts max output, I definitely took the chance
of switching it for a 350W one. :-)

So even if the power supply was the true cause of failure for hd and dvd, it
is not an issue anymore.

Best, :-)
Marko

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Hello,

I just saw lua 5.1.4-1 in [extra] (only for i686, x86_64 still has
5.1.3-3) but an older release 5.1.3-5 in [testing]. I guess it is a
mistakenly uploaded package.

Regards

Stefan Husmann