14:24 to: ink 
yes 

16:30 to: Christopher J. Walker 
More of a Lustre question (so leave it until the end) - but I'm curious which version of Lustre  is/was used for tarring up that directory in /work? And the hardware config. 

18:52 to: Andrew 
Chris, we are running Lustre 2.4.1 according to /proc/fs/lustre/version 

19:49 to: Christopher J. Walker 
Thanks. 

20:14 to: Andrew 
Should also note that when using rsync you canb get really poor performance using "-z" flag 

20:37 to: Andrew 
This is because you become CPU-bound rather than IO-bound due to the compression overhead 

21:42 to: Andrew 
Depends on the bandwidth (fs or network) available for the transfer but when copying between two fs mounted on the same system it is usually slower 

27:05 to: Andrew 
You can either ask questions in the chat window or speak 

27:20 to: Vaughan 
what quotas are in place? 

27:52 to: Vaughan 
ok 

28:07 to: Andrew 
All projects have a size quota on all file systems 

28:32 to: Christopher J. Walker 
Is there a way to have rsync like functionality over gridftp, or bbcp? 

28:50 to: Christopher J. Walker 
That's copying multiple files and syncing them? 

29:03 to: Andrew 
At the moment we do not have inode quotas but will probably be introducing them at some point as number of files tends to be growing quicker than size ort than the file systems can deal with 

29:37 to: Andrew 
inode quotas are essentially file number quotas 

30:13 to: Andrew 
Chris, there are tools such as gtransfer and gsatellite that provide some functionality like this but not the full set 

30:55 to: Andrew 
As rsync is just a wrapper that can use different protocols under the hood it does not seem impossible that you could call GridFTP from rsync 

31:04 to: Andrew 
May be worth looking into this 

31:36 to: Andrew 
We will do some digging 

31:54 to: Christopher J. Walker 
For GridPP like data sizes, that would be useful - also doing transfers in parallel. 

32:13 to: Christopher J. Walker 
http://fasterdata.es.net/ is a useful resource for those who don't know it. 

32:21 to: ink 
Is bandwidth to/from login nodes controlled/throttled? Or it is users' responsibility to be sensible? 

32:25 to: Andrew 
That is a really good website! 

33:14 to: Andrew 
We will add a link to that website from our documentation 

33:48 to: Andrew 
Bandwidth is generally not an issue - JANET is so good now 

34:09 to: Vaughan 
what about recovery point time in the RDF, i.e. what is the window before data is safely backed up 

34:11 to: Andrew 
Contention on nodes usually hits CPU/memory limits before network limits 

34:42 to: Andrew 
We are aiming for a daily snapshot cycle 

34:49 to: Andrew 
on the RDF 

35:50 to: Andrew 
Sometimes we may fall a little behind this if someone deposits a huge number of files in a single day (it seems to be number of files that casues the issue rather than size). 

36:36 to: Andrew 
We are working with the vendor to optimise the backup process to deal with these issues and initial investigations are positive. 

38:36 to: Andrew 
Thanks all for joining. This is the start of more coordinated activity and training aroung practical data management and optimising transfers that we are working on 

38:41 to: Christopher J. Walker 
Thanks. 

38:46 to: Andrew 
We will be producing stuff for our face-to-face and online training around these topics