Thanks Phil. I've committed a fix for this along with some other
minor changes over the course of the day. The biggest change was to
allow endpoints to be separated by comma instead of a semi-colon, for
users that don't quote the spec string. Let me know if you hit any
other problems.
-sam
On Jun 1, 2006, at 5:16 AM, Phil Carns wrote:
Thanks for getting this stuff committed and cleaned up!
I think a new bug may have been introduced along the way, however.
It looks like the server config files "HostID" field is being set
to the alias name rather than the fully qualified BMI address. For
example, if you do a build and check the src/server/server.conf-
localhost file, it has the HostID set to "localhost" rather than
"tcp://localhost:3334". This causes an error when you try to create
the file system.
Otherwise, the changes look good as far as I can tell so far.
-Phil
Sam Lang wrote:
On May 31, 2006, at 9:47 PM, Sam Lang wrote:
I went ahead and committed the --metaspec and --iospec options
to pvfs2-genconfig. The changes aren't based on your patch Bart,
Errr...that was meant to say ARE based on Bart's patch...
but I did a lot of cleanup and ended up changing the code fairly
significantly. The options themselves allow the endpoints to be
specified as follows:
[<proto>://]<host>:<port>[:<storage>][:<logfile>]
You can specify multiple endpoints separated by semicolons.
Also, you can specify port ranges, i.e. for <port> you might
have {1-4,8-12,16-20}. If the protocol isn't specified, tcp is
used. If the storage or logfile aren't specified, filename (or
path) is requested interactively, and modified for each endpoint
by adding a unique suffix: -<host>_<proto><port>. For example, /
psto- hosta_tcp3334 and /plog-hosta_tcp3334.
Also, if you want to be able to specify multiple protocols for
the same endpoint, you can do that by combining them between
square brackets:
[endpoint1,endpoint2,endpoint3,...]
So you can have "[tcp://hosta:3334,gm://hosta:6]:/psto:/tmp/plog"
I think these changes will allow reasonable backward
compatibility for the --ioports and --metaports options we have
now, as well as covering pretty much all the use cases you guys
have. Let me know if you have any problems/concerns.
-sam
On May 18, 2006, at 11:26 AM, Phil Carns wrote:
Robert Latham wrote:
On Thu, Apr 06, 2006 at 02:40:01PM -0600, Bart Taylor wrote:
As an example, suppose that you are using a SAN and you want
one particular
server to have a dedicated LUN for metadata. In that case
you might want to
specify something like this:
--iospecs host1:3335:/mnt/data-lun,host2:3335:/mnt/data-lun
--metaspces host1:3334:/mnt/meta-lun
It sounds like what you want, more than iospecs and metaspecs,
is a
way to specify separate storage spaces for metadata and data.
==rob
I just ran across this email when looking for a reference to
the pvfs2-ping patch, but I thought I would add my 2c.
I think for the range of cases that Bart was addressing it
isn't necessarily as simple as choosing different storage for
meta vs. I/ O (although that would work for this example).
Having more flexibility in terms of the exact server
specification can be helpful for unusual server environments,
like:
- multiple servers per node on some machines (to access
multiple LUNs on systems with LUN size limitations)
- tuning subsets of servers for specific purposes (maybe some
have different RAM or other hardware footprints)
- temporarily doubling up servers on just one of the machines,
so that you can take a different one off line for maintenance
(mainly useful if you have network attached storage that other
servers could reach)
We haven't necessarily seen all of these configurations, but it
would be nice to be able to handle all of those cases with the
same command line interface.
There may be a cleaner way to represent all of this in general,
but this patch was also trying not to break existing arguments
to genconfig.
-Phil
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-
developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
