Celerra FLR toolkit also usable for Isilon SmartLock?

Hi,

In the FLR documentations it is mentioned that it can be used for Celerra and VNX file systems. I am not sure if it can be used for isilion.  You can try it on a test FS.

Hi Jithin,

Thanks for your reply. I tried to do that, but the monitor part of the FLR toolkit uses dhsm to communicate with the Celerra. It looks like that Isilon does not support dhsm, so the monitor does not work.

The flrapply tool from the toolkit does only use the cifs connection, and this works. However with flrapply it's not possible to lock files which are not modified in for example the last 10 days.

So at this time no real solution yet as the application provider is not able to include read-only-bit-setting in their processes.

I have to look into OneFS7 (Mavericks) to see if there are automated locking options available now.

The FLR Toolkit was designed specifically to work with the FLR feature in Celerra (also known as Celerra WORM).  CWORM works by changing the mtime on the file to the expiration date of the file and then setting the file to read only.  Once the file is set to read-only, it cannot be changed until the mtime expires.  FLR-E (Enterprise) allows you to then change the mtime again (to something before the current time) so that you can delete (but not modify) the file.  FLR-C (Compliance) does not allow you to change the mtime once the file has been locked.  The FLR Toolkit simply automates the process of setting the appropriate mtime and locking the files.

SmartLock works differently.  You designate a SmartLock folder, dump files into it, and then issue a CLI command to commit (lock) the files.  FLR Toolkit would not be guaranteed to function correctly on Isilon.

Mavericks (OneFS7) automates the committing of files in Compliance mode.  Once the files are moved into the SmartLock directory, they are locked.  So an external "FLR Toolkit" type of software is no longer necessary.

Thanks for your info William.
Celerra sets retention time by changing atime (last access time) and by setting read-only bit (CIFS) and/or removing write-bit (Unix/NFS).

However also Isilon Smartlock works the same way as Celerra does. Retention periods can be set by changing the atime and file is locked by setting CIFS readonly-bit (or removing Unix NFS write-bit). Therefore the FLR toolkit locking part will work (uses standard client-OS functions to set atime and readonlybit). However the intelligence in selecting files for locking does not work as Isilon doesn't support DHSM, which is required for the FLR-monitor to run.

In my best knowledge there is no OneFS CLI command to lock files (other than executing chmod on the Isilon commandshell).

And indeed with OneFS7 we have a new autocommit option available. I have read the OneFS7 userguide (chapter8), and from what I can find the autocommit is available both in Enterprise and Compliance mode. The only thing is that I am afraid is if the autocommit function is sufficient to secure files. The userguide states that when the autocommit time period for a file is exceeded AND the file is accessed by a user the file is locked. This means that files are never locked when not accessed after initial placement.

What will happen when a delete command is issued against a file which has the autocommit time exceeded (and should be locked) but does not have the lock. Will the file be deleted? Or will this delete command trigger the autocommit locking and the delete be denied?

To summarize:
- FLR toolkit monitor function not Isilon compatible (and probably never will be)

- Snaplock Autocommit probably also available in Enterprise mode?
- Are stored files safe when using Autocommit function?