<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I run an old Lustre (1.8.9), but it doesn't support some forms of file locking that were even required for compiling some software. Doesn't happen often, but enough to give me pause. <br><br><span style="background-color: rgba(255, 255, 255, 0);">____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*<br>|| \\UTGERS |---------------------*O*---------------------<br>||_// Biomedical | Ryan Novosielski - Senior Technologist<br>|| \\ and Health | <a href="mailto:novosirj@rutgers.edu" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="3">novosirj@rutgers.edu</a>- 973/972.0922 (2x0922)<br>|| \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark<br> `'</span></div><div><br>On Dec 23, 2014, at 12:11, Prentice Bisbal <<a href="mailto:prentice.bisbal@rutgers.edu">prentice.bisbal@rutgers.edu</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Beowulfers,</span><br><span></span><br><span>I have limited experience managing parallel filesytems like GPFS or </span><br><span>Lustre. I was discussing putting /home and /usr/local for my cluster on </span><br><span>a GPFS or Lustre filesystem, in addition to using it just for /scratch. </span><br><span>I've never done this before, but it doesn't seem like all that bad an </span><br><span>idea. My logic for this is the following:</span><br><span></span><br><span>1. Users often try to run programs from in /home, which leads to errors, </span><br><span>no matter how many times I tell them not to do that. This would make the </span><br><span>system more user-friendly. I could use quotas/policies to encourage them </span><br><span>to use 'steer' them to use other filesystems if needed.</span><br><span></span><br><span>2. Having one storage system to manage is much better than 3.</span><br><span></span><br><span>3. Profit?</span><br><span></span><br><span>Anyway, another person in the conversation felt that this would be bad, </span><br><span>because if someone was running a job that would hammer the fileystem, it </span><br><span>would make the filesystem unresponsive, and keep other people from </span><br><span>logging in and doing work. I'm not buying this concern for the following </span><br><span>reasons:</span><br><span></span><br><span>If a job can hammer your parallel filesystem so that the login nodes </span><br><span>become unresponsive, you've got bigger problems, because that means </span><br><span>other jobs can't run on the cluster, and the job hitting the filesystem </span><br><span>hard has probably slowed down to a crawl, too.</span><br><span></span><br><span>I know there are some concerns with the stability of parallel </span><br><span>filesystems, so if someone wants to comment on the dangers of that, too, </span><br><span>I'm all ears. I think that the relative instability of parallel </span><br><span>filesystems compared to NFS would be the biggest concern, not performance.</span><br><span></span><br><span>-- </span><br><span>Prentice Bisbal</span><br><span>Manager of Information Technology</span><br><span>Rutgers Discovery Informatics Institute (RDI2)</span><br><span>Rutgers University</span><br><span><a href="http://rdi2.rutgers.edu">http://rdi2.rutgers.edu</a></span><br><span></span><br><span>_______________________________________________</span><br><span>Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a> sponsored by Penguin Computing</span><br><span>To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf">http://www.beowulf.org/mailman/listinfo/beowulf</a></span><br></div></blockquote></body></html>