Re: Online target database?

by Jeff Waller :: Rate this Message:

On Jun 27, 2008, at 6:14 AM, Marcel Ritter wrote:

> Jeff Waller schrieb:
>> Hello Marcel,
> Hi Jeff,
>>
>> Thanks for the reply, I see you've begun a project here, good
>> deal. Take it simply
>> as feedback (see below), but I disagree with the approach. I think
>> you'd be better
>> off pulling the file parser (but not the online command parser)
>> smarts out of ietd except for
>> stuff that doesn't change as the daemon is running and maintain its
>> online
>> configuration information using some Berkley dbm flavor.
> I'm not sure if I got it right: You'd like to take most of the file
> parser stuff out of ietd
> an put it into ietadm, right?

Yes.

>
> So ietadm converts plain config files into Berkley dbms read by
> ietd. All online changes
> are then written do db by whom: ietd or ietadm?

ietd

>
>
> Which advantages do you get by using db instead of plain files?
> - performance is not much of a topic

That's true, I can't envision a scenario on which this database is
being updated quickly but only occasionally; Typically as another
system adds storage wants them exposed via ietd, and changes in
user password/login stuff.

>
> - config file parsing is needed anyway
> - and: I like human-readable files ;-)

I think there's a place for having human readable files. It's
a comfortable way to get started for new iscsitarget users.

>
>
> Just to explain my (simplistic) approach:
> - Just keep the old code (as far as possible): if online changes
> were accepted by kernel
> and ietd, write data to disk

I think we're close here. I am of the same opinion. I have to admit,
I'm attracted
to the simplicity of something like (note necessary error checking
removed for
ease of reading).

save_to_backing_store(key,value)
{ if(backing_store_type == DBM)
{ dbm_write(store_id,key,value);
}
}

looks like we're taking about essentially 5 tables

the global attribute table
the target table
the target attribute table
the user table
the user attribute table

Is there more? For one thing I'm not sure I follow the schema w.r.t.
the target
user relationship, do you want to have the user named "User1" have
global
effect or is it restricted to per target? In the first case if you
change the
user password, the effect is across all targets referring to that user
name,
and in the 2nd case of course if you change the users password, it's
only
for that target, though I wonder if in that case, you should be
instead using
another user name.

>
>> Startup would pull in the configuration information, and online
>> updates would write out attributes. Augment
>> ietadm by putting the parser into it instead and allow it to write
>> out the entire DB
>> contents in human readable format if necessary. Am ready and
>> willing to help here.
> That'd be great ;-)
>
> Bye,
> Marcel
>> On Jun 27, 2008, at 2:21 AM, Marcel Ritter wrote:
>>
>>> Jeff Waller schrieb:
>>>> Reading the man page of ietadm, I find that ietadm will change
>>>> the state of
>>>> the iet daemon, but
>>>> that information will not be persistent. It's one of the known
>>>> issues.
>>>>
>>>> Searching the archive, there's been a couple of suggestions along
>>>> these
>>>> lines, but has there been
>>>> anything concretely done? Has there been any discussion about
>>>> making the
>>>> daemon use a more
>>>> online database (e.g. dbm) and it being the conduit for ietadm
>>>> modifying
>>>> that?
>>>> -Jeff
>>>>
>>> Hi Jeff,
>>>
>>> I've started to implement this, but it's not finished yet. However
>>> I don't like
>>> the idea of databases to store this information. open-iscsi for
>>> example uses
>>
>> database in the computer theoretic sense; agreed a relational
>> database like mysql or
>> postgres is overkill here especially since one would imagine the
>> reverse requirement;
>> ietd would offer resources (filesystems) so that these heavy
>> weight databases
>> can operate on filesystems exported from LVM allowing snapshots and
>> such.
>>
>> However that being said, I can imagine a future in which the
>> usernames/passwords
>> could be provided from a real heavy weight external process (LDAP,
>> Radius).
>>
>> But look, you're saying you don't want to use databases, but in
>> fact you are,
>> your inventing a schema and a persistant store in which elements
>> are written
>> directly to files in a directory structure and to do that you're
>> having to tack on a
>> parser and a file manager to boot. You're complicating the design
>> in order to
>> keep things simple.
>>
>>>
>>> the god old unix fashion "everything is a file" - and stores all
>>> information
>>> in nice little plain text files (everyone can edit with his
>>> favourite vi/emacs/whatever).
>>> So that's the way I'm doing it.
>>
>> True everything is a file, but I don't think text files are what
>> you want here. They
>> offer human readability but are not appropriate for online kind of
>> attribute changes.
>> Certainly they have their place in this project, but not as a means
>> of maintaining the
>> state of ietd.
>>
>>>
>>>
>>> As most users on linux will use open-iscsi as initiator (and
>>> iscsitarget as target),
>>> I think it's nice to have a similar way to configure iscsi on both
>>> sides.
>>
>> I'm pretty sure open-iscsi uses dbm
>>
>>>
>>>
>>> For now you'll have to create 3 extra directories in order to make
>>> this version work:
>>>
>>> /etc/ietd.d/
>>> /etc/ietd.d/targets
>>> /etc/ietd.d/tids
>>>
>>> What I've done so far:
>>> - Added code to save changed settings
>>> * users
>>> * targets
>>> * luns
>>> * global settings: only partially
>>>
>>> Still to do:
>>> - clean up global option parsing/handling
>>> - read config files to restore iscsi settings on restart
>>> - cleanups ...
>>> - lots more (I guess)
>>>
>>> I've attached the patch - but please consider this work in progress.
>>>
>>> Bye,
>>> Marcel
>>>
>>> --
>>> ----
>>> Dipl.-Inf. Marcel Ritter
>>> Linux/Novell
>>> Regionales Rechenzentrum Erlangen
>>> Tel: 09131 / 85-27808
>>> E-Mail: Marcel.Ritter@...
>>> ----
>
>
> --
> ----
> Dipl.-Inf. Marcel Ritter
> Linux/Novell
> Regionales Rechenzentrum Erlangen
> Tel: 09131 / 85-27808
> E-Mail: Marcel.Ritter@...
> ----
> Unix _IS_ user friendly... It's just selective about who its friends
> are.
>
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

« Return to Thread: Online target database?

LightInTheBox - Buy quality products at wholesale price!