|
Home > Archive > Debian Developers > December 2006 > block device served over network connections
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
block device served over network connections
|
|
| Warren Turkal 2006-12-18, 7:23 am |
| DDs,
I am looking for some info on this subject. I have looked at both the aoetools
and open-iscsi for a solution to the following problem.
I have a block device that is served over aoe. Basically, I would like to take
two of these devices (e0.0 and e1.0) and create a raid1 with software RAID.
However, I am not really sure how to solve this one. I am emailing here
because I think the infrastructure to do such a thing may not exist in
Debian.
The basic problem is the network devices that receive info related to the
block device must be up early enough that the mdadm discovery has not
happened. It would be fairly easy to right a script that simply
does "ifconfig eth0 up" and performs discovery (additionally
disabling /etc/rcS.d/S41aoetools and essentially doing my own thing), but I
would like to know if there is official Debian infrastructure for this sort
of thing.
Are there any other packages I should be looking at to make this happen?
If not, maybe this is something that should be considered by some people who
care as network based block storage is getting more common. With NBD, AOE,
and ISCSI (and others I am sure), I don't think that each package should
implement their own way of dealing with this problem, and I hope some kind of
normalized way of dealing with this problem can be made available, if it is
not already available.
Thanks,
wt
--
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nikita V. Youshchenko 2006-12-18, 1:21 pm |
| > Are there any other packages I should be looking at to make this happen?
>
> If not, maybe this is something that should be considered by some people
> who care as network based block storage is getting more common. With NBD,
> AOE, and ISCSI (and others I am sure), I don't think that each package
> should implement their own way of dealing with this problem, and I hope
> some kind of normalized way of dealing with this problem can be made
> available, if it is not already available.
Looks like a word for using ubuntu's upstart instead of sysvinit ?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2006-12-20, 7:25 am |
| On Mon, Dec 18, 2006 at 02:26:14AM -0700, Warren Turkal wrote:
> DDs,
>
> I am looking for some info on this subject. I have looked at both the aoetools
> and open-iscsi for a solution to the following problem.
>
> I have a block device that is served over aoe. Basically, I would like to take
> two of these devices (e0.0 and e1.0) and create a raid1 with software RAID.
> However, I am not really sure how to solve this one. I am emailing here
> because I think the infrastructure to do such a thing may not exist in
> Debian.
>
> The basic problem is the network devices that receive info related to the
> block device must be up early enough that the mdadm discovery has not
> happened. It would be fairly easy to right a script that simply
> does "ifconfig eth0 up" and performs discovery (additionally
> disabling /etc/rcS.d/S41aoetools and essentially doing my own thing), but I
> would like to know if there is official Debian infrastructure for this sort
> of thing.
Just rearrange the initscripts so that mdadm is ran _after_ aoetools.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Warren Turkal 2006-12-20, 7:22 pm |
| On Wednesday 20 December 2006 02:59, Wouter Verhelst wrote:
> Just rearrange the initscripts so that mdadm is ran _after_ aoetools.
If it were only that easy, I would do that. However, there is much more to it.
For instance, the mdadm and lvm and evms run in the initramfs. Also the
ethernet card receiving the AOE data needs to be up to talk to the devices,
and thus needs to be up. An IP is not neccesarily needed for AOE (think "ip
link set eth1 up") unlike ISCSI. I wish there were a way to make the aoetools
script work, but it is fundamentally broken. I would like to work with the
maintainer, but he has been pretty unresponsive to this use case.
I have now added the scripts to make it work from initramfs and to make sure
the network is up during shutdown at the right time to let the lvm subsystem
properly shut down. I also disabled the aoetools scripts. I have posted the
required scripts at [1]. Granted, they are a total hack, but they work. I
wish someone smarter than me about this stuff would take a look. As one
improvement, I could probably use the /etc/default/aoetools in the initramfs
script.
wt
[1]http://penguintechs.org/debian/aoe_stuff/aoe-block.tar
--
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ron Johnson 2006-12-20, 7:22 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/20/06 18:16, Warren Turkal wrote:
> On Wednesday 20 December 2006 02:59, Wouter Verhelst wrote:
>
> If it were only that easy, I would do that. However, there is much more to it.
> For instance, the mdadm and lvm and evms run in the initramfs. Also the
> ethernet card receiving the AOE data needs to be up to talk to the devices,
> and thus needs to be up. An IP is not neccesarily needed for AOE (think "ip
> link set eth1 up") unlike ISCSI. I wish there were a way to make the aoetools
> script work, but it is fundamentally broken. I would like to work with the
> maintainer, but he has been pretty unresponsive to this use case.
Roll a custom kernel that either statically links the modules, or
loads them in your preferred order?
> I have now added the scripts to make it work from initramfs and to make sure
> the network is up during shutdown at the right time to let the lvm subsystem
> properly shut down. I also disabled the aoetools scripts. I have posted the
> required scripts at [1]. Granted, they are a total hack, but they work. I
> wish someone smarter than me about this stuff would take a look. As one
> improvement, I could probably use the /etc/default/aoetools in the initramfs
> script.
>
> wt
>
> [1]http://penguintechs.org/debian/aoe_stuff/aoe-block.tar
- --
Ron Johnson, Jr.
Jefferson LA USA
Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFidVzS9HxQb37XmcRAh1oAJ9kzSvFqATG
PdJa8ZFGpCujzVxQPwCgz88s
mZRvGSwuBrywRXcdrryxx6U=
=dNzb
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Warren Turkal 2006-12-21, 7:32 am |
| On Wednesday 20 December 2006 17:29, Ron Johnson wrote:
> Roll a custom kernel that either statically links the modules, or
> loads them in your preferred order?
I don't see how this helps me bring up the network at the right time. I guess
you are suggesting this in addition to shuffling around init scripts.
I have a working solution that doesn't require building modules statically
into the kernel. I would like to see a mechanism to support this type of use
case (network hosted block level storage) in a more generic way so that I
(and others) don't have to reinvent the wheel when doing this. If that wheel
has not been invented, I would like to help do so.
wt
--
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|