Hi,

A couple of points around this:

- The smallest data movement policy you can set against an mtree is 14 days

- Files are selected for migration when data movement runs if (current time - file modification time) > data movement policy for the mtree

There is no way in which customers can override the 14 day minimum so only files which have 'aged' > 14 days can be migrated from active tier -> cloud/object storage. As a result of this the only way to migrate newly written data is to manually set the files modification time (mtime) to a previous point in time.

A files mtime can be modified using the unix/linux touch command - for example I create a new file:

# ls -al /data/col1/jftest/testfile

-rw-r--r--  1 root root 10737418240 Feb 23 16:38 /data/col1/jftest/testfile

I move the files mtime back by 90 days using the touch command:

# touch -d '90 days ago' /data/col1/jftest/testfile

We can see that the mtime has changed as follows:

# ls -al /data/col1/jftest/testfile

-rw-r--r--  1 root root 10737418240 Dec 15 17:00 /data/col1/jftest/testfile

Even if this file were brand new it would now be migrated if the corresponding mtree had a migration policy of 90 days.

When working with files on a DDR you can change the mtime using touch from a unix/linux system via an NFS mount or from a Windows system using a CIFS share (assuming you have touch.exe installed on the Windows system).

Hopefully this helps?

Thanks, James