Re: [lustre-discuss] dne2: lfs setdirstripe

[Henwood, Richard]

On Thu, 2015-09-03 at 16:47 +, Faaland, Olaf P. wrote:
> Patrick,
> 
> Perhaps I'm not seeing something in front of my face.  So far I've found only 
> design documents discussing DNE phase I.
> 
> The places I have found any design docs at all are here:
> 
> http://wiki.old.lustre.org/index.php/Lustre_Design_Documents
> https://wiki.hpdd.intel.com/display/PUB/Intel+Design+documents
> 
> Where else should I be looking?
> 

There are DNE1 and DNE2 specific design docs here:

http://wiki.opensfs.org/Contract_SFS-DEV-001

r,


-- 
richard.henw...@intel.com
Intel High Performance Data Division
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] dne2: lfs setdirstripe

[Faaland, Olaf P.]

Patrick,

Perhaps I'm not seeing something in front of my face.  So far I've found only 
design documents discussing DNE phase I.

The places I have found any design docs at all are here:

http://wiki.old.lustre.org/index.php/Lustre_Design_Documents
https://wiki.hpdd.intel.com/display/PUB/Intel+Design+documents

Where else should I be looking?

Olaf P. Faaland
Livermore Computing
phone : 925-422-2263


From: Patrick Farrell [p...@cray.com]
Sent: Wednesday, September 02, 2015 7:50 PM
To: Faaland, Olaf P.; lustre-discuss@lists.lustre.org
Subject: RE: dne2: lfs setdirstripe

Olaf,

I can explain the rationale for the restrictions, though I have not verified if 
the root only one applies to striped as well as remote directories.  (It's a 
simple test, though.  I'm just not where I can reach a test system.)

Note, to be clear: DNE 2 does not replace DNE 1.  Remote directories and 
striped directories are different things and can coexist.

For enable_remote_dir, it applies only to remote directories - not striped 
directories.

As for the rationale: If enabled, it complicates things notably from an 
administrative perspective...  If you have multiple MDT changes in a path, it 
makes it harder to know what is where, and can cause files on, for example, 
MDT2 or MDT0, to become unreachable if MDT1 is lost.  Also, if you think 
carefully, it doesn't really enable any use cases that can't be done otherwise 
- at least, none that we could find that seemed practical.

As far as the root only thing:
Imagine you are trying to split the load between your MDTs by assigning 
particular users to particular MDTs.  If your users can create their own remote 
directories, they can escape this restriction.  Also, you can open up 
permission by setting it to -1.

I learned this by a mix of reading design docs, experimenting, and being at 
least tangentially involved via the PAC.
I'd suggest design docs as a good place to look for more.

- Patrick Farrell

From: lustre-discuss [lustre-discuss-boun...@lists.lustre.org] on behalf of 
Faaland, Olaf P. [faala...@llnl.gov]
Sent: Wednesday, September 02, 2015 5:21 PM
To: lustre-discuss@lists.lustre.org
Subject: Re: [lustre-discuss] dne2: lfs setdirstripe

The lustre we are testing with is built from commit

ea383222e031cdceffbdf2e3afab3b6d1fd53c8e

which is after tag 2.7.57 but before 2.7.59; so recent but not entirely current.

Olaf P. Faaland
Livermore Computing
phone : 925-422-2263

From: lustre-discuss [lustre-discuss-boun...@lists.lustre.org] on behalf of 
Faaland, Olaf P. [faala...@llnl.gov]
Sent: Wednesday, September 02, 2015 3:17 PM
To: lustre-discuss@lists.lustre.org
Subject: [lustre-discuss] dne2: lfs setdirstripe

Hi,

We have begun work on testing DNE with ZFS backend.  So far we've only done the 
installation of the filesystem and begun educating ourselves.

I see in man lfs, that "lfs setdirstripe" has some restrictions by default
 - only executable by root unless "mdt.*.enable_remote_dir_gid" is set
 - only directories on MDT can contain directories that are not on the same 
MDT unless "mdt.*.enable_remote_dir"

1. Are those restrictions still current, or do they refer to DNE phase 1 
restrictions that no longer apply?

2. If the first, allowing only root to invoke "lfs setdirstripe" is current, 
what is the rationale?

3. Is there documentation, or a mailing list thread, that we should read prior 
to posting questions?

Thanks,

Olaf P. Faaland
Livermore Computing
phone : 925-422-2263
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] dne2: lfs setdirstripe

[Faaland, Olaf P.]

Ah!  Thank you.

I'll put links on lustre.org so others can find them more easily.

Olaf P. Faaland
Livermore Computing
phone : 925-422-2263


From: Henwood, Richard [richard.henw...@intel.com]
Sent: Thursday, September 03, 2015 10:08 AM
To: Faaland, Olaf P.
Cc: lustre-discuss@lists.lustre.org
Subject: Re: [lustre-discuss] dne2: lfs setdirstripe

On Thu, 2015-09-03 at 16:47 +, Faaland, Olaf P. wrote:
> Patrick,
>
> Perhaps I'm not seeing something in front of my face.  So far I've found only 
> design documents discussing DNE phase I.
>
> The places I have found any design docs at all are here:
>
> http://wiki.old.lustre.org/index.php/Lustre_Design_Documents
> https://wiki.hpdd.intel.com/display/PUB/Intel+Design+documents
>
> Where else should I be looking?
>

There are DNE1 and DNE2 specific design docs here:

http://wiki.opensfs.org/Contract_SFS-DEV-001

r,


--
richard.henw...@intel.com
Intel High Performance Data Division
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] [HPDD-discuss] possible to read orphan ost objects on live filesystem?

[Martin Hecht]

Hi Chris,

On 09/02/2015 07:18 AM, Chris Hunter wrote:
> Hi Andreas
>
> On 09/01/2015 07:22 PM, Dilger, Andreas wrote:
>> On 2015/09/01, 7:59 AM, "lustre-discuss on behalf of Chris Hunter"
>> > chris.hun...@yale.edu> wrote:
>>
>>> Hi Andreas,
>>> Thanks for your help.
>>>
>>> If you have a striped lustre file with "holes" (ie. one chunk is gone
>>> due hardware failure, etc.) are the remaining file chunks considered
>>> orphan objects ?
> So when a lustre striped file has a hole (eg. missing chunk due to
> hardware failure), the remaining file chunks stay indefinitely on the
> OSTs.
> Is there a way to reclaim the space occupied by these pieces (after
> recovery of any usuable data, etc.)?
these remaining chunks still belong to the file (i.e. you have the
metadata entry on the MDT and you see the file when lustre is mounted).
By removing the file you free up the space.

In general there are two types of inconsistencies which may occur:
Orphan objects are objects which are NOT assigned to an entry on the
MDT, i.e. chunks which do not belong to any file. These can be either
pre-allocated chunks or chunks left over after a corruption of the
metadata on the MDT.

The other type of corruption is that you have a file, where chunks are
missing in-between. This can happen, when an OST gets corrupted. As long
as the MDT is Ok, you should be able to remove such a file. If in
addition the MDT is also corrupted, you should first fix the MDT, and
you might then only be able to unlink the file (which again might leave
some orphan objects on the OSTs). lfsck should be able to remove them,
depending on the lustre version you are running...

Another point: When the OST got corrupted, after having them repaired
with e2fsck, you can mount them as ldiskfs and see if there are chunks
in lost+found and use the tool ll_recover_lost_found_objs to restore
them in the original place. I believe these objects which e2fsck puts in
lost+found are another kind of thing, usually not called "orphan
objects". As I said, they usually can be easily recovered.

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] dne2: lfs setdirstripe

[Patrick Farrell]

Thanks, Richard.  Much appreciated.

From: lustre-discuss [lustre-discuss-boun...@lists.lustre.org] on behalf of 
Faaland, Olaf P. [faala...@llnl.gov]
Sent: Thursday, September 03, 2015 12:20 PM
To: Henwood, Richard
Cc: lustre-discuss@lists.lustre.org
Subject: Re: [lustre-discuss] dne2: lfs setdirstripe

Ah!  Thank you.

I'll put links on lustre.org so others can find them more easily.

Olaf P. Faaland
Livermore Computing
phone : 925-422-2263


From: Henwood, Richard [richard.henw...@intel.com]
Sent: Thursday, September 03, 2015 10:08 AM
To: Faaland, Olaf P.
Cc: lustre-discuss@lists.lustre.org
Subject: Re: [lustre-discuss] dne2: lfs setdirstripe

On Thu, 2015-09-03 at 16:47 +, Faaland, Olaf P. wrote:
> Patrick,
>
> Perhaps I'm not seeing something in front of my face.  So far I've found only 
> design documents discussing DNE phase I.
>
> The places I have found any design docs at all are here:
>
> http://wiki.old.lustre.org/index.php/Lustre_Design_Documents
> https://wiki.hpdd.intel.com/display/PUB/Intel+Design+documents
>
> Where else should I be looking?
>

There are DNE1 and DNE2 specific design docs here:

http://wiki.opensfs.org/Contract_SFS-DEV-001

r,


--
richard.henw...@intel.com
Intel High Performance Data Division
___
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

[lustre-discuss] Announcing Lustre* User Group PRC 2015

[Yarlagadda, Eman]

[Intel(r) - High Performance Data Division]


Event Details:

Hear directly from industry thought leaders about the latest Lustre* file 
system trends by attending the 2015 PRC Lustre* Users Group conference. Don't 
miss this exclusive opportunity to collaborate with industry leaders to advance 
the Lustre* file system and contribute to new releases on behalf of the open 
source community.

Register Here

Call for Papers: We are inviting you to send proposals for presentations at 
this event. Please send an abstract for a 30min technical presentation to 
fan.y...@intel.com before 
September 30th 2015.

Event Date: October 20th, 2015 from 8:30am - 5:00pm (Click Here to Add Event to 
your Calendar)

Location: Regent Hotel Beijing 
(99 Jinbao Street, Dongcheng District, Beijing, 15, China)

Telephone: +86 10 8522 1888

Review Agenda (To be published soon)


UNABLE TO ATTEND? We're sorry that you cannot make it to the event, but you can 
still sign-up for our mailing list to receive future communications about this 
gathering and valuable information about Intel (r) Solutions for Lustre* 
software.

Subscribe to Newsletter (Click 
Here)










[HPDD PRC Footer]





[Intel(r)]


Trademarks | Terms of 
Use | Privacy 
Policy | Contact Us


Copyright (c) 2014 Intel Corporation. All rights reserved. Intel, the Intel 
logo, and Intel Xeon are trademarks of Intel Corporation in the U.S. and/or 
other countries. *Other names and brands may be claimed as the property of 
others.

*Other names and brands may be claimed as the property of others.




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