[lustre-discuss] Robinhood User Group: agenda is online

[LEIBOVICI Thomas]

Robinhood User Group agenda is now online:
http://github.com/cea-hpc/robinhood/wiki/RUG2015#agenda

There is only a handful of seats still available.
Make sure to register if you want to attend the meeting:
http://rug2015.wufoo.com/forms/robinhood-user-group-registration-form

There is still room for 1 presentation, if you wish to share your 
experience about:

- specific usages and implementations, site status
- performance and tunings (robinhood, database, kernel, filesystem...)
- integration to site monitoring and accounting systems
- contributions and annex tools
- vendors integration
- expectations for future versions
To propose a topic, or for any other question about RUG, contact: 
robinhood-user-gr...@lists.sf.net 


See you soon!

Robinhood User Group
September 21st, 2015 (afternoon)**
Marriott Hotel Champs-Elysees
Paris, France*
*
http://github.com/cea-hpc/robinhood/wiki/RUG2015*
*
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] refresh file layout error

[Martin Hecht]

On 09/03/2015 07:22 AM, E.S. Rosenberg wrote:
> On Wed, Sep 2, 2015 at 8:47 PM, Wahl, Edward  wrote:
>
>> That would be my guess here.  Any chance this is across NFS?  Seen that a
>> great deal with this error, it used to cause crashes.
>>
> Strictly speaking it is not, but it may be because a part of the path the
> server 'sees'/'knows' is a symlink to the lustre filesystem which lives on
> nfs...
>
Ah, I can remember a problem we had some years ago, when users with
their $HOME on NFS were accessing many files in directories on lustre
via symlink. Somehow the NAS box serving the nfs file system didn't
immediately notice that the files weren't on its own file system and
repeatedly had to look up in its cache, just to notice that the files
are somewhere else behind a symlink. If I recall correctly, the problem
could be avoided by:
- Either access the file via absolute path, or cd into the directory
(both via mount point, not (!) via symlink)
- Or make the symlink an absolute one (I'm not 100% sure, but I believe
the problem was only with relative links pointing out of the NFS upwards
across the mountpoint and down again into the lustre file system).
It could be something similar here. Do you have any chance to access the
files via absolute path in your setup and web server configuration?

best regards, Martin




smime.p7s
Description: S/MIME Cryptographic Signature
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] Convert a disk from lustre to ext4

[Martin Hecht]

Maybe, it's anyhow too late, but I have found this thread in my unread mail:

On 09/01/2015 06:38 PM, Colin Faber wrote:
> If you're just looking to reformat the drive, then just reformat the drive:
>
> http://linux.die.net/man/8/mkfs.ext4
It's still unclear what he actually did. Maybe he formatted as ldiskfs
and used the disk as if it were ext4?
Then, it might even be mountable as ext4, at least if the e2fstools are
installed.
Anyhow, I would recommend to backup the data (if there is anything
useful on the device already) on a different device, then  reformat the
drive and restore the files on it.

and from an earlier mail on this topic:

On 08/24/2015 08:07 PM, E.S. Rosenberg wrote:
> What's wrong with plain ext4?
> Or XFS, btrfs etc.
>
> If you want good support on Windows you're stuck with windows filesystems
> ((ex)FAT, NTFS), though there are tools to mount extX filesystems on
> windows they aren't all that stable as far as I know (though I haven't
> looked at that for years so things may have changed).
maybe using a NAS box which exports a file system via NFS and SMB is
what you are looking for. It's connected via ethernet, however and
Windwos can mount it as so-called Network Drive. Linux and MAC support
both, NFS and SMB more or less, depending on the version of OS.
If you go out to buy such a box, I would recommend to look for a
solution based on a RAID system. The very low-price end is based on
single disks which, might not be a good idea for long term storage. A
RAID system (excpet for RAID0) has built-in redundancy, so that disks
may fail and you still can recover the data.

regards,
Martin




smime.p7s
Description: S/MIME Cryptographic Signature
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] refresh file layout error

[Patrick Farrell]

Martin might know about that short read thing, since his site has a nice wiki 
page on it:
https://wickie.hlrs.de/platforms/index.php/Lustre_short_read

Technically Lustre is allowed to return fewer bytes than requested, as it says 
on that page.  But it doesn't normally - LU-6389 is a bug where that can happen 
kind of often.  (Again, it's technically allowed as that page says...  But it 
shouldn't really happen in practice, which is why LU-6389 is a bug.)

So perhaps Gaussian does not retry short reads?  If memory serves, it's closed 
source, so you can't check - but perhaps you could ask the vendor?

From: lustre-discuss [lustre-discuss-boun...@lists.lustre.org] on behalf of 
Martin Hecht [he...@hlrs.de]
Sent: Friday, September 04, 2015 8:53 AM
To: E.S. Rosenberg; Wahl, Edward
Cc: lustre-discuss@lists.lustre.org
Subject: Re: [lustre-discuss] refresh file layout error

On 09/03/2015 07:22 AM, E.S. Rosenberg wrote:
> On Wed, Sep 2, 2015 at 8:47 PM, Wahl, Edward  wrote:
>
>> That would be my guess here.  Any chance this is across NFS?  Seen that a
>> great deal with this error, it used to cause crashes.
>>
> Strictly speaking it is not, but it may be because a part of the path the
> server 'sees'/'knows' is a symlink to the lustre filesystem which lives on
> nfs...
>
Ah, I can remember a problem we had some years ago, when users with
their $HOME on NFS were accessing many files in directories on lustre
via symlink. Somehow the NAS box serving the nfs file system didn't
immediately notice that the files weren't on its own file system and
repeatedly had to look up in its cache, just to notice that the files
are somewhere else behind a symlink. If I recall correctly, the problem
could be avoided by:
- Either access the file via absolute path, or cd into the directory
(both via mount point, not (!) via symlink)
- Or make the symlink an absolute one (I'm not 100% sure, but I believe
the problem was only with relative links pointing out of the NFS upwards
across the mountpoint and down again into the lustre file system).
It could be something similar here. Do you have any chance to access the
files via absolute path in your setup and web server configuration?

best regards, Martin

___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] refresh file layout error

[Patrick Farrell]

Oops, I'm sorry - this was supposed to be a reply to Amit Kumar's thread.  
Apologies.

From: lustre-discuss [lustre-discuss-boun...@lists.lustre.org] on behalf of 
Patrick Farrell [p...@cray.com]
Sent: Friday, September 04, 2015 4:07 PM
To: lustre-discuss@lists.lustre.org; E.S. Rosenberg; Wahl,  Edward
Subject: Re: [lustre-discuss] refresh file layout error

Martin might know about that short read thing, since his site has a nice wiki 
page on it:
https://wickie.hlrs.de/platforms/index.php/Lustre_short_read

Technically Lustre is allowed to return fewer bytes than requested, as it says 
on that page.  But it doesn't normally - LU-6389 is a bug where that can happen 
kind of often.  (Again, it's technically allowed as that page says...  But it 
shouldn't really happen in practice, which is why LU-6389 is a bug.)

So perhaps Gaussian does not retry short reads?  If memory serves, it's closed 
source, so you can't check - but perhaps you could ask the vendor?

From: lustre-discuss [lustre-discuss-boun...@lists.lustre.org] on behalf of 
Martin Hecht [he...@hlrs.de]
Sent: Friday, September 04, 2015 8:53 AM
To: E.S. Rosenberg; Wahl, Edward
Cc: lustre-discuss@lists.lustre.org
Subject: Re: [lustre-discuss] refresh file layout error

On 09/03/2015 07:22 AM, E.S. Rosenberg wrote:
> On Wed, Sep 2, 2015 at 8:47 PM, Wahl, Edward  wrote:
>
>> That would be my guess here.  Any chance this is across NFS?  Seen that a
>> great deal with this error, it used to cause crashes.
>>
> Strictly speaking it is not, but it may be because a part of the path the
> server 'sees'/'knows' is a symlink to the lustre filesystem which lives on
> nfs...
>
Ah, I can remember a problem we had some years ago, when users with
their $HOME on NFS were accessing many files in directories on lustre
via symlink. Somehow the NAS box serving the nfs file system didn't
immediately notice that the files weren't on its own file system and
repeatedly had to look up in its cache, just to notice that the files
are somewhere else behind a symlink. If I recall correctly, the problem
could be avoided by:
- Either access the file via absolute path, or cd into the directory
(both via mount point, not (!) via symlink)
- Or make the symlink an absolute one (I'm not 100% sure, but I believe
the problem was only with relative links pointing out of the NFS upwards
across the mountpoint and down again into the lustre file system).
It could be something similar here. Do you have any chance to access the
files via absolute path in your setup and web server configuration?

best regards, Martin

___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org