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
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
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.....
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.
Following could be the major problems(if not all) you may end up in: