Snaplock

[dirkslechten]

Hello,

Is it possible to create a normal flexvol volume in a Snaplock Aggregate? For example if you put the retention period to 0?

SnapLock is an attribute of the aggregate; therefore, the volume contained in that aggregate inherits

the aggregate’s SnapLock attributes. Every FlexVol volume created in a SnapLock aggregate is, by

definition, a SnapLock volume. A SnapLock Compliance aggregate contains only SnapLock

Compliance flexible volumes, and a SnapLock Enterprise aggregate contains only SnapLock

Enterprise flexible volumes.

Thank you in advance

[jose_miguel_almagro]

I think that if you don't do the commit to the file, the retention period doesn't apply.

But I only have been worked with SnapLock Enterprise, not Compliance mode, and some time ago....

[dirkslechten]

The problem I'm facing is the following

if you need only a limited space for snaplock (like 2TB) and you are working with 2TB disks, you would create an aggregate of 3 disks, but then you get the performance of 1 sata disk (which is terrible)

so what happens if you create a snaplock aggregate of 13 disks and you need a non snaplock volume, this isn't possible?

what do you mean by commit the file? If you write the file in the volume it is commited

[mwalters]

SnapLock (aside from the "autocommit" option) generally works with an application changing the attributes of a file to be read only.   That is the "act of committing" it.    Copying a file that was read-only from another place to a SnapLock volume will NOT do the same: it is the act of changing the attribute (attrib +r, chmod 444) that "locks it".

Retention times are, however, set by volume (not aggregate), so in theory what you are asking for should be possible.

If you had a "regular" set of data that was not intending to be locked, then for the most part I think you would be okay.   I am not sure, however, whether the default & maximum retention time can be set to zero.   I suspect it can, and if you did that then nothing would ever get locked: happy days!

In general it is certainly not recommended, since it is feasible someone could change those retention times and "unusual behaviour" might follow.....

cheers

Mike

[radek_kubka]

Hi Mike,

Good to see you around!

It's interesting subject, indeed. I've recently came across similar dilemma & decided to stick to the official guidelines that SnapLock aggregate is an "all or nothing" choice. This, however, can be very inflexible, especially in situations where the amount of data required locking is ether small, or unknown.

Having a freedom of choosing between "locked" & "unlocked" volumes sharing the same aggregate would be really nice.

Regards,

Radek

[nagp]

Hi Mike,

Following could be the major problems(if not all) you may end up in:

1. 1) If a file with contents has its write permission removed, it becomes a worm file. After expiry the file can only be deleted but the contents cannot be modified(even if you the min/max/def to 0days)  This applies to both SLE and SLC vols.
2. 2) You can’t change the file permission of an expired worm file(which can be created by above point). Applies to both SLE and SLC vols
3. 3) If you use SLC vol, you can’t do a snap restore.
4. 4) You cannot delete un-expired files even in SLE without configuring a SLC volume which is required for audit logging.
5. 5) You can’t rename a directory
6. 6) You can’t rename a SLC volume
7. 7) Volume snapmirror(VSM) resync is not allowed with SLC volume as destination(In VSM if you choose SLC as destination then source needs to be SLC too)
8. 😎 QSM resync will be allowed for a SLC dest volume only if source volume is also SLC.

[dirkslechten]

Hello,

Thank you very much for the answers, it helped me alot in understanding this subject.

Have a nice weekend all

Cheers

Dirk