Snaplock Autocommit question

[jkoelker01]

Hello -

I have a question in regards to the snaplock compliance Autocommit feature. We currently have a volume contained in an aggregrate that has snaplock compliance applied too it. We have used this volume for a few years now without issue. In our environment we have a 2003 server that sends files to this snaplock volume with the read-only flag set on it already. Currently we are in the process of migrating to a new server and have the option to eliminate some software that was marking the read-only flag for us. This would eliminate complexity and cost. We are looking at this because we found the option for the snaplock compliance volume called snaplock_autocommit_period. My question is currently we are using this option but would like to turn it on. Will turning this feature on have any adverse effects on the rest of the volume which already contains sensitive data or will it only apply to new files being sent to the volume? As always, I appreciate the help and advice.

Environment:

FAS2240-2

8.1.1 7-mode

Cifs, NFS, Snaplock Compliance

[JGPSHNTAP]

show me vol options on the volume?

https://library.netapp.com/ecmdocs/ECMP1196889/html/GUID-6FFE24E8-A8C1-4520-A9FD-B7EA07964D49.html

Is there an app that is sending it read-only and controlling the locking?

[jkoelker01]

controller1> vol options wormvol1
nosnap=off, nosnapdir=off, minra=off, no_atime_update=on, nvfail=off,
ignore_inconsistent=off, snapmirrored=off, create_ucode=off,
convert_ucode=off, maxdirsize=9175, schedsnapname=ordinal,
fs_size_fixed=off, snaplock_compliance, guarantee=volume,
svo_enable=off, svo_checksum=off, svo_allow_rman=off,
svo_reject_errors=off, no_i2p=off, fractional_reserve=0,
snaplock_autocommit_period=none, snaplock_default_period=max,
snaplock_minimum_period=0y, snaplock_maximum_period=30y, extent=off,
try_first=volume_grow, read_realloc=off, snapshot_clone_dependency=off,
dlog_hole_reserve=off, nbu_archival_snap=off
controller1>

Currently the software before the filer marks the file as read-only and then sends it to the filers worm volume. At that point it no longer controls the read-only bit. We have the option to take the software out of the equation and just let the filer mark the file read-only. I'm also wondering if there is an immediate option for marking it or if it has to wait 1 hour at the minimum to mark it as read-only. Thanks for replying.

[JGPSHNTAP]

We don't like to do that.

Also, i see your default setting is max.  We never do that, we leave it as min and let the app control it.  Which app are you talking about?

[jkoelker01]

The app is EMC DiskXtender. It's what our vendor uses to talk with their program we use for image viewing/indexing.

Unfortunately the original worm volume was setup by one of our vendors and that is what we are stuck with. Do you know if turning on the autocommit feature will have any adverse effects on the existing data or will it only start marking the read-only flag for new files coming in? 

I see the minimum time for doing autocommit is 2 hours but says it won't be exactly that as it depends on what else is going on, how many files there are etc.... Do you know will it know which files are new and not have to scan the volume to see which files need the read-only flag set or how does that process work? Thanks again for any advice you have.