On Fri, Aug 09, 2013 at 03:44:00PM -0500, Mike Christie wrote: > On 08/06/2013 05:48 PM, Chris Leech wrote: > > I've been doing some digging into a reported scenario where a node > > update fails with an "iSCSI database failure" reported. > > > > The short of it is that it's possible to create node records for a > > target portal in both the old-style portal configuration file format, > > and the new-style configuration directory with tpgt. If they both exist > > on an update command a database failure may occur, depending on the > > unspecified return order of readdir. > > Just to make sure I am on the same page you have something like: > > [root@fio iqn.2012-06.com.noisy:tgt1]# ls -l > total 16 > -rw-------. 1 root root 1764 Aug 9 15:29 10.50.230.117,3260 > drw-------. 2 root root 4096 Aug 9 15:30 10.50.230.117,3260,1 > > One created from the discovery command and the other created from > iscsiadm -m node -p 10.50.230.117:3260 -T iqn.2012-06.com.noisy:tgt1 -o new
Yep, with the caveat that in order for that to happen the discovery one has to be there first. <snip/> > > The idbm code could be more forgiving of stat failures in these loops, > > either ignoring them or restarting the command if a filesystem change > > like this happens. In this case, it could check for the existence of a > > matching new-style entry, and convert that to a static record preserving > > the tpgt instead of adding a new static record without one. > > I think this would be ok. There should not be 2 entries. Cool, I'll see what I can come up with. Just wanted to verify my understanding of there being no valid reason to have multiple entries for a portal (other than access through multiple ifaces). > One question I have is does it cache for different instances of iscsiadm > or is a per process type of caching? If one instance of iscsiadm is > running some commands and so is another then locking would not prevent > issues where one instance is getting stale info. Is there any call we > can do to not get cached info? Something like O_DIRECT but for metadata? Not that I know of, I mean there's always going to be a race between being informed of a files existance and someone else removing it right? Unless there's some other coordination going on. The issue with readdir is that it's a library funtion that's called in a loop, built on top of getdents which can return an entire directory listing in one syscall. > On a side note if you want to go wild: > > That iscsi db code is really crusty. The iterator stuff is out of hand. > Could we just rewrite it and forget the old formats. To support old > setups, can we just do a script that gets run on startup or install that > converts the old style to the new one? Yeah, the upgrade issues are why I wasn't suggesting that (yet). I'll keep it in mind. - Chris -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/groups/opt_out.
