[Stgt-devel] data corruption problems with stgt (aborted journal, remounting ro)?

FUJITA Tomonori fujita.tomonori
Wed Feb 6 02:31:29 CET 2008


On Sat, 02 Feb 2008 11:19:11 +0100
Tomasz Chmielewski <mangoo at wpkg.org> wrote:

> FUJITA Tomonori schrieb:
> > On Sat, 02 Feb 2008 10:39:02 +0100
> > Tomasz Chmielewski <mangoo at wpkg.org> wrote:
> > 
> >> FUJITA Tomonori schrieb:
> >>> On Fri, 01 Feb 2008 13:05:41 +0100
> >>> Tomasz Chmielewski <mangoo at wpkg.org> wrote:
> >>>
> >>>> Tomasz Chmielewski schrieb:
> >>>>> Doesn't look my posts get to this list... or is it just lagged a lot? 
> >>>>> Resending.
> >>>>>
> >>>>>
> >>>>> Perhaps I'm doing something wrong - but with stgt I'm facing problems I 
> >>>>> didn't have with IET or SCST.
> >>>>>
> >>>>> Whenever I kill tgtd daemon and start it again (i.e., target server 
> >>>>> restart), the initiator detects an aborted journal and remount the 
> >>>>> device ro.
> >>>>>
> >>>>> Why is it so?
> >>>>>
> >>>>> What is the recommended way to kill the tgtd daemon? It doesn't seem to 
> >>>>> react on TERM signal.
> >>>> Hello, anyone there?
> >>>>
> >>>> Is there a way to restart tgtd daemon or a machine running tgtd, so that 
> >>>> iSCSI connections don't break?
> >>> What does your 'restart tgtd daemon' mean? For me, 'restart' involves
> >>> stopping tgtd daemon and it closes all the iSCSI connections.
> >> Stop it, and start again?
> >>
> >> Imagine you want to upgrade your tgtd daemon, a kernel running on that 
> >> machine, or you have to restart the target machine for some other reason 
> >> (i.e. your target machine died).
> >>
> >> With IET or SCST there is no problem with that - stop the target, and 
> >> iSCSI initiator will try to reconnect.
> > 
> > How did you restart IET?
> > 
> > /etc/init.d/iscsi-target restart
> 
> Yes. Or restarting the whole machine if I changed the kernel (which 
> would use the same iscsi-target script).
> 
> IET has some problems that it breaks when a number of initiators is 
> bigger than 50 or so - which needs two workarounds (iptables, and 
> increasing INCOMING_MAX in ietadm.h).
> 
> I described it a bit here:
> 
> http://blog.wpkg.org/2007/09/09/solving-reliability-and-scalability-problems-with-iscsi/

BTW, this problem should not exist in stgt. There is no limits about
it.



More information about the stgt mailing list