Space Management and Data ONTAP– Part 5

Eventually, as more files are changed, more and more blocks will be assigned from the snapshot reserve.  The df –k command will show the amount of space being used within the active file system and in the .snapshot directory.

There is nothing magical about the 20% number.  Sometimes we may want to decrease the percentage allocated to the snap reserve.  Sometimes we may want to increase it.  It all depends on the rate at which data changes in the volume and how long we want to keep our snapshots available.

Suppose I want to change the snapshot reserve in vol3 to 30% instead of 20%.

Notice the space allocation on vol3 has now changed.

As you can see, it is possible that more than 20% of the blocks within the volume may actually be assigned to the snapshot reserve.  This reduces the amount of space available to the active file system.  In this case we increased the space allocated to the snapshot reserve.  We could just as easily reduce the size of the snapshot reserve.

If these are NAS volumes – used for CIFS or NFS – then the creation and deletion of snapshots is probably being controlled by Data ONTAP’s snapshot scheduler.  This is configured either with the snap sched command or from filerview.  Filerview’s screen to modify the parameters for vol3 looks like this:

Notice we can change the percentage of space preallocated for snapshot blocks here as well as with the snap reserve command.

What I’m interested in here is the Number of Scheduled Snapshots to Keep options.  Logically, the longer I keep snapshots around the greater the difference will be between the blocks in the active filesystem and the oldest snapshot.  Remember that blocks pointed to by any snapshot cannot be updated – they are read-only – as long as the snapshot exists.

The snapshot scheduler controls how long the snapshots will be kept and when they will occur.  For example, weekly snapshots occur at midnight on Sunday nights.  If the scheduler is set to retain the last 6 weekly snapshots it will delete the oldest weekly snapshot after it has accumulated 6 weekly snapshots. The last 6 weekly snapshots will be maintained and older snapshots will be automatically deleted.

The same is true for nightly snapshots (which are taken at midnight every day except Sunday) and hourly backups (which are taken on the hours specified).  The number scheduled to be kept will limit how far back we can go to recover files.

Ideally equilibrium is reached, with the percentage of blocks allocated to the snapshot reserve adequate for the length of time we want to have the snapshots available.  As snapshots are automatically deleted blocks which are pointed to uniquely from that snapshot will be returned to the free space pool in the active file system.

If more blocks are needed than have been set aside by the snapshot reserve than they will be taken from the active file system.  (This is the default behavior and can be changed.) A user will see a situation where deleting files may not actually free any space.  This is because there are no available free blocks in the snapshot reserve.  Free blocks will not be available until some snapshots are deleted and, if no other snapshot points to them, the blocks will be returned for reuse.

In extreme situations, it is possible that the active file system may actually run out of blocks and it will be impossible to change files in the volume or add new files.  The storage system administrator will have to intervene, either by growing the volume or by deleting old snapshots so that blocks associated with them can be reused.

For volumes used to support NAS applications this is usually adequate.  This situation should be extremely rare.  After the system administrator deletes some snapshots or grows the volume, users can proceed normally.  For volumes that contain LUNs, the situation is more complex and   we’ll be looking at some additional options that might be useful for these volumes next time.

Cisco Certification Abroad

Cisco Certification in South America seems to be held in high regards.  I was recently abroad over the winter holidays and while lounging about did some job inquiries in Colombia. Little to say there were some heavy salaries to be had if you possess the correct certifications. CCNA seemed to be commanding a minimum salary while the professional certification CCNP and CCSP in particular were being paid US equivalent salaries, this might not seem that big a deal yet once you take into consideration the cost of living difference you will find yourself living the upper class lifestyle.  What really took me back was the salary a CCIE could command.  In order to attract appropriate talent to the game they were offering approximately twice the going US rate.  What does that mean, quarter of a million salary as a base, negotiable up from there.   And once again once you factor in the cost of living you are really quite well off.  So whats my advice?  Learn Spanish and get your CCIE!

Will ‘7’ Be Windows’ Lucky Number?

We’re taking a short break from IPv6 series to talk about the new Windows 7.0, Microsoft’s new operating system that many are looking forward too.

With download problems solved, no killer problems seem to have arisen so far in Win7’s public beta.  Suprisingly.

In fact, overall, the process appears to be going overall fairly smooth up until now, with the exception of what happened on Friday.

Microsoft (NASDAQ: MSFT) servers were so overwhelmed even before the Windows 7 public beta was slated to be posted on Friday. A crush of traffic even before the beta build was released forcing Microsoft to deploy more servers than originally planned, which ultimately delayed the program’s start until Saturday.

After using it for a day or two, people didn’t have any complaints, which was refreshingly good news.  Perhaps a dozen users, including one who claimed to be a Microsoft employee, did report that, for them, the beta freezes when they try to run Windows Live Messenger 2009.

We have high hopes from Windows 7.0.  Let’s keep our fingers crossed.

Space Management and Data ONTAP– Part 4

We’ve been discussing how the WAFL file system allocates space for volumes, including the   meaning of space guarantees, space reservations and fractional reserve.  Now I’d like to look a little deeper at snapshots and space management from a snapshot perspective.

Basically, when a snapshot occurs all the blocks associated with data in the volume are frozen.  Sometimes people use the term snapshot “copy”.  This is accurate in a certain sense.  The snapshot looks like a copy of the data in the file system.  For the most part, we can generally treat the snapshot as if it were a read-only copy of the data in the file system.

In fact, the blocks of data were not copied.  They were simply frozen in place.  Each snapshot creates a version of the file system.  The blocks that belong to files associated with each version cannot be altered.  Currently WAFL supports up to 255 versions, or snapshots, per volume.

After the snapshot occurs we can continue to change files and create new files in the active version of the file system.  We can do this because WAFL supports multiple virtual inode systems to track each version of the filesystem.  Blocks are allocated from free space available to the volume.  By design, WAFL does not overwrite data.  It writes updates into free blocks.  Obviously this integrates beautifully with snapshots, but it does raise an interesting question:  since we can have multiple versions of the files in a volume how do we manage space utilization of the volume?  Across all the “versions” of the file system, I may have only a single version of one file while I could have 256 versions (counting the one in the active file system) of another.

Generally the way this is done is through something called the snapshot reserve.

By default, when a volume is created, 20% of the space within the volume is assigned to the snapshot reserve.  If I want to check this for a volume – vol3 in my example – I would use the following command:

You can also check with the df command.  For example:

You can see the amount of space allocated to each volume is divided into two categories: the active file system and the .snapshot directory.  When volumes vol1, vol2 and vol3 were created 100 megabytes were allocated to each.  For each volume, this has been subdivided into approximately 80 MB for the active file system and 20 MB for the .snapshot directory.

Suppose we were to create a file in vol3.  Some blocks would be allocated to contain this file in vol3.  If we take a snapshot of vol3, there is still only one version of the file.  No blocks will be allocated from the snapshot reserve at this point.  However if we make changes to this file then there will be some blocks which are different between the file that exists in the snapshot and the file that exists in the snapshot.  The blocks associated with the file in the snapshot that are different from the blocks in the active files system will be assigned, not from the active file system, but from the snapshot reserve.

This is even clearer with the example of a deleted file.  Suppose we take a snapshot of a volume that contains some file and then we delete the files from the active file system.  The blocks containing the files cannot actually be freed because the snapshot still references them.  As long as the snapshot exists the files will still be there.  However the space occupied by the blocks will now be counted against the snapshot reserve and an equivalent amount of free space in the snapshot reserve will be allocated to the active file system.  This makes it look, from a space perspective, like the files were actually deleted when in fact they continue to be stored in the volume and are now referenced through a .snapshot directory.