Re: [lustre-discuss] Lustre 2.9 performance issues

While tuning can alleviate some pain it shouldn't go without mentioning that there are some operations that are just less than optimal on a parallel file system. I'd bet a cold one that a copy to local /tmp, vim/paste, copy back to the LFS would've been quicker. Some single-threaded small i/o

Re: [lustre-discuss] Lustre 2.9 performance issues

On Apr 25, 2017, at 13:11, Bass, Ned wrote: > > Hi Darby, > >> -Original Message- >> >> for i in $(seq 0 99) ; do >> dd if=/dev/zero of=dd.dat.$i bs=1k count=1 conv=fsync > /dev/null 2>&1 >> done >> >> The timing of this ranges from 0.1 to 1 sec on our old LFS but

[lustre-discuss] undelete

A user just rm'd a big archive of theirs on lustre, any way to recover it before it gets destroyed by other writes? ___ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

[lustre-discuss] kerberised lustre performance

Hi everyone, I just saw Sebatians' talk at LUG 2016 (Yes I know I'm a bit behind times) and I was wondering if and how much a performance impact there is from the need to get kerberos tickets before file actions (or is it only mounting?)... https://www.youtube.com/watch?v=zo6b03zxrIs Thanks, Eli