7 comments

Azure Virtual Machines: Event 257: Defrag: Slab Consolidation/ Slab Analysis

Published on Wednesday, March 4, 2015 in , ,

I’ve got a customer running some virtual machines on the Azure IAAS platform, and when doing a quick checkup I found the following recurring events in the event log:

  • The volume (C:) was not optimized because an error was encountered: Neither Slab Consolidation nor Slab Analysis will run if slabs are less than 8 MB. (0x8900002D)
  • The volume Temporary Storage (D:) was not optimized because an error was encountered: Neither Slab Consolidation nor Slab Analysis will run if slabs are less than 8 MB. (0x8900002D)
  • The volume Data (F:) was not optimized because an error was encountered: Neither Slab Consolidation nor Slab Analysis will run if slabs are less than 8 MB. (0x8900002D)

Sample event:

image

I’m aware that Windows does maintenance on a regular base all by itself. One of these tasks is a scheduled defrag:

image

You’ll probably see that there’s no trigger for this particular task, yet it runs regularly! That’s because there’s another scheduled task called “regular maintanance” who calls this specific task. An excellent writeup can be found here: DataToHelpThePeople: Maintenance at 3AM in the Morning

I did some googling and I quickly came accross this: KB2964429: Storage Optimizer memory use increases when it runs on thin provisioned LUNs

From that article: There's no need to run Storage Optimizer on thin provisioned LUNs that use an allocation size (also known as slab size) of less than 8 MB. Thin provisioned LUNs that have a smaller slab size manage space more efficiently, and the benefits of defragmenting them are not as great.

So that got me curious, how big is the allocation size on these volumes? We can find this information using diskpart:

image

After selecting a given volume, execute “filesystem”. In our example we have 4 MB which is, as the erorr states, less than 8 MB. Both the OS disk and the Temporary Disk have 4 MB which is the default I guess. My custom disk (F:) also has this value.

image

If we check the action of the scheduled task we can see that this is the command being executed: %windir%\system32\defrag.exe -c -h -k -g –$ If we execute that command manually, the same events are logged.

image

From defrag.exe /? I can tell that we could ommit –k in order to avoid slab analysis and consolidation. However upon executing the command I’m not really sure much happens in the background.

image

In the following screenshot you can clearly see that for each volume an event with ID 258 is logged: The storage optimizer succesfully completed retrim on XYZ. This events are NOT logged when I run the defrag command without the –k switch.

image

Your first reaction might be to disable this scheduled task all togehter. You might not care about fragmentation. But you might care about your billing statement… If you care check: fabriccontroller: Release unused space from your Windows Azure Virtual Hard Disks to reduce their billable size Bottom line: whenever this maintenance tasks finds unused storage it reclaims it and lowers the overall VHD size. Which means you pay less for your storage account!

I’m not really sure how to move forward. On the one hand I really detest recurring, safe to ignore, errors in events logs. But I don’t like changing system stuff like this without some official guidance. So if you got something to add, feel free to comment!

Related Posts

7 Response to Azure Virtual Machines: Event 257: Defrag: Slab Consolidation/ Slab Analysis

Anonymous
16 December, 2015 17:33

A fantastic article, I agree with you - I don't particularly want to change anything if I can help it.

I did spot a hotfix for this (Windows 8.1 and Server 2012r2); am about to try this:

https://support.microsoft.com/en-us/kb/2929874

Anonymous
24 May, 2016 20:36

What was your result? Was applying the hotfix successful? Did you have any issues?

Anonymous
26 May, 2016 23:51

Best article on this issue I have found - I am running a local VDI solution I just built from scratch and having same issue. Will try -k removal.

Anonymous
08 June, 2016 11:16

Just had the same error on SQL servers. Great info! Really helped me but also not certain if we like errors that are ok ...

27 June, 2016 08:08

My understanding is that Microsoft now provisions the entire size of your VHD regardless of consumption inside the guest OS. I doubt there is much gain to defrag in Azure, but I will be contacting my azure engineer on this since he errors are often popping up on my SQL server

06 August, 2016 18:24

Note the “Regular Maintenance” task doesn't actually start at 3am. The Details column on the Triggers tab of Task Scheduler is misleading. If you edit the trigger for the “Regular Maintenance” task you'll find that there is a random delay of up to 4 hours set for this task.

Anonymous
29 December, 2016 01:36

so i found this article here. http://www.storage-spaces-recovery.com/library/storage-spaces-fundamentals.aspx. it looks like that slabs are the building blocks on top of physical drives. I am guessing that a defrag causes windows to be smart enough to say hey we can consolidate all of these 200 1 mb into one 256 mb slab. so if you read further in the article it lets you know that if the drive is thinly provisioned, then yes it will reduce the actual storage space you are using and I would guess trim your bill. if it is fixed, then no your bill would remain the same since you are reserving a fixed amount of space. I would leave it alone and ignore the errors. if your drive gets out of whack then the errors go away and the defrag takes care of it. I do not know about you but I have enough head aches in my life without trying to monitor drive configuration. if you are hard core into squeezing every nanosecond out of the drives then feel free to do it. This is just my two cents.

Add Your Comment