Re: [gpfsug-discuss] Lost disks

IBM has a procedure for it that may work in some cases, but you’re manually editing the NSD descriptors on disk. Contact IBM if you think an NSD has been lost to descriptor being re-written. Bob Oesterlin Sr Principal Storage Engineer, Nuance From:

Re: [gpfsug-discuss] Lost disks

What is this manual header reconstruction you speak of? That doesn’t sound trivial at all. From: Oesterlin, Robert [mailto:robert.oester...@nuance.com] Sent: Wednesday, July 26, 2017 12:46 PM To: gpfsug main discussion list Subject: Re: [gpfsug-discuss] Lost

Re: [gpfsug-discuss] Lost disks

it can happen for multiple reasons , one is a linux install, unfortunate there are significant more simpler explanations. Linux as well as BIOS in servers from time to time looks for empty disks and puts a GPT label on it if the disk doesn't have one, etc. this thread is explaining a lot of this :

Re: [gpfsug-discuss] Lost disks

One way this could possible happen would be a system is being installed (I’m assuming this is Linux) and the FC adapter is active; then the OS install will see disks and wipe out the NSD descriptor on those disks. (Which is why the NSD V2 format was invented, to prevent this from happening) If

Re: [gpfsug-discuss] Baseline testing GPFS with gpfsperf

Hi Scott, >>- Should the number of threads equal the number of NSDs for the file system? or equal to the number of nodes? >>- If I execute a large multi-threaded run of this tool from a single node in the cluster, will that give me an accurate result of the performance of the file system?

[gpfsug-discuss] Lost disks

I have a client has had an issue where all of the nsd disks disappeared in the cluster recently. Not sure if it's due to a back end disk issue or if it's a reboot that did it. But in their PMR they were told that all that data is lost now and that the disk headers didn't appear as GPFS disk