OK, I got it.
Actually, robinhood considers any file modification or change as an access,
assuming that if a user changes file data or metadata recently, he still
cares about the file.
Thus, rbh actually takes access time = MAX(atime, mtime, ctime),
so it is perfectly expected that rbh's last access >= atime.
I first understood in your initial mail that rbh's last access was
outdated, i.e. < actual atime.
This is not expected, this is why I cared. But it finally doesn't seem
to be the case.
Regards,
Thomas
On 03/14/14 09:30, [email protected] wrote:
Hi Thomas,
This is my policy:
Policy default
{ condition { last_access > 3d } }
I ran robinhood with the dry-run option for my tests, this is a line
from the log:
2014/03/13 11:00:12 robinhood@xxx[6649/6]: Purged
'/scratch/xxx/xxxx/fichmeg/petit/m1.bin' using policy 'default', last
access *20.8d ago* | size=1048576, *last_access*=*1392909857*,
last_mod=1392312225, osts=ost#6: 39, ost#8: 39, ost#1: 80, ost#3: 48,
ost#7: 39, ost#9: 39, ost#0: 80, ost#2: 48
This last access is corresponding to 20/2/2014 à 16:24:17 but you can
see with stat command that the real last access was on 13/02/2014 and
the change time was 20/02/2014:
# stat /scratch/xxx/xxxx/fichmeg/petit/m1.bin
File: « /scratch/xxxx/xxxx/fichmeg/petit/m1.bin »
Size: 1048576 Blocks: 2048 IO Block: 4194304 fichier
Device: 2c54f966h/743766374d Inode: 144115205272502310 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 211/ xxxx) Gid: ( xxx/ xxxxx)
*Access: 2014-02-13 18:23:45*.000000000 +0100
Modify: 2014-02-13 18:23:45.000000000 +0100
*Change: 2014-02-20 16:24:17*.000000000 +0100
But, despite this, it's working. I change the acess time on one file
and run an another test with robinhood:
# stat /scratch/xxxx/xxxx/gig2.bin
File: « /scratch/xxxxxxx/gig2.bin »
Size: 4294967296 Blocks: 8388640 IO Block: 4194304 fichier
Device: 2c54f966h/743766374d Inode: 144115205255725241 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 211/ xxx) Gid: ( xxx/ xxx)
*Access: 2014-03-13 10:59:22*.000000000 +0100
Modify: 2014-02-11 13:42:44.000000000 +0100
*Change: 2014-02-20 16:24:17*.000000000 +0100
Then I run "robinhood -S -O --dry-run" and "robinhood -O --dry-run"
and when i check the log, this file was not purged. So it's ok for me.
I was just surprised by the date on the log.
About GPFS, we have two different environments, one with Lustre
Filesystem and an another with GPFS Filesystem. As we want to use
robinhood to manage file on Lustre, we'd like to manage GPFS files
also with robinhood.
I'll give you some feedback if i can implement this.
Have a good day and thank you,
Regards,
Emilie
------------------------------------------------------------------------
*De: *"LEIBOVICI Thomas" <[email protected]>
*À: *[email protected]
*Cc: *[email protected]
*Envoyé: *Jeudi 13 Mars 2014 14:42:26
*Objet: *Re: [robinhood-support] Issue with accestime criteria
On 03/13/14 10:04, [email protected] wrote:
> Indeed, it's seems to work. It's quite surprising because in the log
> there's still the "wrong" last access, but the policy is apply on the
> "good" one.
An extract of your policy definition would help me understanding what
you want to do,
and a copy the related line of log too, so I can double check and ensure
your policy application is safe.
I've never heard about running robinhood on GPFS. People use to
implement built-in GPFS policy engine on it.
I'd be curious to know your interests in running robinhood on GPFS, and
your feedback about this experimentation.
Thanks
Thomas
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
robinhood-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/robinhood-support
