From: FUJITA Tomonori <tomof@acm.org>
To: mangoo@wpkg.org
Cc: tomof@acm.org, James.Bottomley@HansenPartnership.com,
bart.vanassche@gmail.com, vst@vlnb.net,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
fujita.tomonori@lab.ntt.co.jp, scst-devel@lists.sourceforge.net,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
stgt-devel@lists.berlios.defujita.tomonori@lab.ntt.co.jp
Subject: Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
Date: Wed, 6 Feb 2008 01:43:37 +0900 [thread overview]
Message-ID: <20080206014340X.tomof@acm.org> (raw)
In-Reply-To: <47A889AB.9090301@wpkg.org>
On Tue, 05 Feb 2008 17:07:07 +0100
Tomasz Chmielewski <mangoo@wpkg.org> wrote:
> FUJITA Tomonori schrieb:
> > On Tue, 05 Feb 2008 08:14:01 +0100
> > Tomasz Chmielewski <mangoo@wpkg.org> wrote:
> >
> >> James Bottomley schrieb:
> >>
> >>> These are both features being independently worked on, are they not?
> >>> Even if they weren't, the combination of the size of SCST in kernel plus
> >>> the problem of having to find a migration path for the current STGT
> >>> users still looks to me to involve the greater amount of work.
> >> I don't want to be mean, but does anyone actually use STGT in
> >> production? Seriously?
> >>
> >> In the latest development version of STGT, it's only possible to stop
> >> the tgtd target daemon using KILL / 9 signal - which also means all
> >> iSCSI initiator connections are corrupted when tgtd target daemon is
> >> started again (kernel upgrade, target daemon upgrade, server reboot etc.).
> >
> > I don't know what "iSCSI initiator connections are corrupted"
> > mean. But if you reboot a server, how can an iSCSI target
> > implementation keep iSCSI tcp connections?
>
> The problem with tgtd is that you can't start it (configured) in an
> "atomic" way.
> Usually, one will start tgtd and it's configuration in a script (I
> replaced some parameters with "..." to make it shorter and more readable):
Thanks for the details. So the way to stop the daemon is not related
with your problem.
It's easily fixable. Can you start a new thread about this on
stgt-devel mailing list? When we agree on the interface to start the
daemon, I'll implement it.
> tgtd
> tgtadm --op new ...
> tgtadm --lld iscsi --op new ...
(snip)
> So the only way to start/restart tgtd reliably is to do hacks which are
> needed with yet another iSCSI kernel implementation (IET): use iptables.
>
> iptables <block iSCSI traffic>
> tgtd
> sleep 1
> tgtadm --op new ...
> tgtadm --lld iscsi --op new ...
> iptables <unblock iSCSI traffic>
>
>
> A bit ugly, isn't it?
> Having to tinker with a firewall in order to start a daemon is by no
> means a sign of a well-tested and mature project.
>
> That's why I asked how many people use stgt in a production environment
> - James was worried about a potential migration path for current users.
I don't know how many people use stgt in a production environment but
I'm not sure that this problem prevents many people from using it in a
production environment.
You want to reboot a server running target devices while initiators
connect to it. Rebooting the target server behind the initiators
seldom works. System adminstorators in my workplace reboot storage
devices once a year and tell us to shut down the initiator machines
that use them before that.
WARNING: multiple messages have this Message-ID (diff)
From: FUJITA Tomonori <tomof@acm.org>
To: mangoo@wpkg.org
Cc: tomof@acm.org, James.Bottomley@HansenPartnership.com,
bart.vanassche@gmail.com, vst@vlnb.net,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
fujita.tomonori@lab.ntt.co.jp, scst-devel@lists.sourceforge.net,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
stgt-devel@lists.berlios.de
Cc: fujita.tomonori@lab.ntt.co.jp
Subject: Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
Date: Wed, 6 Feb 2008 01:43:37 +0900 [thread overview]
Message-ID: <20080206014340X.tomof@acm.org> (raw)
In-Reply-To: <47A889AB.9090301@wpkg.org>
On Tue, 05 Feb 2008 17:07:07 +0100
Tomasz Chmielewski <mangoo@wpkg.org> wrote:
> FUJITA Tomonori schrieb:
> > On Tue, 05 Feb 2008 08:14:01 +0100
> > Tomasz Chmielewski <mangoo@wpkg.org> wrote:
> >
> >> James Bottomley schrieb:
> >>
> >>> These are both features being independently worked on, are they not?
> >>> Even if they weren't, the combination of the size of SCST in kernel plus
> >>> the problem of having to find a migration path for the current STGT
> >>> users still looks to me to involve the greater amount of work.
> >> I don't want to be mean, but does anyone actually use STGT in
> >> production? Seriously?
> >>
> >> In the latest development version of STGT, it's only possible to stop
> >> the tgtd target daemon using KILL / 9 signal - which also means all
> >> iSCSI initiator connections are corrupted when tgtd target daemon is
> >> started again (kernel upgrade, target daemon upgrade, server reboot etc.).
> >
> > I don't know what "iSCSI initiator connections are corrupted"
> > mean. But if you reboot a server, how can an iSCSI target
> > implementation keep iSCSI tcp connections?
>
> The problem with tgtd is that you can't start it (configured) in an
> "atomic" way.
> Usually, one will start tgtd and it's configuration in a script (I
> replaced some parameters with "..." to make it shorter and more readable):
Thanks for the details. So the way to stop the daemon is not related
with your problem.
It's easily fixable. Can you start a new thread about this on
stgt-devel mailing list? When we agree on the interface to start the
daemon, I'll implement it.
> tgtd
> tgtadm --op new ...
> tgtadm --lld iscsi --op new ...
(snip)
> So the only way to start/restart tgtd reliably is to do hacks which are
> needed with yet another iSCSI kernel implementation (IET): use iptables.
>
> iptables <block iSCSI traffic>
> tgtd
> sleep 1
> tgtadm --op new ...
> tgtadm --lld iscsi --op new ...
> iptables <unblock iSCSI traffic>
>
>
> A bit ugly, isn't it?
> Having to tinker with a firewall in order to start a daemon is by no
> means a sign of a well-tested and mature project.
>
> That's why I asked how many people use stgt in a production environment
> - James was worried about a potential migration path for current users.
I don't know how many people use stgt in a production environment but
I'm not sure that this problem prevents many people from using it in a
production environment.
You want to reboot a server running target devices while initiators
connect to it. Rebooting the target server behind the initiators
seldom works. System adminstorators in my workplace reboot storage
devices once a year and tell us to shut down the initiator machines
that use them before that.
next prev parent reply other threads:[~2008-02-05 16:43 UTC|newest]
Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-23 14:22 Integration of SCST in the mainstream Linux kernel Bart Van Assche
2008-01-23 14:22 ` Bart Van Assche
2008-01-23 17:11 ` Vladislav Bolkhovitin
2008-01-29 20:42 ` James Bottomley
2008-01-29 21:31 ` Roland Dreier
2008-01-29 23:32 ` FUJITA Tomonori
2008-01-30 1:15 ` [Scst-devel] " Vu Pham
2008-01-30 8:38 ` Bart Van Assche
2008-01-30 10:56 ` FUJITA Tomonori
2008-01-30 11:40 ` Vladislav Bolkhovitin
2008-01-30 13:10 ` Bart Van Assche
2008-01-30 13:54 ` FUJITA Tomonori
2008-01-30 13:54 ` FUJITA Tomonori
2008-01-31 7:48 ` Bart Van Assche
2008-01-31 13:25 ` Nicholas A. Bellinger
2008-01-31 14:34 ` Bart Van Assche
2008-01-31 14:44 ` Nicholas A. Bellinger
2008-01-31 15:50 ` Vladislav Bolkhovitin
2008-01-31 16:25 ` [Scst-devel] " Joe Landman
2008-01-31 17:08 ` Bart Van Assche
2008-01-31 17:13 ` Joe Landman
2008-01-31 18:12 ` David Dillow
2008-02-01 11:50 ` Vladislav Bolkhovitin
2008-02-01 11:50 ` Vladislav Bolkhovitin
2008-02-01 12:25 ` Vladislav Bolkhovitin
2008-01-31 17:14 ` Nicholas A. Bellinger
2008-01-31 17:40 ` Bart Van Assche
2008-01-31 18:15 ` Nicholas A. Bellinger
2008-02-01 9:08 ` Bart Van Assche
2008-02-01 8:11 ` Bart Van Assche
2008-02-01 10:39 ` Nicholas A. Bellinger
2008-02-01 11:04 ` Bart Van Assche
2008-02-01 12:05 ` Nicholas A. Bellinger
2008-02-01 13:25 ` Bart Van Assche
2008-02-01 14:36 ` Nicholas A. Bellinger
2008-01-30 16:34 ` James Bottomley
2008-01-30 16:50 ` Bart Van Assche
2008-02-02 15:32 ` Pete Wyckoff
2008-02-05 17:01 ` Erez Zilber
2008-02-06 12:16 ` Bart Van Assche
2008-02-06 16:45 ` Benny Halevy
2008-02-06 17:06 ` Roland Dreier
2008-02-18 9:43 ` Erez Zilber
2008-02-18 11:01 ` Bart Van Assche
2008-02-20 7:34 ` Erez Zilber
2008-02-20 8:41 ` Bart Van Assche
2008-01-30 11:18 ` Vladislav Bolkhovitin
2008-01-30 8:29 ` Bart Van Assche
2008-01-30 16:22 ` James Bottomley
2008-01-30 17:03 ` Bart Van Assche
2008-02-05 7:14 ` [Scst-devel] " Tomasz Chmielewski
2008-02-05 13:38 ` FUJITA Tomonori
2008-02-05 13:38 ` FUJITA Tomonori
2008-02-05 16:07 ` Tomasz Chmielewski
2008-02-05 16:21 ` Ming Zhang
2008-02-05 16:43 ` FUJITA Tomonori [this message]
2008-02-05 16:43 ` FUJITA Tomonori
2008-02-05 17:09 ` Matteo Tescione
2008-02-05 17:09 ` Matteo Tescione
2008-02-06 1:29 ` FUJITA Tomonori
2008-02-06 2:01 ` Nicholas A. Bellinger
2008-01-30 11:17 ` Vladislav Bolkhovitin
2008-02-04 12:27 ` Vladislav Bolkhovitin
2008-02-04 13:53 ` Bart Van Assche
2008-02-04 17:00 ` David Dillow
2008-02-04 17:08 ` Vladislav Bolkhovitin
2008-02-05 16:25 ` Bart Van Assche
2008-02-05 18:18 ` Linus Torvalds
2008-02-04 15:30 ` James Bottomley
2008-02-04 16:25 ` Vladislav Bolkhovitin
2008-02-04 17:06 ` James Bottomley
2008-02-04 17:16 ` Vladislav Bolkhovitin
2008-02-04 17:25 ` James Bottomley
2008-02-04 17:56 ` Vladislav Bolkhovitin
2008-02-04 18:22 ` James Bottomley
2008-02-04 18:38 ` Vladislav Bolkhovitin
2008-02-04 18:54 ` James Bottomley
2008-02-05 18:59 ` Vladislav Bolkhovitin
2008-02-05 19:13 ` James Bottomley
2008-02-06 18:07 ` Vladislav Bolkhovitin
2008-02-07 13:13 ` [Scst-devel] " Bart Van Assche
2008-02-07 13:13 ` Bart Van Assche
2008-02-07 13:45 ` Vladislav Bolkhovitin
2008-02-07 22:51 ` david
2008-02-08 10:37 ` Vladislav Bolkhovitin
2008-02-09 7:40 ` david
2008-02-08 11:33 ` Nicholas A. Bellinger
2008-02-08 14:36 ` Vladislav Bolkhovitin
2008-02-08 23:53 ` Nicholas A. Bellinger
2008-02-15 15:02 ` Bart Van Assche
2008-02-07 15:38 ` [Scst-devel] " Nicholas A. Bellinger
2008-02-07 20:37 ` Luben Tuikov
2008-02-08 10:32 ` Vladislav Bolkhovitin
2008-02-09 7:32 ` Luben Tuikov
2008-02-11 10:02 ` Vladislav Bolkhovitin
2008-02-08 11:53 ` [Scst-devel] " Nicholas A. Bellinger
2008-02-08 14:42 ` Vladislav Bolkhovitin
2008-02-09 0:00 ` Nicholas A. Bellinger
2008-02-04 18:29 ` Linus Torvalds
2008-02-04 18:49 ` James Bottomley
2008-02-04 19:06 ` Nicholas A. Bellinger
2008-02-04 19:19 ` Nicholas A. Bellinger
2008-02-04 19:44 ` Linus Torvalds
2008-02-04 20:06 ` [Scst-devel] " 4news
2008-02-04 20:06 ` 4news
2008-02-04 20:24 ` Nicholas A. Bellinger
2008-02-04 21:01 ` J. Bruce Fields
2008-02-04 21:24 ` Linus Torvalds
2008-02-04 22:00 ` Nicholas A. Bellinger
2008-02-04 22:57 ` Jeff Garzik
2008-02-04 23:45 ` Linus Torvalds
2008-02-05 0:08 ` Jeff Garzik
2008-02-05 1:20 ` Linus Torvalds
2008-02-05 8:38 ` Bart Van Assche
2008-02-05 17:50 ` Jeff Garzik
2008-02-06 10:22 ` Bart Van Assche
2008-02-06 14:21 ` Jeff Garzik
2008-02-05 13:05 ` Olivier Galibert
2008-02-05 18:08 ` Jeff Garzik
2008-02-05 18:08 ` Jeff Garzik
2008-02-05 19:01 ` Vladislav Bolkhovitin
2008-02-04 22:43 ` Alan Cox
2008-02-04 17:30 ` Douglas Gilbert
2008-02-05 2:07 ` [Scst-devel] " Chris Weiss
2008-02-05 14:19 ` FUJITA Tomonori
2008-02-05 14:19 ` FUJITA Tomonori
2008-02-04 22:59 ` Nicholas A. Bellinger
2008-02-04 23:00 ` James Bottomley
2008-02-04 23:12 ` Nicholas A. Bellinger
2008-02-04 23:12 ` Nicholas A. Bellinger
2008-02-04 23:16 ` Nicholas A. Bellinger
2008-02-04 23:16 ` Nicholas A. Bellinger
2008-02-05 18:37 ` James Bottomley
2008-02-04 23:04 ` Jeff Garzik
2008-02-04 23:27 ` Linus Torvalds
2008-02-05 19:01 ` Vladislav Bolkhovitin
2008-02-05 19:12 ` Jeff Garzik
2008-02-05 19:21 ` Vladislav Bolkhovitin
2008-02-06 0:11 ` Nicholas A. Bellinger
2008-02-06 1:43 ` Nicholas A. Bellinger
2008-02-12 16:05 ` [Scst-devel] " Bart Van Assche
2008-02-13 3:44 ` Nicholas A. Bellinger
2008-02-13 6:18 ` CONFIG_SLUB and reproducable general protection faults on 2.6.2x Nicholas A. Bellinger
2008-02-13 16:37 ` Nicholas A. Bellinger
2008-02-06 0:17 ` Integration of SCST in the mainstream Linux kernel Nicholas A. Bellinger
2008-02-06 0:48 ` Nicholas A. Bellinger
2008-02-06 0:51 ` Nicholas A. Bellinger
2008-02-05 0:07 ` Matt Mackall
2008-02-05 0:24 ` Linus Torvalds
2008-02-05 0:42 ` Jeff Garzik
2008-02-05 0:45 ` Matt Mackall
2008-02-05 4:43 ` [Scst-devel] " Matteo Tescione
2008-02-05 4:43 ` Matteo Tescione
2008-02-05 5:07 ` James Bottomley
2008-02-05 13:38 ` FUJITA Tomonori
2008-02-05 13:38 ` FUJITA Tomonori
2008-02-05 19:00 ` Vladislav Bolkhovitin
2008-02-05 17:10 ` Erez Zilber
2008-02-05 19:02 ` Bart Van Assche
2008-02-05 19:02 ` Vladislav Bolkhovitin
-- strict thread matches above, loose matches on Subject: below --
2008-02-09 7:44 [Scst-devel] " Luben Tuikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080206014340X.tomof@acm.org \
--to=tomof@acm.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=bart.vanassche@gmail.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mangoo@wpkg.org \
--cc=scst-devel@lists.sourceforge.net \
--cc=stgt-devel@lists.berlios.defujita.tomonori \
--cc=torvalds@linux-foundation.org \
--cc=vst@vlnb.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.