I see the whamcloud repo is abandoned and I don't really see any forks or other
information out there, does anyone knows if this is abandoned?
https://github.com/whamcloud/integrated-manager-for-lustre
Scott
___
lustre-discuss mailing list
lustre-discu
We use them fairly extensively with 2.7 and 2.8 and find them useful and stable.
For cluster nodes, perhaps not a big deal, but for our many non-cluster clients
it is useful. We have multiple filesystems so sometimes many mounts. The main
benefit I think is not that sometimes they unmount, but
On 12/14/2015 12:43 AM, Dilger, Andreas wrote:
...
Is this a tool that you are using? IIRC, there wasn't a particular reason
that it was removed, except that when we asked LLNL (the authors) they
said they were no longer using it, and we couldn't find anyone that was
using it so it was removed
We noticed with recent versions of lustre lshowmount has disappeared.
Annoyingly, it's still in the lustre docs, this is at least noted with a
ticket:
https://build.hpdd.intel.com/job/lustre-manual/lastSuccessfulBuild/artifact/lustre_manual.xhtml#dbdoclet.50438219_64286
https://jira.hpdd.intel
We use robinhood policy engine to do this for GIDs to provide a fake
group quota sort of thing.
If you have to do this routinely, look into robinhood.
Regards,
Scott
On 10/14/2015 9:52 PM, Ms. Megan Larko wrote:
Hello,
I have been able to successfully use "lfs lsetfacl ." to set and
mod
I'd just add that we've been generally OK for running a variety of 2.X
servers vs 2.whatever clients.
For our latest project I hear we're going to try 2.7 server and 2.8
client. The client machines for us are much more likely to need OS
versions pushed forward.
Regarding interim patches to L
An important question is what performance do they have now, and what do
they expect if converting it to Lustre. Our more basically, what are
they looking for in general in changing?
The performance requirements may help drive your OSS numbers for
example, or interconnect, and all kinds of stuf
Another thing to think about is does he perhaps own files outside of his
directory? The quota is on the volume but you are only doing du on the
directory.
Even if he's not aware of it, things can happen like people using rsync
and preserving ownership. The original owner's usage then goes up.
It would be really convenient if all the presentations for various LUG,
LAD, and similar meetings were available in one page.
Ideally there would also be some kind of keywords for each presentation
for easy searches, but even just having a comprehensive list of links
would be valuable I think.
Regarding ZFS MDT backups -
Dealing with the metadata performance issues we performed many zfs mdt
backup/recoveries and used snapshots to test things. It did work, but
slow. It was *agonizing* to wait a day for each testing iteration.
So now in production we've just got a full and incrementa
I just want to second what Rick said - It's create/remove not stat of
files where there are performance penalties. We covered this issue for
our workload just by using SSD's for our mdt, when normally we'd just
use fast SAS drives.
A bigger deal for us was RAM on the server, and improvements w
Chris and others,
I have moved my ZFS notes to the lustre wiki and made a category -
http://wiki.lustre.org/Category:ZFS
I am hoping others will post their notes or useful tips, and have talked
to a few people.
Can you make a top level link to the category?
Thank you,
Scott
Has anyone been working with the lustre jobstats feature and SLURM? We
have been, and it's OK. But now that I'm working on systems that run a
lot of array jobs and a fairly recent slurm version we found some ugly
stuff.
Array jobs report their do SLURM_JOBID as a variable, and it's unique
for
, Alex.
On Apr 29, 2015, at 11:07 AM, Scott Nolin mailto:scott.no...@ssec.wisc.edu>> wrote:
Ok I looked up my notes.
I'm not really sure what you mean by record size. I assumed when I do
a file per process the block size = file size. And that's what I see
dropped on the filesyst
l re-run
some tests after upgrading to 0.6.4.1 .
Single file performance differs substantially from file per process.
Alex.
On Apr 29, 2015, at 9:38 AM, Scott Nolin mailto:scott.no...@ssec.wisc.edu>> wrote:
I used IOR, singlefile, 100MB files. That's the most important
workload for us.
Just to chime in on our 8+2 vs 10+2 tests, since I ran those.
I tested ldiskfs with hardware raid6 and raidz2. Hardware vs software
raid I think made no noticeable difference.
I used IOR, singlefile, 100MB files. That's the most important workload
for us. I tried several different file sizes,
me.
Scott
On 4/28/2015 3:50 PM, Christopher J. Morrone wrote:
Sure, no problem! I just added a Monitoring section to the sidebar for
you.
Chris
On 04/28/2015 01:25 PM, Scott Nolin wrote:
Thank you for clarifying the OpenSFS vs lustre.org thing Chris, this
makes sense to me.
That makes it
awiki
extension of some kind.
Thanks again,
Scott
On 4/28/2015 3:11 PM, Christopher J. Morrone wrote:
On 04/28/2015 11:58 AM, Scott Nolin wrote:
Hello,
With the new lustre.org and wiki.lustre.org site there is an opportunity
to make this a more useful tool for community involvement with L
Hello,
With the new lustre.org and wiki.lustre.org site there is an opportunity
to make this a more useful tool for community involvement with Lustre.
Here are my ideas for how to arrange the new site. I know Chris Morrone
and OpenSFS members are interested in what the community can do with t
On 4/16/2015 4:24 PM, Michael Kluge wrote:
On Wed, Apr 15, 2015 at 11:44 AM, Scott Nolin
wrote:
Since Intel will not be making community releases for 2.5.4 or 2.x.0
releases now, it seems the community will need to maintain some sort of
patch list against these releases.
I don't think
Since Intel will not be making community releases for 2.5.4 or 2.x.0
releases now, it seems the community will need to maintain some sort of
patch list against these releases. Especially stability, data
corruption, and security patches.
I think this is important so if people are trying a Lust
Here is my attempt to detail some of the Lustre statistics and methods
for collecting and working with them:
http://wiki.opensfs.org/Lustre_Statistics_Guide
Contributions are welcome.
Regards,
Scott
___
Lustre-discuss mailing list
Lustre-discuss@list
Here's how I understand it:
First number = number of times (samples) the OST has handled a read or
write.
Second number = the minimum read/write size
Third number = maximum read/write size
Fourth = sum of all the read/write requests in bytes, the quantity of
data read/written.
Since this
I should also add - many of those documents just don't belong in the
lustre manual anyway, such as monitoring JBOD arrays. But nonetheless
may be useful for some lustre installations.
Scott
On 8/14/2014 8:40 AM, Scott Nolin wrote:
Hi Andrew,
Much of this information is notes and not
on.
Scott
On 8/14/2014 6:13 AM, Andrew Holway wrote:
Hi Scott,
Great job! Would you consider merging with the standard Lustre docs?
https://wiki.hpdd.intel.com/display/PUB/Documentation
Thanks,
Andrew
On 12 August 2014 18:58, Scott Nolin mailto:scott.no...@ssec.wisc.edu>> wrote:
in general. But this
information may be helpful for some -
http://www.ssec.wisc.edu/~scottn/
Topics that I think of particular interest may be lustre zfs install
notes and JBOD monitoring.
Scott Nolin
UW SSEC
smime.p7s
Description: S/MIME Cryptographic Signature
he same.
>So are these performance issues after scubbing and is it possible to
>scrub online - I.e. some reasonable level of performance is maintained
>while the scrub happens?
>Resilvering is also recommended. Not sure if that is for performance
>reasons.
>
>http://docs.oracle.com/c
ch from Brian that should help
performance in your case:
http://review.whamcloud.com/10237
Cheers, Andreas
On Jun 11, 2014, at 12:53, "Scott Nolin"
mailto:scott.no...@ssec.wisc.edu>>
wrote:
We tried a few arc tunables as noted here:
https://jira.hpdd.intel.com/browse/LU-2476
H
off at 500
files/sec,
then declined so it was about 1/20th of that after 2.45 million files.
-Anjana
On 06/09/2014 10:27 AM, Scott Nolin wrote:
We ran some scrub performance tests, and even without tunables set it
wasn't too bad, for our specific configuration. The main thing we did
was verify i
Looking at some of our existing zfs filesystems, we have a couple with zfs mdts
One has 103M inodes and uses 152G of MDT space, another 12M and 19G. I’d plan
for less than that I guess as Mr. Dilger suggests. It all depends on your
expected average file size and number of files for what will
We have had success with rhel5 2.1.x clients and 2.4.0-1 servers.
On a test system with 2.5 servers we've also just rolled (rhel6) clients
back to 2.1.6 due to what looks like a client bug and it seems to work too.
Scott
On 5/7/2014 10:47 AM, Jones, Peter A wrote:
Mike
I would think either
You can do this with the --index option to mkfs, for example:
mkfs.lustre --fsname=(name) --ost --backfstype=zfs --index=0
--mgsnode=(etc)
Makes , --index=1 makes 1, and so on.
Scott
On 10/24/2013 2:35 AM, Andrew Holway wrote:
You need to use unique index numbers for each OST, i.e.
I would check to make sure your ldev.conf file is set up with the
lustre-ost0 and host name properly.
Scott
On 10/8/2013 10:40 AM, Anjana Kar wrote:
The git checkout was on Sep. 20. Was the patch before or after?
The zpool create command successfully creates a raidz2 pool, and mkfs.lustre
doe
Ned
Here is the exact command used to create a raidz2 pool with 8+2 drives,
followed by the error messages:
mkfs.lustre --fsname=cajalfs --reformat --ost --backfstype=zfs --index=0
--mgsnode=10.10.101.171@o2ib lustre-ost0/ost0 raidz2 /dev/sda /dev/sdc
/dev/sde /dev/sdg /dev/sdi /dev/sdk /dev/
I forgot to add 'slabtop' is a nice tool for watching this stuff.
Scott
On 8/23/2013 9:36 AM, Scott Nolin wrote:
You might also try increasing the vfs_cache_pressure.
This will reclaim inode and dentry caches faster. Maybe that's the
problem, not page caches.
To be clear -
You might also try increasing the vfs_cache_pressure.
This will reclaim inode and dentry caches faster. Maybe that's the
problem, not page caches.
To be clear - I have no deep insight into Lustre's use of the client
cache, but you said you has lots of small files, which if lustre uses
the ca
36 matches
Mail list logo
