Re: [lustre-discuss] Draining and replacing OSTs with larger volumes

Scott, This sounds great. Slower, but safer. You might want to integrate the pool suggestion Jongwoo made in the other recent thread in order to control allocations to your new OSTs (assuming you're trying to stay live during most of this). - Patrick From:

Re: [lustre-discuss] Draining and replacing OSTs with larger volumes

My Thanks to both Jongwoo and Patrick for your responses. Great advice to do a practice run in a virtual environment but I'm lucky enough to have a physical one. I have a testbed that has the same versions of all software but with iscsi targets as the OSTs, rather than physical arrays, and not

Re: [lustre-discuss] Suspended jobs and rebooting lustre servers

On Tue, 26 Feb 2019 at 23:25, Andreas Dilger wrote: > I agree that having an option that creates the OSTs as inactive might be > helpful, though I wouldn't want that to be the default as I'd imagine it > would also cause problems for the majority users that wouldn't know that they > need to ena

[lustre-discuss] upgrade from 2.10.5 to 2.12.0

Hello, I am planning a Lustre upgrade from 2.10.5/ZFS  to 2.12.0/ZFS any particular cavetat on this procedure ? Can I simply upgrade the Lustre package and mount the filesystem ? thank you Rick ___ lustre-discuss mailing list lustre-discuss@lists.

[lustre-discuss] Due Today: Lustre Usage Survey

Dear Lustre Community, Today, February 28th, is the deadline to provide your response to the Lustre usage survey. We are looking for trends in Lustre usage to assist with future planning on releases and will present the results at LUG. Please complete this short survey (

Re: [lustre-discuss] Suspended jobs and rebooting lustre servers

This is very good advice, and you can also vary it to aid in removing old OSTs (thinking of the previous message) - simply take the old ones you wish to remove out of the pool, then new files will not be created there. Makes migration easier. One thing though: Setting a default layout everywhe

Re: [lustre-discuss] Draining and replacing OSTs with larger volumes

Scott, I’d like to strongly second all of Jongwoo’s advice, particularly that about adding new OSTs rather than replacing existing ones, if possible. That procedure is so much simpler and involves a lot less messing around “under the hood”. It takes you from a complex procedure with many step

Re: [lustre-discuss] Suspended jobs and rebooting lustre servers

My strategy for adding new OSTs on live filesystem is to define a pool with currently running OST and apply pool stripe (lfs setstripe -p [live-ost-pool]) on all existing directories. It is better when it is done at first filesystem creation. After that, you can safely add new OSTs without newly c

Re: [lustre-discuss] Draining and replacing OSTs with larger volumes

On Thu, Feb 28, 2019 at 11:09 AM Scott Wood wrote: > Hi folks, > > Big upgrade process in the works and I had some questions. Our current > infrastructure has 5 HA pairs of OSSs and arrays with an HA pair of > management and metadata servers who also share an array, all running lustre > 2.10.3.