<div dir="ltr">There is a potentially lost PhD project there which was to be defended this month for which the person may simply give up and another project which represents two years of work but was never copied anywhere else. We also have many users who don't read notices and who probably aren't aware yet there was a problem so it's possible there is more loss yet to be noticed. Our environment has multiple scratch filesystems by design, so we are able to limp along while trying to recover data from this one. <div><br></div><div>I've been at this for nearly 30 years now, this is basically a 500 TB version of the first 5 1/4" floppy disk I was handed with the plea "this is the only copy of my thesis, can you please get it back..." I think the lesson has been driven home, for them and me, but we'd still like to get something back if we can and we will actually be completely down throughout the month of June for unrelated reasons so it's mitigated a bit by that planned downtime.</div><div><br></div><div>Given the number of floppy disks, Zip disks, Jaz drive cartridges, USB thumb drives, dead laptops,... I've been handed over the years the one constant take home lesson is that you can never stop educating people (including yourself) about the importance of keeping multiple copies of critical data no matter how stable the storage you use claims to be. It is ALL going to die eventually.</div><div><br></div><div>jbh</div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, May 19, 2017 at 11:57 AM Bogdan Costescu <<a href="mailto:bcostescu@gmail.com" target="_blank">bcostescu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello John,<br>
<br>
I'm quite curious to know what was the thinking behind taking a<br>
scratch filesystem down for so long, i.e. you wrote to the list on<br>
29.04 and likely you experienced the problem some days before, and you<br>
expect the image from the recovery company to reach you no sooner than<br>
beginning of June, so a downtime of 6+ weeks? Is there some really<br>
precious data stored there? Did you do some kind of costs analysis<br>
comparing recovery costs with recomputing the data? Your description:<br>
<br>
"Of course this is a scratch filesystem, of course people were warned<br>
repeatedly about the risk of using a scratch filesystem that is not<br>
backed up and of course many ignored that."<br>
<br>
fits one of our large filesystems too :) The software side (BeeGFS)<br>
has been resilient in the face of hardware failures until now, but I'm<br>
worried about an extended hardware failure (i.e. several disks failing<br>
at the same time) which would take some part of the data with them...<br>
<br>
Cheers,<br>
Bogdan<br>
<br>
On Fri, May 19, 2017 at 9:39 AM, John Hanks <<a href="mailto:griznog@gmail.com" target="_blank">griznog@gmail.com</a>> wrote:<br>
> Thanks Arif, I'm signed up there now.<br>
><br>
> As a general update, the most recently failed disk of the pair is at a data<br>
> recovery company who thinks they can recover a workable image from it. We<br>
> should have that back in two or three weeks and will try to use it to<br>
> recover the filesystem.<br>
><br>
> jbh<br>
><br>
> On Thu, May 18, 2017 at 5:21 PM Arif Ali <<a href="mailto:mail@arif-ali.co.uk" target="_blank">mail@arif-ali.co.uk</a>> wrote:<br>
>><br>
>> Hi John,<br>
>><br>
>> I would recommend joining up at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a> mailing list, where you<br>
>> will find very good experts from the HPC industry who know GPFS well,<br>
>> including, Vendors, users and integrators. More specifically, you'll you'll<br>
>> find gpfs developers on there. Maybe someone on that list can help out<br>
>><br>
>> More direct link to the mailing list, here,<br>
>> <a href="https://www.spectrumscale.org:10000/virtualmin-mailman/unauthenticated/listinfo.cgi/gpfsug-discuss/" rel="noreferrer" target="_blank">https://www.spectrumscale.org:10000/virtualmin-mailman/unauthenticated/listinfo.cgi/gpfsug-discuss/</a><br>
>><br>
>><br>
>> On 29/04/2017 08:00, John Hanks wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I'm not getting much useful vendor information so I thought I'd ask here<br>
>> in the hopes that a GPFS expert can offer some advice. We have a GPFS system<br>
>> which has the following disk config:<br>
>><br>
>> [root@grsnas01 ~]# mmlsdisk grsnas_data<br>
>> disk driver sector failure holds holds<br>
>> storage<br>
>> name type size group metadata data status<br>
>> availability pool<br>
>> ------------ -------- ------ ----------- -------- ----- -------------<br>
>> ------------ ------------<br>
>> SAS_NSD_00 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_01 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_02 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_03 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_04 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_05 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_06 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_07 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_08 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_09 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_10 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_11 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_12 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_13 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_14 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_15 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_16 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_17 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_18 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_19 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_20 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SAS_NSD_21 nsd 512 100 No Yes ready up<br>
>> system<br>
>> SSD_NSD_23 nsd 512 200 Yes No ready up<br>
>> system<br>
>> SSD_NSD_24 nsd 512 200 Yes No ready up<br>
>> system<br>
>> SSD_NSD_25 nsd 512 200 Yes No to be emptied down<br>
>> system<br>
>> SSD_NSD_26 nsd 512 200 Yes No ready up<br>
>> system<br>
>><br>
>> SSD_NSD_25 is a mirror in which both drives have failed due to a series of<br>
>> unfortunate events and will not be coming back. From the GPFS<br>
>> troubleshooting guide it appears that my only alternative is to run<br>
>><br>
>> mmdeldisk grsnas_data SSD_NSD_25 -p<br>
>><br>
>> around which the documentation also warns is irreversible, the sky is<br>
>> likely to fall, dogs and cats sleeping together, etc. But at this point I'm<br>
>> already in an irreversible situation. Of course this is a scratch<br>
>> filesystem, of course people were warned repeatedly about the risk of using<br>
>> a scratch filesystem that is not backed up and of course many ignored that.<br>
>> I'd like to recover as much as possible here. Can anyone confirm/reject that<br>
>> deleting this disk is the best way forward or if there are other<br>
>> alternatives to recovering data from GPFS in this situation?<br>
>><br>
>> Any input is appreciated. Adding salt to the wound is that until a few<br>
>> months ago I had a complete copy of this filesystem that I had made onto<br>
>> some new storage as a burn-in test but then removed as that storage was<br>
>> consumed... As they say, sometimes you eat the bear, and sometimes, well,<br>
>> the bear eats you.<br>
>><br>
>> Thanks,<br>
>><br>
>> jbh<br>
>><br>
>> (Naively calculated probability of these two disks failing close together<br>
>> in this array: 0.00001758. I never get this lucky when buying lottery<br>
>> tickets.)<br>
>><br>
>> --<br>
>> ‘[A] talent for following the ways of yesterday, is not sufficient to<br>
>> improve the world of today.’<br>
>> - King Wu-Ling, ruler of the Zhao state in northern China, 307 BC<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
>> To change your subscription (digest mode or unsubscribe) visit<br>
>> <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
>><br>
>><br>
>> --<br>
>> regards,<br>
>><br>
>> Arif Ali<br>
>> Mob: <a href="tel:+44%207970%20148122" value="+447970148122" target="_blank">+447970148122</a><br>
>><br>
>> _______________________________________________<br>
>> Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
>> To change your subscription (digest mode or unsubscribe) visit<br>
>> <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
><br>
> --<br>
> ‘[A] talent for following the ways of yesterday, is not sufficient to<br>
> improve the world of today.’<br>
> - King Wu-Ling, ruler of the Zhao state in northern China, 307 BC<br>
><br>
> _______________________________________________<br>
> Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
> To change your subscription (digest mode or unsubscribe) visit<br>
> <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
><br>
</blockquote></div></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div>‘[A] talent for following the ways of yesterday, is not sufficient to improve the world of today.’</div><div> - King Wu-Ling, ruler of the Zhao state in northern China, 307 BC</div></div></div>