aoetools-discuss Mailing List for ATA over Ethernet Tools
Brought to you by:
ecashin,
elcapitansam
You can subscribe to this list here.
2005 |
Jan
|
Feb
(3) |
Mar
(14) |
Apr
(24) |
May
|
Jun
(8) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(16) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(21) |
Feb
(7) |
Mar
(6) |
Apr
(10) |
May
(16) |
Jun
(17) |
Jul
(28) |
Aug
(50) |
Sep
(72) |
Oct
(44) |
Nov
(41) |
Dec
(33) |
2007 |
Jan
(10) |
Feb
(35) |
Mar
(29) |
Apr
(17) |
May
(5) |
Jun
(9) |
Jul
(12) |
Aug
(23) |
Sep
(27) |
Oct
(7) |
Nov
(15) |
Dec
(2) |
2008 |
Jan
(12) |
Feb
(25) |
Mar
(31) |
Apr
(30) |
May
(21) |
Jun
(16) |
Jul
(24) |
Aug
(2) |
Sep
(26) |
Oct
(15) |
Nov
(4) |
Dec
(12) |
2009 |
Jan
(7) |
Feb
(34) |
Mar
(38) |
Apr
(41) |
May
(37) |
Jun
|
Jul
(16) |
Aug
(7) |
Sep
(10) |
Oct
(15) |
Nov
(22) |
Dec
(7) |
2010 |
Jan
(9) |
Feb
(1) |
Mar
(3) |
Apr
(15) |
May
(23) |
Jun
(9) |
Jul
(1) |
Aug
(4) |
Sep
(2) |
Oct
(14) |
Nov
(9) |
Dec
(3) |
2011 |
Jan
|
Feb
(8) |
Mar
(6) |
Apr
(5) |
May
(10) |
Jun
(6) |
Jul
(48) |
Aug
(8) |
Sep
(15) |
Oct
|
Nov
(6) |
Dec
(6) |
2012 |
Jan
(1) |
Feb
(2) |
Mar
(12) |
Apr
(27) |
May
(15) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
(6) |
Dec
|
2013 |
Jan
(2) |
Feb
(1) |
Mar
(11) |
Apr
(12) |
May
(8) |
Jun
(1) |
Jul
(3) |
Aug
|
Sep
(10) |
Oct
(17) |
Nov
|
Dec
|
2014 |
Jan
(6) |
Feb
|
Mar
(6) |
Apr
(1) |
May
(39) |
Jun
(20) |
Jul
(10) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
2015 |
Jan
|
Feb
(8) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(16) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(3) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
|
Dec
(9) |
2017 |
Jan
(4) |
Feb
|
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(9) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(5) |
Oct
(5) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Christoph B. <sou...@ma...> - 2020-04-19 21:37:24
|
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 |
From: Eriel P. <eri...@gm...> - 2019-03-13 20:47:51
|
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. |
From: Ben K. <sha...@gm...> - 2018-10-29 07:28:00
|
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/ |
From: Ed L. C. <ec...@us...> - 2018-10-23 23:03:26
|
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/ |
From: Ben K. <sha...@gm...> - 2018-10-23 13:29:42
|
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. |
From: Ed L. C. <ec...@us...> - 2018-10-23 13:19:40
|
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/ |
From: Ben K. <sha...@gm...> - 2018-10-22 09:55:52
|
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 |
From: Christoph B. <sou...@ma...> - 2018-09-13 11:24:42
|
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 |
From: Christoph B. <sou...@ma...> - 2018-09-12 17:15:08
|
Ed Cashin wrote... > Does the OpenAoE vblade master look like it picked up your changes > correctly? No differences. Christoph |
From: Ed C. <ec...@no...> - 2018-09-12 11:53:15
|
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...> |
From: Ed C. <ec...@no...> - 2018-09-01 17:26:37
|
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...> |
From: Christoph B. <sou...@ma...> - 2018-09-01 16:40:59
|
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 -- |
From: Christoph B. <sou...@ma...> - 2018-08-26 13:46:59
|
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. |
From: Anth H. <atr...@gm...> - 2018-06-27 01:46:23
|
Password reminder |
From: Ed C. <ed....@ac...> - 2017-11-21 02:08:20
|
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 |
From: Swift G. <sg...@pa...> - 2017-11-21 00:17:26
|
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 |
From: Christoph B. <sou...@ma...> - 2017-11-20 20:38:43
|
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 |
From: Christoph B. <sou...@ma...> - 2017-11-20 20:37:15
|
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 |
From: Ed C. <ed....@ac...> - 2017-11-20 02:21:48
|
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 > |
From: Ed C. <ed....@ac...> - 2017-11-20 02:21:42
|
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/ > |
From: Lars T. <ta...@bb...> - 2017-11-13 10:13:38
|
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 |
From: Christoph B. <sou...@ma...> - 2017-11-10 18:30:23
|
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/ -- |
From: Christoph B. <sou...@ma...> - 2017-11-10 18:17:50
|
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; |
From: Ed C. <ed....@ac...> - 2017-08-28 01:31:10
|
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 |
From: Nivin L. <niv...@gm...> - 2017-08-24 05:18:54
|
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 |