[lustre-discuss] Lustre Client in a container

[David Cohen]

Thanks for all the answers.
I was thinking of creating a new file system, starting from clean
configuration, implementing quotas etc.
For that I was looking for a way in which the systems can coexist, moving
symbolic links while the folders are synchronized to the new system.
In the process emptying disks of the old file system and moving them to the
new one.
This is a long process that might take more then a month, but can be done
without disturbing normal cluster operation.

As it doesn't seems to be possible in real life, I will have to reevaluate
my options and come with a different migration schema.




On Wed, Jan 3, 2018 at 1:49 PM, Patrick Farrell <paf at cray.com> wrote:

> FWIW, as long as you don’t intend to use any interesting features (quotas,
> etc), 1.8 clients were used with 2.5 servers at ORNL for some time with no
> ill effects on the IO side of things.
>
> I’m not sure how much further that limited compatibility goes, though.
> ------------------------------
> *From:* Dilger, Andreas <andreas.dilger at intel.com>
> *Sent:* Wednesday, January 3, 2018 4:20:56 AM
> *To:* David Cohen
> *Cc:* Patrick Farrell; lustre-discuss at lists.lustre.org
> *Subject:* Re: [lustre-discuss] Lustre Client in a container
>
> On Dec 31, 2017, at 01:50, David Cohen <cdavid at physics.technion.ac.il>
> wrote:
> >
> > Patrick,
> > Thanks for you response.
> > I looking for a way to migrate from 1.8.9 system to 2.10.2, stable
> enough to run the several weeks or more that it might take.
>
> Note that there is no longer direct support for upgrading from 1.8 to
> 2.10.
>
> That said, are you upgrading the filesystem in place, or are you copying
> the data from the 1.8.9 filesystem to the 2.10.2 filesystem?  In the latter
> case, the upgrade compatibility doesn't really matter.  What you need is a
> client that can mount both server versions at the same time.
>
> Unfortunately, no 2.x clients can mount the 1.8.x server filesystem
> directly, so that does limit your options.  There was a time of
> interoperability with 1.8 clients being able to mount 2.1-ish servers, but
> that doesn't really help you.  You could upgrade the 1.8 servers to 2.1 or
> later, and then mount both filesystems with a 2.5-ish client, or upgrade
> the servers to 2.5.
>
> Cheers, Andreas
>
> > On Sun, Dec 31, 2017 at 12:12 AM, Patrick Farrell <paf at cray.com> wrote:
> > David,
> >
> > I have no direct experience trying this, but I would imagine not -
> Lustre is a kernel module (actually a set of kernel modules), so unless the
> container tech you're using allows loading multiple different versions of
> *kernel modules*, this is likely impossible.  My limited understanding of
> container tech on Linux suggests that this would be impossible, containers
> allow userspace separation but there is only one kernel/set of
> modules/drivers.
> >
> > I don't know of any way to run multiple client versions on the same node.
> >
> > The other question is *why* do you want to run multiple client versions
> on one node...?  Clients are usually interoperable across a pretty generous
> set of server versions.
> >
> > - Patrick
> >
> >
> > From: lustre-discuss <lustre-discuss-bounces at lists.lustre.org> on
> behalf of David Cohen <cdavid at physics.technion.ac.il>
> > Sent: Saturday, December 30, 2017 11:45:15 AM
> > To: lustre-discuss at lists.lustre.org
> > Subject: [lustre-discuss] Lustre Client in a container
> >
> > Hi,
> > Is it possible to run Lustre client in a container?
> > The goal is to run two different client version on the same node, can it
> be done?
> >
> > David
> >
> >
> > _______________________________________________
> > lustre-discuss mailing list
> > lustre-discuss at lists.lustre.org
> > http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>
> Cheers, Andreas
> --
> Andreas Dilger
> Lustre Principal Architect
> Intel Corporation
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20180103/82373814/attachment-0001.html>