> On May 19, 2016, at 12:46 PM, Nathan Dauchy - NOAA Affiliate
> wrote:
>
> Thanks for pointing out the approach of trying to keep a single file from
> using too much space on an OST. It looks like the Log2(size_in_GB) method I
> proposed works well up to a point, but breaks down in the capa
On Wed, May 18, 2016 at 2:04 PM, Mohr Jr, Richard Frank (Rick Mohr) <
rm...@utk.edu> wrote:
>
> 2) Use some sort of formula (like ORNL’s “file_size/100GB” or even your
> log function)
>
> Since I mainly care about striping for large files and I want the stripe
> count to increase as file size grow
"1) More even space usage across OSTs (mostly relevant for *really* big files,
..."
When OSTs are almost full and user writes large file it can overfill the OSTs.
Having file OSTs striped over several OSTs somewhat mitigates this issue.
2) bandwidth ...
It is better to benchmark the applicat
Ah, of course - We're only talking about restriping existing stuff.
Yes, that's just fine - No lock conflicts on reading. Looks good to me.
This is probably also something we'd want to allow via HSM. Not sure
how the current patches interact with that (haven't looked).
- Patrick
On 05/19/2
Patrick,
You bring up an interesting point on read vs. write performance. We can't
use lfs_migrate control the stripe count used for writes (obviously), so
that is left up to the application developer or at least the user to
intelligently place shared access files in a directory with wider
stripi
Hello Lustre team,
We have an older production cluster with 1.8.1 , with 1 MDT/MDS server and
two OST/OSD servers. The network card of one of the OSD servers (lxsrv3)
crashed (eth0), and we put a new one (eth5). Then we changed
modprobe.conf.local of the server:
options lnet networks="tcp0(eth5)"
