Re: [1/4] DST: Distributed storage documentation.

[Kay Sievers <kay.sievers@vrfy.org>]

On Mon, 2007-12-10 at 22:33 +0300, Evgeniy Polyakov wrote:
> On Mon, Dec 10, 2007 at 08:02:28PM +0100, Kay Sievers (kay.sievers@vrfy.org) wrote:
> > > uganda:~/codes# ls -l /sys/devices/storage/n-0-ffff81003ebc220/
> > > total 0
> > > drwxr-xr-x 2 root root    0 2007-12-10 13:23 power
> > > -r--r--r-- 1 root root 4096 2007-12-10 13:30 size
> > > -r--r--r-- 1 root root 4096 2007-12-10 13:30 start
> > > -r--r--r-- 1 root root 4096 2007-12-10 13:30 type
> > > -rw-r--r-- 1 root root 4096 2007-12-10 13:30 uevent
> > 
> > This is a "struct device" instance without a subsystem (bus/class),
> > right? It will not send an uevent to userspace. Is that intended? Why
> > don't you add them all to the dst bus? 
> 
> I created dst bus for storage devices only, nodes are very different
> objects, and actually they do not need any events from above, but I need
> to put some attributes somewhere, so it is 'empty' device.

Ok.

> > > Actually not - I have to set reference counter to something other than 1
> > > or +/- 1, and thus will have to call kref_get() in a loop, which is a
> > > very ugly step. Is there kref_set() or somethinglike that? At least not
> > > in 2.6.22 what I'm using for now.
> > 
> > Yeah, a loop would look pretty ugly. How about just adding kref_set(),
> > if you need it.
> 
> Well, then it distributed storage will not be able to build as
> standalone module, and kref_set() itself will not be accepted as a single 
> patch, since there are no in-kernel users :)
> It is easily doable though.

Most rules have exceptions. :) Send a patch, so we can see how it looks
like.

> > > > Why don't you use groups for the attributes?
> > > 
> > > For 3-4 attributes it is faster to register them in a loop than typing
> > > another structure :)
> > 
> > Yeah, but if you would need to recover from an error when the creation
> > of a file fails, a group would do the proper "rollback".
> 
> I do not care about such errors - if there is such an error for a file,
> which exports information about type of the node (i.e. string "L" or "R")
> or some other very meaningful info, then system has enough to care about
> instead of this, so dst does not do anything special - it ignores such
> errors :)
> 
> On exit path it will be checked and removed correctly.
> If there will be additional sysfs files, I think group is a good way to
> implement them.
> 
> > > > Why don't you use default attributes for the device, where you get all
> > > > error handling done by the core.
> > > 
> > > What is 'default attributes' and for what devices?
> > > All my sysfs files are so much trivial, so they do not need anything
> > > special and I do not see what is error handling you mentioned.
> > 
> > If all devices of a subsystem (bus/class) are of the same type, you can
> > set a default array of attributes in the "struct bus/class" to be
> > created at every device. If you have multiple types of devices in the
> > same subsytem (bus/class) you can to assign a the "device_type", which
> > has the default attribute group.
> > That way the core will create the files before the event is sent out to
> > userspace, and the files can be access from the event itself. Not sure
> > if that is needed for dst.
> 
> Ok, I see.
> 
> DST right now has 3 types of files - storage files, it is common for
> every storage device; node files, which are the same for every node; and
> per-algorithm private devices - they can be different (actually only
> mirroring algorithm exports something to userspace).
> 
> I think it is possible to use default attributes for storage devices,
> but node device does not have a bus/class, so they will be untouched.

Sounds fine.

Thanks,
Kay

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/