aoetools-discuss — General discussion list for AoE and aoetools

[Aoetools-discuss] [patch] Build error with gcc-10

[Christoph B. <sou...@ma...>]

Hello,

vblade fails to build with gcc-10¹, According to the Gentoo wiki², the
current definition in dat.h is no longer acceptable. The patch moves the
definitions to aoe.c and changes dat.h to declaration. Works for me.

Please apply this, or do whatever resolves the situation.

Regards,

    Christoph

¹ Debian's bug report is at https://bugs.debian.org/957908
² https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common

[Aoetools-discuss] vblade-persist

[Eriel P. <eri...@gm...>]

Hola colegas.

cuando intento

vblade-persist restart all

me dice:

warning: /var/lib/vblade-persist/vblades/e0.0: unable to open 
supervise/ok: file does not exist


Alguna sugerencia. El fichero si esta donde dice y con todos los permisos.

Re: [Aoetools-discuss] ROM target type

[Ben K. <sha...@gm...>]

So I've found a solution! Thanks to "cc_Smart" <sm...@sm...> for
pointing back to tgt iSCSI target.

The closest I had come before this was using iSCSI with the pSCSI
backend in the kernel, but that seems to produce a memory leak that
consumes all RAM ... some sort of infinite loop on initiator login?

Going back to userspace tools did the trick for me, but I had to dig
to find the right flags to give it.

1. First, find what /dev/sg device maps to the DVD drive
# for dev in /dev/sg*; do sdparm "$dev" | grep '\[cd/dvd\]$'; done
In my case, /dev/sg0 is the generic device for /dev/sr0

2. Create the iSCSI target as normal (including ACL/whitelist)

3. Create the iSCSI logical unit
# tgtadm --mode logicalunit --op new --tid 1 --lun 1 --backing-store
/dev/sg0 --device-type pt --bstype sg
# tgtadm --mode logicalunit --op update --tid 1 --lun 1 --params removable=1

4. Log in on the initiator as normal

I thought at first I was hitting another bug in tgtd, but it's just
that the BluRay disc I was testing with only works in one of my two
drives (despite the drives being identical models). ¯\_(ツ)_/¯

My /etc/tgt/conf.d file for 5 DVD drives (I should probably write some
udev rules for by-id symlinks to sg devices):
default-driver iscsi

<target iqn.2007-03:dvdroms:frankie>
bs-type sg
device-type pt
removable 1
readonly 1
initiator-address 192.168.9.9
block-size 512

backing-store /dev/sg0
backing-store /dev/sg1
backing-store /dev/sg2
backing-store /dev/sg4
backing-store /dev/sg5
</target>

Have fun with this info. Or not :)

Thanks all,
Ben Klein
On Wed, 24 Oct 2018 at 10:03, Ed L. Cashin
<ec...@us...> wrote:
>
> I would also assume that remotely ejecting would not work.
>
> Sorry to be of little help.
>
> On Tue, Oct 23, 2018 at 6:29 AM Ben Klein <sha...@gm...> wrote:
> >
> > I tried that. It still treats the device as a file. So first, the disc
> > needs to be loaded before starting vblade, and libdvdcss/libaacs can't
> > decode encrypted discs. I would assume that remotely ejecting would
> > also not work with vblade as the target.
>
>
>
> --
>   Ed Cashin <ec...@no...>
>   http://noserose.net/e/
>   http://www.coraid.com/

Re: [Aoetools-discuss] ROM target type

[Ed L. C. <ec...@us...>]

I would also assume that remotely ejecting would not work.

Sorry to be of little help.

On Tue, Oct 23, 2018 at 6:29 AM Ben Klein <sha...@gm...> wrote:
>
> I tried that. It still treats the device as a file. So first, the disc
> needs to be loaded before starting vblade, and libdvdcss/libaacs can't
> decode encrypted discs. I would assume that remotely ejecting would
> also not work with vblade as the target.



-- 
  Ed Cashin <ec...@no...>
  http://noserose.net/e/
  http://www.coraid.com/

Re: [Aoetools-discuss] ROM target type

[Ben K. <sha...@gm...>]

I tried that. It still treats the device as a file. So first, the disc
needs to be loaded before starting vblade, and libdvdcss/libaacs can't
decode encrypted discs. I would assume that remotely ejecting would
also not work with vblade as the target.

Re: [Aoetools-discuss] ROM target type

[Ed L. C. <ec...@us...>]

There's the "-r" option for vblade.

https://github.com/OpenAoE/vblade/blob/master/aoe.c#L483

I think we put that in for someone doing this.
On Mon, Oct 22, 2018 at 5:56 AM Ben Klein <sha...@gm...> wrote:
>
> Hi all,
>
> I've been looking for a way to run a bunch of DVD-ROM drives over a network/ethernet-connected system. The goal is to have the optical drives "off-board" of my main desktop running in a headless system, and be able to play and archive DVDs and BluRays remotely.
>
> I've looked into AoE, iSCSI, and NBD, and found they are (at least in the opensource world) all designed only for disk-type targets, not for ROM-types.
>
> Is it feasible to implement an AoE target module that would allow exporting CD/DVD/BluRay ROM drives to initiators? I'm not a kernel hacker by any stretch of the imagination.
>
> Thanks,
> Ben Klein
> _______________________________________________
> Aoetools-discuss mailing list
> Aoe...@li...
> https://lists.sourceforge.net/lists/listinfo/aoetools-discuss



-- 
  Ed Cashin <ec...@no...>
  http://noserose.net/e/
  http://www.coraid.com/

[Aoetools-discuss] ROM target type

[Ben K. <sha...@gm...>]

Hi all,

I've been looking for a way to run a bunch of DVD-ROM drives over a
network/ethernet-connected system. The goal is to have the optical drives
"off-board" of my main desktop running in a headless system, and be able to
play and archive DVDs and BluRays remotely.

I've looked into AoE, iSCSI, and NBD, and found they are (at least in the
opensource world) all designed only for disk-type targets, not for
ROM-types.

Is it feasible to implement an AoE target module that would allow exporting
CD/DVD/BluRay ROM drives to initiators? I'm not a kernel hacker by any
stretch of the imagination.

Thanks,
Ben Klein

Re: [Aoetools-discuss] Persisting vblade exports

[Christoph B. <sou...@ma...>]

Christoph Biedl wrote...

> Ed Cashin wrote...
> 
> > Does the OpenAoE vblade master look like it picked up your changes
> > correctly?
> 
> No differences.

... but there's a typo. Please s/vlbade/vblade/ in two of the files.

    Christoph

Re: [Aoetools-discuss] Persisting vblade exports

[Christoph B. <sou...@ma...>]

Ed Cashin wrote...

> Does the OpenAoE vblade master look like it picked up your changes
> correctly?

No differences.

    Christoph

Re: [Aoetools-discuss] Persisting vblade exports

[Ed C. <ec...@no...>]

Does the OpenAoE vblade master look like it picked up your changes
correctly?

On Sat, Sep 1, 2018 at 1:26 PM Ed Cashin <ec...@no...> wrote:

> This looks like good stuff! I’m away from proper computers for a few days.
> Then I’ll give this the attention it deserves.
>
> Thanks.
>
> On Sat, Sep 1, 2018 at 12:41 PM Christoph Biedl <
> sou...@ma...> wrote:
>
>> Ed Cashin wrote...
>>
>> > In the past it has been difficult to say anything specific about startup
>> > that applies to a majority of popular Linux distributions.
>> >
>> > I think we're still in that situation, but perhaps systemd could change
>> it.
>> > I know there are a few distros that do not use systemd, though.
>> >
>> > I don't think you could go wrong in trying to create something helpful.
>>
>> It's been a while, but eventually I created a few things:
>>
>> Please pull from <https://github.com/cbiedl/vblade>,
>> or download from <https://www.in-ulm.de/~cbiedl/vblade-persistence.tar.xz
>> >
>>
>>
>> In the `contrib/persistence/` subdirectory you'll find several files:
>>
>> * vblade-persistence.txt
>>
>>   Documentation in the asciidoc format (I'm too lazy to write *roff).
>>
>> * vblade.service
>> * vblade@.service
>> * vblade-generator
>>
>>   Service files and generator for systemd.
>>
>> * vblade.init.lsb-daemon
>> * vblade.init.daemon
>>
>>   Two different flavours of a SysV init script, see
>>   vblade-persistence(5).
>>
>>   Both are based on daemon(1). I've prepared something that uses
>>   Debian's start-stop-daemon(8) - but this requires pid file support
>>   in vblade and I'm not convinced adding this is worth the efforts.
>>
>> * vblade.init.in
>> * vblade.init.generate
>>
>>   Template and generator for these init scripts.
>>
>>
>> That's some stuff to read, so just the key points:
>>
>> Configuration is in `/etc/vblade.conf.d/`, each export (or "instance")
>> is a file there, name ending in `.conf`.
>>
>> Using lowercase variable names in the configuration is my personal
>> preference, YMMV.
>>
>> By intention I did not implement a mechanism to override settings from
>> a global configuration file. There are some pitfalls in the handling of
>> vblade options and I doubt it's worth to deal with them.
>>
>>
>> The init scripts have been tested to some extent. The systemd variant
>> has been in production for a few days now and seems to be stable.
>> Still, the systemd generator could use a review, I haven't understood
>> all the gory details yet. Controlling the I/O scheduling is an
>> important feature for me but gave me quite a a headache.
>>
>> So before anyone asks,
>>
>>     EnvironmentFile=/etc/vblade.conf.d/%I.conf
>>     ExecStart=/usr/sbin/vblade $shelf $slot $netif $filename $options
>>     IOSchedulingClass=$ioschedulingclass
>>     IOSchedulingPriority=$ioschedulingpriority
>>
>> does *not* what it suggests. Seems definitions from EnvironmentFile
>> do not apply for the IO* directives.
>>
>> Cheers,
>>     Christoph
>> --
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Aoetools-discuss mailing list
>> Aoe...@li...
>> https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
>>
> --
>   Ed Cashin <ec...@no...>
>


-- 
  Ed Cashin <ec...@no...>

Re: [Aoetools-discuss] Persisting vblade exports

[Ed C. <ec...@no...>]

This looks like good stuff! I’m away from proper computers for a few days.
Then I’ll give this the attention it deserves.

Thanks.

On Sat, Sep 1, 2018 at 12:41 PM Christoph Biedl <
sou...@ma...> wrote:

> Ed Cashin wrote...
>
> > In the past it has been difficult to say anything specific about startup
> > that applies to a majority of popular Linux distributions.
> >
> > I think we're still in that situation, but perhaps systemd could change
> it.
> > I know there are a few distros that do not use systemd, though.
> >
> > I don't think you could go wrong in trying to create something helpful.
>
> It's been a while, but eventually I created a few things:
>
> Please pull from <https://github.com/cbiedl/vblade>,
> or download from <https://www.in-ulm.de/~cbiedl/vblade-persistence.tar.xz>
>
>
> In the `contrib/persistence/` subdirectory you'll find several files:
>
> * vblade-persistence.txt
>
>   Documentation in the asciidoc format (I'm too lazy to write *roff).
>
> * vblade.service
> * vblade@.service
> * vblade-generator
>
>   Service files and generator for systemd.
>
> * vblade.init.lsb-daemon
> * vblade.init.daemon
>
>   Two different flavours of a SysV init script, see
>   vblade-persistence(5).
>
>   Both are based on daemon(1). I've prepared something that uses
>   Debian's start-stop-daemon(8) - but this requires pid file support
>   in vblade and I'm not convinced adding this is worth the efforts.
>
> * vblade.init.in
> * vblade.init.generate
>
>   Template and generator for these init scripts.
>
>
> That's some stuff to read, so just the key points:
>
> Configuration is in `/etc/vblade.conf.d/`, each export (or "instance")
> is a file there, name ending in `.conf`.
>
> Using lowercase variable names in the configuration is my personal
> preference, YMMV.
>
> By intention I did not implement a mechanism to override settings from
> a global configuration file. There are some pitfalls in the handling of
> vblade options and I doubt it's worth to deal with them.
>
>
> The init scripts have been tested to some extent. The systemd variant
> has been in production for a few days now and seems to be stable.
> Still, the systemd generator could use a review, I haven't understood
> all the gory details yet. Controlling the I/O scheduling is an
> important feature for me but gave me quite a a headache.
>
> So before anyone asks,
>
>     EnvironmentFile=/etc/vblade.conf.d/%I.conf
>     ExecStart=/usr/sbin/vblade $shelf $slot $netif $filename $options
>     IOSchedulingClass=$ioschedulingclass
>     IOSchedulingPriority=$ioschedulingpriority
>
> does *not* what it suggests. Seems definitions from EnvironmentFile
> do not apply for the IO* directives.
>
> Cheers,
>     Christoph
> --
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Aoetools-discuss mailing list
> Aoe...@li...
> https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
>
-- 
  Ed Cashin <ec...@no...>

Re: [Aoetools-discuss] Persisting vblade exports

[Christoph B. <sou...@ma...>]

Ed Cashin wrote...

> In the past it has been difficult to say anything specific about startup
> that applies to a majority of popular Linux distributions.
>
> I think we're still in that situation, but perhaps systemd could change it.
> I know there are a few distros that do not use systemd, though.
>
> I don't think you could go wrong in trying to create something helpful.

It's been a while, but eventually I created a few things:

Please pull from <https://github.com/cbiedl/vblade>,
or download from <https://www.in-ulm.de/~cbiedl/vblade-persistence.tar.xz>


In the `contrib/persistence/` subdirectory you'll find several files:

* vblade-persistence.txt

  Documentation in the asciidoc format (I'm too lazy to write *roff).

* vblade.service
* vblade@.service
* vblade-generator

  Service files and generator for systemd.

* vblade.init.lsb-daemon
* vblade.init.daemon

  Two different flavours of a SysV init script, see
  vblade-persistence(5).

  Both are based on daemon(1). I've prepared something that uses
  Debian's start-stop-daemon(8) - but this requires pid file support
  in vblade and I'm not convinced adding this is worth the efforts.

* vblade.init.in
* vblade.init.generate

  Template and generator for these init scripts.


That's some stuff to read, so just the key points:

Configuration is in `/etc/vblade.conf.d/`, each export (or "instance")
is a file there, name ending in `.conf`.

Using lowercase variable names in the configuration is my personal
preference, YMMV.

By intention I did not implement a mechanism to override settings from
a global configuration file. There are some pitfalls in the handling of
vblade options and I doubt it's worth to deal with them.


The init scripts have been tested to some extent. The systemd variant
has been in production for a few days now and seems to be stable.
Still, the systemd generator could use a review, I haven't understood
all the gory details yet. Controlling the I/O scheduling is an
important feature for me but gave me quite a a headache.

So before anyone asks,

    EnvironmentFile=/etc/vblade.conf.d/%I.conf
    ExecStart=/usr/sbin/vblade $shelf $slot $netif $filename $options
    IOSchedulingClass=$ioschedulingclass
    IOSchedulingPriority=$ioschedulingpriority

does *not* what it suggests. Seems definitions from EnvironmentFile
do not apply for the IO* directives.

Cheers,
    Christoph
-- 

Re: [Aoetools-discuss] [PATCH] Dealing with a missing interface

[Christoph B. <sou...@ma...>]

Ed Cashin wrote...

> Do you use github?  Would you be willing to open a pull request on
> OpenAoE/vblade?

That took a few days - web interfaces hate me, and it's mutual. But now
you should see <https://github.com/OpenAoE/vblade/pull/11> - let me know
if something went havoc during the procedure.

    Christoph

PS: For those who understand my pain: I found
    https://github.com/sociomantic-tsunami/git-hub
    and it did the things I needed.

[Aoetools-discuss] (no subject)

[Anth H. <atr...@gm...>]

Password reminder

Re: [Aoetools-discuss] OpenVMS AoE initiator

[Ed C. <ed....@ac...>]

On 11/20/2017 06:32 PM, Swift Griggs wrote:
> 
> Is there an OpenVMS AoE initiator ? I'm guessing there isn't. We (folks 
> here at the PARSEC Group) might be interested in writing one. However, 
> right now I'm looking for a good starting point. I took a look at the 
> code in the Linux kernel. I also had a peek at the FreeBSD driver 
> package, which is a bit more self-contained.
> 
> Can anyone recommend a good place to start? Some nice modular 
> initiator-code would be great. We haven't decided on anything yet and we 
> don't know what kind of code-license we'll be using. So, I'm guessing 
> BSD-licensed stuff will be the most welcome.
> 
> Any advice or warnings are welcome.

You might like the initiator in Quanstrom's plan 9 distribution:

   http://www.quanstro.net/plan9/9atom/index.html

... called "devaoe".

I tried to download it just now but couldn't.

If I knew about an OpenVMS AoE initiator, I've forgotten.

The initiator is very simple until you want to have multiple
outstanding AoE commands.  Unfortunately, it's also very slow
without multiple outstanding commands.  If performance isn't a
concern, you could get very simple indeed.

Another performance thing that adds complexity is the avoidance of 
copying by setting up segments for DMA.  Linux has a pretty 
idiosyncratic way of doing that.  I have no idea whether it's better in 
OpenVMS.

-- 
   Ed

[Aoetools-discuss] OpenVMS AoE initiator

[Swift G. <sg...@pa...>]

Is there an OpenVMS AoE initiator ? I'm guessing there isn't. We (folks 
here at the PARSEC Group) might be interested in writing one. However, 
right now I'm looking for a good starting point. I took a look at the code 
in the Linux kernel. I also had a peek at the FreeBSD driver package, 
which is a bit more self-contained.

Can anyone recommend a good place to start? Some nice modular 
initiator-code would be great. We haven't decided on anything yet and we 
don't know what kind of code-license we'll be using. So, I'm guessing 
BSD-licensed stuff will be the most welcome.

Any advice or warnings are welcome.

Thanks,
   Swift
-- 

Swift Griggs <sg...@pa...>
Senior Consultant
The PARSEC Group
999 18th St #1725,
Denver, CO 80202
Direct: (720) 962-9582

Re: [Aoetools-discuss] Persisting vblade exports

[Christoph B. <sou...@ma...>]

Ed Cashin wrote...

> In the past it has been difficult to say anything specific about startup
> that applies to a majority of popular Linux distributions.
>
> I think we're still in that situation, but perhaps systemd could change it.
> I know there are a few distros that do not use systemd, though.
>
> I don't think you could go wrong in trying to create something helpful.

That's encouraging, thanks. I'll probably create something based on
Lars' concept.

    Christoph

Re: [Aoetools-discuss] [PATCH] Dealing with a missing interface

[Christoph B. <sou...@ma...>]

Ed Cashin wrote...

> Do you use github?  Would you be willing to open a pull request on
> OpenAoE/vblade?

Will do, may take a few days.

    Christoph

Re: [Aoetools-discuss] [PATCH] Dealing with a missing interface

[Ed C. <ed....@ac...>]

Hi, Christoph.

Thanks very much for the suggestion and patch.

Do you use github?  Would you be willing to open a pull request on 
OpenAoE/vblade?

(I tried replying earlier with my cell phone but failed. Sorry for the 
delay.)

-- 
   Ed
On 11/10/2017 12:58 PM, Christoph Biedl wrote:
> Hello,
> 
> at the moment, vblade handles an unknown or missing interface
> to bind to not that well (seen on Linux):
> 
> # /usr/sbin/vblade 12 3 ens4 /home/root/vblade.img
> | bind funky: No such device
> | Can't get hw addr: Bad file descriptor
> | pid 1664: e12.3, 131072 sectors O_RDWR
> | Can't get mtu: Bad file descriptor
> | putpkt aoe id: Bad file descriptor
> | read network: Bad file descriptor
> 
> Two problems here:
> 
> * (linux only) In dial, the getindx result is not checked. The following
>    bind call however fails for an invalid interface index. But "bind funky"
>    isn't quite a helpful error message.
> 
> * The main routine does not check the dial result.
> 
> Patches for both are fairly simple. The freebsd counterpart for the
> first one is missing, though. I don't want to fiddle with code I don't
> fully understand, and cannot test either.
> 
> Output then:
> | ens4: No such device
> 
> ... which I call an improvement.
> 
>      Christoph
> 
> --- a/aoe.c
> +++ b/aoe.c
> @@ -536,6 +536,8 @@
>   	}
>   	ifname = argv[2];
>   	sfd = dial(ifname, bufcnt);
> +	if (sfd < 0)
> +		return 1;
>   	getea(sfd, ifname, mac);
>   	printf("pid %ld: e%d.%d, %lld sectors %s\n",
>   		(long) getpid(), shelf, slot, size,
> --- a/linux.c
> +++ b/linux.c
> @@ -47,6 +47,10 @@
>   		return -1;
>   	}
>   	i = getindx(s, eth);
> +	if (i < 0) {
> +		perror(eth);
> +		return -1;
> +	}
>   	sa.sll_family = AF_PACKET;
>   	sa.sll_protocol = htons(0x88a2);
>   	sa.sll_ifindex = i;
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Aoetools-discuss mailing list
> Aoe...@li...
> https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
> 

Re: [Aoetools-discuss] Persisting vblade exports

[Ed C. <ed....@ac...>]

Hi, Christoph.

In the past it has been difficult to say anything specific about startup 
that applies to a majority of popular Linux distributions.

I think we're still in that situation, but perhaps systemd could change 
it.  I know there are a few distros that do not use systemd, though.

I don't think you could go wrong in trying to create something helpful.

On 11/10/2017 01:30 PM, Christoph Biedl wrote:
> Hello,
> 
> for all the years I've been wondering how people persist their vblade
> instances, i.e. have some exports that are automatically started at
> bootup. Some hand-crafted shell scripts that call vbladed?
> 
> In the Debian project, there is a vblade-persist package which uses
> runit, and the maintainer/upstream (Cc:'d) has expressed his
> consideration of either giving it into other hands for major rework, or
> just removing (RM) it entirely.[1]
> 
> Now I am thinking about going the rework way: Create a simple
> configuration file format[2] for persistent vblade exports, and add
> support for at least systemd (via generators) and sysv (probably using
> the daemon[3] program as a supervisor).
> 
> Before re-inventing the wheel: Did I miss anything similar out there?
> Is this something for the vblade package? I could do this within
> Debian, but avoiding distribution-specific extensions was a plus.
> 
>      Christoph
> 
> [1] https://bugs.debian.org/862873
> 
> [2] Basically a POSIX shell fragment key/value store for
>      netif, shelf, slot, source, opts, mac, and ionice.
> 
> [3] http://www.libslack.org/daemon/
> 

Re: [Aoetools-discuss] Persisting vblade exports

[Lars T. <ta...@bb...>]

Hi,

for those who are interested, here our systemd solution:

global config /etc/vblade.conf:
===============================
# example configuration file

# global variables
BUFFER_COUNT=16
===============================



local config for each target, e.g.:
/etc/vblade.conf.d/e02.08.conf
===============================
SHELF=2
SLOT=8
NETIF=bond-aoe
FILE=/dev/DRBD/KVM_ABC-DEF
MACS=XX:YY:ZZ:__:a5:85,XX:YY:ZZ:__:af:86,XX:YY:ZZ:__:21:40,XX:YY:ZZ:__:20:f0
===============================



systemd template file:
/lib/systemd/system/vblade@.service
===============================
# vblade target service
#
# 2017-01-26 Lars Täuber ta...@bb... - initial version ported from upstart script

[Unit]
Description=vblade AoE target for %I
Requires=drbd.service
ConditionPathExists=/etc/vblade.conf
ConditionFileNotEmpty=/etc/vblade.conf.d/%I.conf
StartLimitInterval=2min
StartLimitBurst=19


[Service]
RestartSec=3
Restart=always
#Restart=on-failure
ExecStart=/bin/bash -c '								\
    . /etc/vblade.conf;									\
											\
    SHELF="%I";										\
     SLOT="${SHELF##*.}";								\
    SHELF="${SHELF%%.*}";								\
    SHELF="${SHELF#e}";									\
											\
    . /etc/vblade.conf.d/%I.conf;							\
											\
    MACS="$${MACS:+-m $$MACS}";								\
    BUFFER_COUNT="$${BUFFER_COUNT:+-b $$BUFFER_COUNT}";					\
											\
    exec vblade $$BUFFER_COUNT $$MACS $$(($$SHELF+0)) $$(($$SLOT +0)) $$NETIF $$FILE	\
'

[Install]
WantedBy=multi-user.target
===============================



to start a single target:
systemctl start vblade@e02.08

get status
systemctl status vblade@e02.08


stop *all* targets:
systemctl stop vblade@*



Hope this helps
Lars



Fri, 10 Nov 2017 19:30:14 +0100
Christoph Biedl <sou...@ma...> ==> aoe...@li... :
> Hello,
> 
> for all the years I've been wondering how people persist their vblade
> instances, i.e. have some exports that are automatically started at
> bootup. Some hand-crafted shell scripts that call vbladed?
> 
> In the Debian project, there is a vblade-persist package which uses
> runit, and the maintainer/upstream (Cc:'d) has expressed his
> consideration of either giving it into other hands for major rework, or
> just removing (RM) it entirely.[1]
> 
> Now I am thinking about going the rework way: Create a simple
> configuration file format[2] for persistent vblade exports, and add
> support for at least systemd (via generators) and sysv (probably using
> the daemon[3] program as a supervisor).
> 
> Before re-inventing the wheel: Did I miss anything similar out there?
> Is this something for the vblade package? I could do this within
> Debian, but avoiding distribution-specific extensions was a plus.
> 
>     Christoph
> 
> [1] https://bugs.debian.org/862873
> 
> [2] Basically a POSIX shell fragment key/value store for
>     netif, shelf, slot, source, opts, mac, and ionice.
> 
> [3] http://www.libslack.org/daemon/


-- 
                            Informationstechnologie
Berlin-Brandenburgische Akademie der Wissenschaften
Jägerstraße 22-23                      10117 Berlin
Tel.: +49 30 20370-352           http://www.bbaw.de

[Aoetools-discuss] Persisting vblade exports

[Christoph B. <sou...@ma...>]

Hello,

for all the years I've been wondering how people persist their vblade
instances, i.e. have some exports that are automatically started at
bootup. Some hand-crafted shell scripts that call vbladed?

In the Debian project, there is a vblade-persist package which uses
runit, and the maintainer/upstream (Cc:'d) has expressed his
consideration of either giving it into other hands for major rework, or
just removing (RM) it entirely.[1]

Now I am thinking about going the rework way: Create a simple
configuration file format[2] for persistent vblade exports, and add
support for at least systemd (via generators) and sysv (probably using
the daemon[3] program as a supervisor).

Before re-inventing the wheel: Did I miss anything similar out there?
Is this something for the vblade package? I could do this within
Debian, but avoiding distribution-specific extensions was a plus.

    Christoph

[1] https://bugs.debian.org/862873

[2] Basically a POSIX shell fragment key/value store for
    netif, shelf, slot, source, opts, mac, and ionice.

[3] http://www.libslack.org/daemon/
-- 

[Aoetools-discuss] [PATCH] Dealing with a missing interface

[Christoph B. <sou...@ma...>]

Hello,

at the moment, vblade handles an unknown or missing interface
to bind to not that well (seen on Linux):

# /usr/sbin/vblade 12 3 ens4 /home/root/vblade.img
| bind funky: No such device
| Can't get hw addr: Bad file descriptor
| pid 1664: e12.3, 131072 sectors O_RDWR
| Can't get mtu: Bad file descriptor
| putpkt aoe id: Bad file descriptor
| read network: Bad file descriptor

Two problems here:

* (linux only) In dial, the getindx result is not checked. The following
  bind call however fails for an invalid interface index. But "bind funky"
  isn't quite a helpful error message.

* The main routine does not check the dial result.

Patches for both are fairly simple. The freebsd counterpart for the
first one is missing, though. I don't want to fiddle with code I don't
fully understand, and cannot test either.

Output then:
| ens4: No such device

... which I call an improvement.

    Christoph

--- a/aoe.c
+++ b/aoe.c
@@ -536,6 +536,8 @@
 	}
 	ifname = argv[2];
 	sfd = dial(ifname, bufcnt);
+	if (sfd < 0)
+		return 1;
 	getea(sfd, ifname, mac);
 	printf("pid %ld: e%d.%d, %lld sectors %s\n",
 		(long) getpid(), shelf, slot, size,
--- a/linux.c
+++ b/linux.c
@@ -47,6 +47,10 @@
 		return -1;
 	}
 	i = getindx(s, eth);
+	if (i < 0) {
+		perror(eth);
+		return -1;
+	}
 	sa.sll_family = AF_PACKET;
 	sa.sll_protocol = htons(0x88a2);
 	sa.sll_ifindex = i;

Re: [Aoetools-discuss] Query on AoE initiator accessing target started locally over lo

[Ed C. <ed....@ac...>]

Hi.  I have some comments between quotes below.

On 08/24/2017 01:18 AM, Nivin Lawrence wrote:
...
> The system can be considered as one with dual CPU complex, but a single 
> SSD. There are 2 operating systems, OS-1 and OS-2 running on each of the 
> CPU complex, OS-1 boots first and takes control of the SSD and starts 
> the target. OS-2 which boots up later uses initiator to connect to 
> target over an interface connecting the 2 CPU complex. There is no 
> switch in between, its a back to back Ethernet network over which AoE is 
> being used by OS-2 for all disk accesses.
> 
> Now, at some point in time, OS-1 has to be shut down, which means target 
> is not available anymore. OS-2 will now start the target on loopback 
> interface using "vbladed 0 0  lo /dev/sda".

In general, when you have two different hosts using a shared read-write 
resource like this, you have to prevent a split-brain situation by using 
fencing.  I think that if you're sure that OS-1 only ever uses the SSD 
at the request of OS-2 and you have fully shut down the whole path from 
the user on OS-2 through the storage layers on OS-1 before OS-2 begins 
using the SSD directly, it's OK, but you'd have to use two-phase commit 
or something to be sure it's always going to be 100% safe.  (Otherwise 
you run the risk of one of them booting during a communication failure 
and using the SSD inappropriately while the other is using it.)

More below.

> As this system is going to 
> run for a long time, i want to understand the overhead that is there in 
> disk access from the POV of applications running on OS-2. I want to 
> compare the AoE based access mechanism in the above scenario with the 
> case where OS-2 applications are directly accessing the SSD.
> 
> Now, all the queries below are for this case where OS-2 has the 
> initiator which tries to connect to the target which is also running in 
> OS-2, no network in between. Not sure if your previous responses would 
> still be valid for this specific case as for example MTU might not be a 
> consideration from the actual data transfer POV.
> 
>     a.__Wanted to understand if the AoE model has specific optimizations
>     done to make this as close as possible to a regular local disk access.

There are a lot of decisions that were made with performance in mind, 
but the loopback-only network scenario was not ever the primary concern 
as a deployment environment.  You should try it and see, though. 
Performance is always best measured and analyzed.  Sometimes there will 
be one or two bottlenecks that are easy to identify and eliminate.

The Linux kernel already has optimizations for loopback networking.

I think you might do more optimizations for your situation if you think 
carefully about I/O operations, their sizes and offsets.  You'll find 
some discussions of that periodically here in the list archives.

-- 
   Ed

Re: [Aoetools-discuss] Query on AoE initiator accessing target started locally over lo

[Nivin L. <niv...@gm...>]

Hi Ed,
   Thanks for the response. Below are the details which explains the
scenario better.

The system can be considered as one with dual CPU complex, but a single
SSD. There are 2 operating systems, OS-1 and OS-2 running on each of the
CPU complex, OS-1 boots first and takes control of the SSD and starts the
target. OS-2 which boots up later uses initiator to connect to target over
an interface connecting the 2 CPU complex. There is no switch in between,
its a back to back Ethernet network over which AoE is being used by OS-2
for all disk accesses.

Now, at some point in time, OS-1 has to be shut down, which means target is
not available anymore. OS-2 will now start the target on loopback interface
using "vbladed 0 0  lo /dev/sda". As this system is going to run for a long
time, i want to understand the overhead that is there in disk access from
the POV of applications running on OS-2. I want to compare the AoE based
access mechanism in the above scenario with the case where OS-2
applications are directly accessing the SSD.

Now, all the queries below are for this case where OS-2 has the initiator
which tries to connect to the target which is also running in OS-2, no
network in between. Not sure if your previous responses would still be
valid for this specific case as for example MTU might not be a
consideration from the actual data transfer POV.

a.       Wanted to understand if the AoE model has specific optimizations
done to make this as close as possible to a regular local disk access.
b.      I see the Linux storage stack @ https://upload.wikimedia.
org/wikipedia/commons/3/30/IO_stack_of_the_Linux_kernel.svg <http://%2522/>,
I was wondering about the overhead involved in accessing storage from
application POV once I restart the AoE target locally.
                                                              i.      Overhead
from the perspective of additional LOC involved as compared to a local disk
access
                                                            ii.      Overhead
from the perspective of throughput possible as compared to a local disk
access
c.       Do you think further optimizations are theoretically possible to
take care of this specific scenario to make it just like a regular local
disk access?


Thankyou,
nivin