On 5-02-2008 14:38, "FUJITA Tomonori" <tomof@xxxxxxx> wrote: > On Tue, 05 Feb 2008 08:14:01 +0100 > Tomasz Chmielewski <mangoo@xxxxxxxx> 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? > > >> Imagine you have to reboot all your NFS clients when you reboot your NFS >> server. Not only that - your data is probably corrupted, or at least the >> filesystem deserves checking... Don't know if matters, but in my setup (iscsi on top of drbd+heartbeat) rebooting the primary server doesn't affect my iscsi traffic, SCST correctly manages stop/crash, by sending unit attention to clients on reconnect. Drbd+heartbeat correctly manages those things too. Still from an end-user POV, i was able to reboot/survive a crash only with SCST, IETD still has reconnect problems and STGT are even worst. Regards, --matteo - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
