The first column in ldev.conf should match the output of 'uname -n'.
If that fails, 'sh -x /etc/init.d/lustre start' is a good way to trace the
startup
process to see where it's going off the rails.
Ned
> -Original Message-
> From: lustre-discuss [mailto:lustre-discuss-boun...@lists.lus
Yep. They are listed in ldev.conf:
10.1.1.1 - mgs zfs:lustre-mgs/mgs
10.1.1.1 - mdt0zfs:lustre-mdt0/mdt0
10.1.1.1 - ost0zfs:lustre-ost0/ost0
I haven't changed any options in /etc/sysconfig/lustre at all. Didn't
see any that might be the source of the issue.
Brian An
On Apr 28, 2017, at 12:23, Brian Andrus wrote:
>
> All,
>
> I just did a new build against the latest (2.9.56_36) source.
>
> I am building with zfs support and kmod. Packages build fine and install fine.
>
> Lnet comes up and I can 'lctl ping' self and a client. Both show up as peers
> after
All,
I just did a new build against the latest (2.9.56_36) source.
I am building with zfs support and kmod. Packages build fine and install
fine.
Lnet comes up and I can 'lctl ping' self and a client. Both show up as
peers afterwards.
I am following: http://wiki.lustre.org/Lustre_with_ZFS_
Hi,
I have not specifically measured the performance impact of getting the Kerberos
ticket before any Lustre request can be sent by the client. It happens at the
first connection (so when mounting) and then when the ticket expires. Otherwise
the ticket is cached.
So unless the ticket has a very
