I finally have my phone replaced under warranty. As promised, I’m posting old / new comparison photos:

Here’s the gap measurements on the newly arrived phone. I’m not sure if this change will make a difference in dust entrance. I will continue to report. See the photo from the older phone right after this below to compare. Strangely gap between glass & plastic appears to be wider on the new phone, but the gap between yellow casing and the black plastic part is much less.

Below is the photo I took today on the old phone from the same angle. You can tell it’s the old one by looking at the dust accumulated on the front-facing camera.

[Original post below]

Like some other early 920 adopters, I have hit the proximity sensor problem. I’m referring to the issue where proximity sensor area takes dust and the phone refuses to bring the screen on while in a call, preventing to touch even the End Call button. Very annoying and show-stopper class problem. People, including me, have temporarily fixed the issue by blowing compressed air into the front facing camera area – but it comes back as more dust gets in over just a few more days…

Anyway.. The reason for this post is to actually show you bunch of microscope pictures to show why it happens and whether your 920 could also be susceptible to the problem – if you know where to look, maybe you can tell without a microscope. So before I replaced my phone, I took some pictures. Here we go:

First one is a close-up front-facing-camera that shows how dust have gone inside. I know it’s inside because as you can see around the camera, it’s quite clean, unscratched blackness after a good wipe. Keep reading…

Next up is the first look at the “rift”… Below, to help you with frame of reference, I left one lint on the upper right and kept the front facing camera on the lower left. What you will later see in greater detail here is that the section where yellow ends and black begins, there is a rift going deep, perhaps a millimeter or more. I will do my best to capture this. Keep reading..

Below, is a clarification on something. When you look with naked eye, you might think that the rift is only in the area where the yellow case shape is different (i.e. see the corner in the middle of the picture where the left-side of the rift appears wider?).. Well.. Turns out the rift goes on the entire upper section of the phone. The wider area is about 10-12mm in length and is probably contributing to the dust accumulation problem – but rift is open from the left edge of the phone to the right. Keep reading…

This next picture is more telling. Microscopes have very limited depth of field, so where you focus makes big difference. I attempted to focus to the floor of the rift where there are pile of dusts. Camera is slightly angled, looking from near-center of the phone towards upper area of the phone to catch the wall of the rift going deep. Shadowed yellow casing wall going deep to the floor is visible below. Once you see this you understand it’s no surprise dust is getting there. The top touchable surface of the phone is out of focus because I am focusing on the deeper floor of the rift.

Here, a bit closer look at the floor of the dusty rift…

So that’s it. Unfortunately this problem is impacting my phone and I’ll be returning it for a replacement one.

Now.. To compare other edges, I have below a photo of the bottom edge of the phone where there is absolutely no rift. Black edging sits on top of yellow case. This is how upper side should have been.

While I had the phone under microscope, here’s a bonus picture of rear-facing camera that remained pretty clean so far. Dust is not getting inside. Those few small dots you see are on the outer surface, as are the tiny scratches.

That’s it. When I get my replacement phone I’ll take more shots to see if the new phone is different. Stay tuned.

Anyway.. The reason for this post is to actually show you bunch of microscope pictures to show why it happens and whether your 920 could also be susceptible to the problem – if you know where to look, maybe you can tell without a microscope. So before I replaced my phone, I took some pictures. Here we go:

First one is a close-up front-facing-camera that shows how dust have gone inside. I know it’s inside because as you can see around the camera, it’s quite clean, unscratched blackness after a good wipe. Keep reading…

Next up is the first look at the “rift”… Below, to help you with frame of reference, I left one lint on the upper right and kept the front facing camera on the lower left. What you will later see in greater detail here is that the section where yellow ends and black begins, there is a rift going deep, perhaps a millimeter or more. I will do my best to capture this. Keep reading..

Below, is a clarification on something. When you look with naked eye, you might think that the rift is only in the area where the yellow case shape is different (i.e. see the corner in the middle of the picture where the left-side of the rift appears wider?).. Well.. Turns out the rift goes on the entire upper section of the phone. The wider area is about 10-12mm in length and is probably contributing to the dust accumulation problem – but rift is open from the left edge of the phone to the right. Keep reading…

This next picture is more telling. Microscopes have very limited depth of field, so where you focus makes big difference. I attempted to focus to the floor of the rift where there are pile of dusts. Camera is slightly angled, looking from near-center of the phone towards upper area of the phone to catch the wall of the rift going deep. Shadowed yellow casing wall going deep to the floor is visible below. Once you see this you understand it’s no surprise dust is getting there. The top touchable surface of the phone is out of focus because I am focusing on the deeper floor of the rift.

Here, a bit closer look at the floor of the dusty rift…

So that’s it. Unfortunately this problem is impacting my phone and I’ll be returning it for a replacement one.

Now.. To compare other edges, I have below a photo of the bottom edge of the phone where there is absolutely no rift. Black edging sits on top of yellow case. This is how upper side should have been.

While I had the phone under microscope, here’s a bonus picture of rear-facing camera that remained pretty clean so far. Dust is not getting inside. Those few small dots you see are on the outer surface, as are the tiny scratches.

That’s it. When I get my replacement phone I’ll take more shots to see if the new phone is different. Stay tuned.

There are many uses for smartphones and some would benefit from a kickstand. The two scenarios that I’m targeting with this are:

• Dinner table toddler entertainment
• In-flight video/podcast viewing

I have been wanting to do this every time I needed to adjust the salt shaker to barely hold the phone in place until food arrives on a restaurant dinner table. Same thing when traveling as I always wish for a better way to place the phone while watching podcasts and movies.

Following were top of my mind when putting it together:

• Need to work with most phones. In our family, we have Nokia Lumia 800, 900 and 920 phones but I also wanted this to work universally with any phone.
• Portability. It needs to be convenient enough to throw into toddler’s bag or consultant’s backpack.
• Made out of generic and most common Lego parts for you to easily build one for yourself, and make additional ones if needed.
• Adjustable. Think of lower positioned toddlers around the dinner table. Video screen inclined at 30-45 degrees is not going to deliver best experience. Similarly, plane seats vary and adjustments will come handy.
• No obstruction of headset, power or button controls. For buttons, Nokia Lumia phones work out the way I liked but can’t guarantee how all others will behave. I expect it’ll be fine due to simplicity.

On the note of reliability… Because it’s made out of Lego, if a part separates after repeat use, you just fix it on the spot. If you want some permanent solution, simply glue them as you like. The way it is, I find it reliable enough to handle the situations I targeted.

I’ll show some close-up shots but this is how it looks “in the bag”

Below is how it looks when you open it. Opening instructions are dead-simple. Angle the legs apart as much as you like, raise the blue backrest as high as you need. Let me explain couple things here.

• The blue Lego piece is a part that comes in different types. This is one that has the red insert on rotation axis (see the arrow on the right) and it requires a bit of force to adjust. Alternatively, there are similar looking parts that essentially opens/closes effortlessly. Obviously that one will not hold the phone in place. This is critical dependency that I couldn’t solve the adjustability requirement any other way than use this specific part.
• The arrow on the left is the second rotating element. I made it yellow in this photo so you can relate to what part it is in subsequent photos. Very common and easy to get.
• Finally, the height of the elements that hold the phone in front, marked with the red curly bracket on the right. This is very easy to adjust to your liking but in my case I wanted absolutely minimal height that would still hold the phone at an angle without obstructing the view for a low-sitting toddler.

Below, I separated it into two so you see the yellow part. Normally you wouldn’t separate them – it just rotates on the yellow part to collapse for traveling. I increased the brightness so you see the details on black parts better.

One last detail shot and then I’ll show it in-action:

Below are the kickstand in-action shots. I want to show two extreme cases of adjustability. First, you see near-vertical alignment for a low-sitting toddler…

…and more traditionally angled standing for in-flight video viewing:

If you pay attention to the angled front photo I just showed you (last row above, left), and compare to the first photo at the very top of this post (left), you’ll see that the legs of the stand are positioned at different angles. Let me comment on this a bit:

The yellow rotating Lego part has no friction. So the most force that’s preventing legs of the stand opening completely is the phone’s weight and consequently leg’s friction on the surface it has been put on. Testing showed that on slippery surfaces like wood desk or glass table, smaller angle legs work better (last row of photos, left). On a cloth or paper surfaces, you can open them as wide as you like (first row at the very top, left). In either case angle of the phone is determined by the blue Lego piece so you can let it stand however you like. You can further improvise on friction by adding rubber pieces to the bottom of the legs and they will almost stick to the surface. In my case I’m not using them with rubbers.

Check my blog for charging docks like Lumia 900 and let me know if you can improve on this idea further. Thanks for visiting.

ThinkPad X1 Carbon

• The model I have been able to borrow does NOT have touch; if rumors are to be believed, the touch display will be IPS. The display on this one is exactly the same as that of T430s, which shows the grids and also I find myself constantly adjusting the angle.
  
• Overall display has high brightness that can be adjusted with sufficient granularity. However, if you have good eyes you will see the black lines that I think is called “screen door effect”. I have a microscope shot later to show what I mean.
  
• I like the overall form factor. Very thin. Feels “dense” and solid.
  
• Bezel is not as thick relative to T430s, which is nice.
  
• No heat or hot blow issues. Completely silent and cool on normal web surfing / emailing.
  
• Not that I care much but you cannot lift the lid with a single finger and open. You must hold the bottom portion down.
  
• Only hesitations are compromises: non-standard power plug; irreplaceable battery (can’t have a spare or use some bay for more juice), no built-in Ethernet port, no built-in VGA for presentation/projector scenarios.
  

Here some details:

Display

Resolution: 1600×900

Screen door effect that I mentioned can be seen in below microscope shots. On the right is a comparison photo of the display of my ThinkPad W500.

You can see above how the T430s and X1 Carbon (non-touch) 1600×900 displays have proportionally much higher always-black horizontal lines. This may not bother many people but I saw it immediately and had to dig deeper. Difference with W500 is quite clear. Despite the better contrast, everywhere white on the screen has these black grids that annoy me.

Speakers

I’d say speakers are OK. Doesn’t have anything good or bad to call out.

Keyboard

I was skeptical about these island style keys but I can type fast. Clicks are quiet, I like the backlight with the exception that from a low angle you can see the bright LEDs from under function keys.

Battery

It appears to charge fast and last quite a bit. I have not had a chance to do accurate measurements but after about 2 hours of light use, indicator dropped to 79%

Resume from standby performance

System turns on quicker than you can open the lid. No issues here. Very fast.

Cold boot observations

22 seconds from cold start, ctrl-alt-del to logon, including me typing a password and reaching to Windows 8 start screen.

It reaches to password prompt in about 15-16 seconds. Easily 3-5 seconds are spent in POST ThinkPad logo screen. Not sure what it’s doing there. TPM/BitLocker comes to mind but not sure.

Heat/Noise

System is absolutely silent. Upon 30-40 minute constant on-lap typing and web browsing, I didn’t feel uncomfortable or heat anywhere. To be clear, it wasn’t hot to legs, it wasn’t hot to hands. I like it.

ThinkPad T430s

Well… To be honest, this was the most surprising one for me. “T” series is flagship of ThinkPad and I wasn’t expecting the issues I’m noting below:

• Fan noise. Yes, this T430s is noisier than my W500. CPU is idle. Power not plugged in. Fully patched. Didn’t investigate anything about power profiles of ThinkPad. Fan is audible and blows hot (hotter than W500 when idle).
  
  • System SKU is 2352CTO – though this may be specific to our corporate purchase SKUs and may not be available directly.
    
• Display is very bright; but has screen door effect (as mentioned earlier on X1 Carbon). W500 by comparison is yellow by now (probably age) but the grid-showing problem definitely does NOT exist in W500. Display in T430s is not IPS (not a surprise; but at this day and age, really was hoping for something better from Lenovo).
  
• Thick bezel. Feels like they could put 1.5″ larger display in this case. It is a very thick, ugly black bezel all around — doesn’t make much sense to me.
  

So overall I’m disappointed in T430s.

Keyboard is good; same as X1 Carbon

Battery is replaceable although I haven’t measured battery life. It does have the slim optical bay, not sure if there is a battery accessory that slim but worst case spare battery will save you. X1 Carbon doesn’t have that option.

Conclusion

Because of the display issue, I will wait to see X1 Carbon Touch which is rumored to have IPS display. If I get hold of one I’ll update this post.

On this next screen it may take extended amount of time especially if your server is busy. Be patient.

Installation complete with the following message:

When this add-in is installed, you will see the following “Online Backup” option in the Dashboard:

Next, click on “Register” in Step-1. Provide the credentials you had created earlier.

After clicking next, there is a very important “Passphrase” entry screen. This is just as important your account password. In fact, it’s more important because password can be reset/recovered but not the passphrase that is used to encrypt your data.

After a brief wait in this screen:

You get the following message:

At this point we can configure the backup. Click on “Configure Online Backup” and choose the folders, as in:

Then configure the backup schedule. Note you can have multiple backups per day. I personally don’t need it.

Next screen shows how long you can keep your backups. Maximum appears to be 30 days, which is a bit low. I will need to investigate if this is individual backup-days (i.e. if I backup only on Sunday, can I keep 30 Sundays) or is it really a calendar month.

Add-in also supports bandwidth scheduling and throttling, as in:

When configured, it looks like this:

It would appear that first backup will be taken at 11pm according to the schedule I had set. For the sake of testing, I will click on “Start Backup Now” link.

Depending on how large the volumes are, you will see Backup status showing “Creating snapshots” – this phase can take a while. After that, it’ll move to the following:

..and then shortly after:

So let’s take a look at the transfer rate:

Largely stable, close to saturating all outbound bandwidth that I have at home (about 5Mbits up .vs. 3.5-4Mbit that it’s utilizing now). You have the process name and the chart that shows the last 60 seconds of the transfer. There is no other significant network activity on this server.

Other observations… While the backup is taking place, I noticed the following disk appear (circled):

This is the result of a volume level snapshot that is taking place every time a backup job runs. It goes away when backup job is completed. Do not touch it.

That’s it – those selected folders are now protected in Azure. I will update this post with some restore experiences when I get a chance.

I have constructed a disk configuration of any disk I can get hold of; from 5400RPM 2TB SATA to even a lowly laptop drive, all bundled in a single pool. From this pool I carved out two thin provisioned volumes, one two-way mirrored, one parity. It looks like this:

For those who want to know, here’s the specifics of each disk. Go look-up on the net for the model numbers for details on each disk if you like.

I then created one ReFS volume within each. Note that I have disabled the FileIntegrity feature of ReFS using the following command. I did this for both volumes I created. When you disable it at the root, all underlying files/folders created after this setting will have the FileIntegrity bit disabled. This can be enabled/disabled at the file level at any time.

• “set-FileIntegrity -Filename D:\ -enable $false”
• “set-FileIntegrity -Filename E:\ -enable $false”

Note that I will enable this later and see what kind of impact it will have on the system. For now, volumes are looking like this:

I then fired up PassMark v8 and custom-configured the disk test profile. I configured two threads going simultaneously for D and E drives at the same time for 120 seconds. I used PassMark’s standard File Server profile, which calls for a 500MB test file.

Before you ask, thin provisioned system and a test like this has some quirks to handle. First time you run this test, allocation of thinly provisioned volume will have to be built from scratch, so it’s not fair to the test scenario to absorb that sort of overhead. For that reason I ran it once completely, then ran for the second and even third time. I verified that allocation size of the virtual disks are no longer growing as I run the tests, meaning, we’re operating on the white space of the thinly provisioned volumes. This is more typical of a performance we’d get from a file server.

So here’s the initial output that I’ll share with you. As you might notice, D: drive is the turtle and E: drive is the rabbit. Pay attention to the lower “Status” section and MB/Sec column. See how low the parity protected disk is in comparison?

(Keep reading after the image)

You should NOT draw conclusions about absolute performance numbers out of my tests. My disks and the system are very old; however, in relative comparison of mirror and parity, this test should be valid.

I will now repeat the same thing with one disk at a time. After all, these disks are hosted on a single Storage Pool, meaning they are competing for resources when they are active simultaneously.

Now the question is, will they deliver similar MB/Sec figures when the test is run one-at-a-time. Here’s the test against D: drive (Parity)

Before you draw any conclusions, let’s check how E: drive (mirror) will perform:

As you can see, difference is not as drastic compared to the test pass where both drives were hit simultaneously. Perhaps this tells us that performance of a parity protected disk degrades much quickly if there are competing IO requests against the system, and less so with mirror protected disks.

Even in a best case comparison scenario, mirrored disks appear to be about 70% faster than parity disks under PassMark’s file server benchmark profile.

All of the above is caching=OFF and this is the default configuration of the standard File Server benchmark profile. Just to see what happens, I turned caching on. Here’s what E: drive could do. Keep in mind, the server has 8GB of available memory. So 500MB file is coming directly from memory.

As promised, I’ll enable now FileIntegrity in ReFS (which is default behavior) and see the impact it will have on the tests. It is enabled like this:

• “set-FileIntegrity -Filename D:\ -enable $true”
• “set-FileIntegrity -Filename E:\ -enable $true”

Here’s the uncached run (same as I had done earlier for E: drive – mirrored one). 16MB/sec value dropped to 1.3MB/sec. This is quite bad.

Let’s see how D: drive will perform. Remember, D is the one with parity protection.

FileIntegrity bit has quite an impact on random IO workloads. Let’s check how things go when both volumes are hit at the same time:

Next, let’s test how NTFS will behave. Same tests, this time disks are formatted with NTFS.

Simultaneous run:

Parity drive alone:

Mirror drive alone:

In conclusion, here are the comparison chart. Do NOT look at absolute numbers. Look at relative changes in varying settings. Values are in MB/Sec.

Given the general purpose nature of my workloads, I’ll be using NTFS.

• Part 1: Introduction and Lab Environment Preparation
• Part 2
• Physical Disk Pull
• Introduce the Pulled Disk Back into the System
• Part 3
• Extend Thinly Provisioned Virtual Disk and Observe Behavior at Limits
• Bonus: Detecting and Replacing Physical Disk Failures
• Part 4
• Removing a Disk from the Storage Pool
• Part 5
• Reclaim Unused Space on Thin Provisioned Disks
• Bonus: Defragmentation Attempt and Observations
• Part 6
• Understanding Hot-Spare Behavior
• Part 7
• Part 8 (You’re here)
• Repurposing Disks from other Servers

Repurposing Disks from other Servers

In my continued attempt to discover intricate operational details of Storage Spaces, I wanted to experiment with shuffling disks between systems and see what behavior I get.

Here’s how things are now:

I have performed the following:

Action: Remove 92GB drive. Insert 1 x 1.5TB, 1 x 750GB and 1 x 2TB disks (total 3). Keep in mind, the 92GB disk was part of the TestSP1 pool that is parity protected. Here’s the result:

What’s interesting above is that I do not see my three new disks. They were dynamic disks and were in use in another Windows Server prior to bringing here. Health degradation is expected of course, since one of the disks in the pool with parity protection is now gone.

I also see heavy disk activity. I can’t explain what this is – for now.

One idea maybe that system is “healing” the virtual disks by re-generating the parity that was lost on the missing drive. However, status of virtual disks are not indicating any repair in progress. As in:

How about physical disks? The UI shows us this:

Where are those three disks that I have added to the system? Let’s try Powershell instead:

What do you know… They do show up in “get-physicalDisk” command. Strange.

What’s even more strange is the duplications in FriendlyName values. If you note in above screenshot, those showing with 698GB, 1.36TB and 1.82TB are the disks that I have just added. They physicalDisks 2, 4 and 5. But look at the 2nd line. The disk with 278.75GB capacity is also called PhysicalDisk5. I will investigate what’s going on here some more.

Let’s look at Disk Management UI and see what it’s showing:

In above screenshot; finally I can see the disks I have just added. They arrive in offline mode.

Only one way to find out what’s in them. I will attempt to bring them online. I do this by individually doing a right-click on each disk and choose “Online” command.

Ok, now they’re reporting as foreign but accessible. Let me do “Import Foreign Disk” on one of these disks and see what happens. When I execute that command, following dialog popped up. The dialog contained the volumes that these disks were part of.

It’s also warning me that I had not brought in all the disks that comprised those previous volumes. At this point I don’t care about data loss but this is the experience you’d have if we you were moving a group of dynamic disks to another system. I clicked “Yes” on the dialog above.

Now I see the remnants of the volumes from previous life of these disks. I shall clean them up. Simply right-click on each failed volume and delete.

At this point I should check the PowerShell and see if anything is different.

Sure enough, “CanPool” column value has changed for those three disks. “Pool” name indicates that this might also be reflected in Storage Pools, quick refresh on the Server Manager UI shows following update:

Now we’ve got Storage Spaces to recognize those disks.

So what did we observe?

• If you bring dynamic disks from another system, you do need to use Disk Management console or diskpart to clean them up. Otherwise Storage Spaces management UI doesn’t show anything about them.
• Physical disk names can be duplicate on the same system. This is very strange – not sure what to make of this or what the implications might be.
• When a disk of an active pool is removed, remaining disks are trashing with no end in sight. I can’t explain why this is happening but the activity does NOT appear to be self-healing or hot-spare activation.

At this point I’m very curious about the disk name duplication, I will proceed to add that new disk5 to the pool and see what happens.

The system doesn’t complain. It can happily have same-name disks in the same pool. Difficulty with this behavior is that if you’ve got same-size disks and if they all named the same, how will you, without “disk light enable” support, be able to determine which disk is which? Say you need to replace a failed disk. It’d be interesting exercise to find out which disk is mapped to which physical/actual disk in the enclosure.

So let’s investigate that.

If you right-click on one of the physical disks and choose “Properties”, you get the following dialog:

As you can see this shows the serial number, which is unique for each physical disk. You could read up your physical disk serials in the enclosure and replace the one that matches the failed disk’s serial number. In real world this is probably an offline operation if your gear doesn’t support “Toggle drive light” operation. Reason being that if you start pulling disks while hot, you’ll cause data outage on 2nd disk that you pull in sequence. If you however shutdown the array and then pull one by one and read the serial number, you’ll be able to safely replace it and power the system back on.

That’s it. Hopefully this post helps save you some time on moving disks between systems.

• Part 1: Introduction and Lab Environment Preparation
• Part 2
  • Physical Disk Pull
  • Introduce the Pulled Disk Back into the System
• Part 3
  • Extend Thinly Provisioned Virtual Disk and Observe Behavior at Limits
  • Bonus: Detecting and Replacing Physical Disk Failures
• Part 4
  • Removing a Disk from the Storage Pool
• Part 5
  • Reclaim Unused Space on Thin Provisioned Disks
  • Bonus: Defragmentation Attempt and Observations
• Part 6
  • Understanding Hot-Spare Behavior
• Part 7 (You’re here) 
  • Evaluating and Enabling Data Deduplication

Evaluating and Enabling Data Deduplication

Let me start by showing you what I have in terms of virtual disks and volume(s) within:

For the moment, my virtual disks are not Deduplication enabled, as seen in:

Before blindly enabling DeDuplication, we might want to assess the contents of the NTFS volumes that live inside these virtual disks. You see how I worded it btw? Deduplication is enabled on a “virtual disk” basis, yet there could be multiple volumes (NTFS etc) within each. First lesson is that deduplication is operating at the disk level, not at the volume level.

Now, here’s how we can assess a “volume” for deduplication. Name of the utility is “DDPEval.Exe”. Depending on the size of the volume being evaluated, it may take extended amount of time. Below, I’m showing you the resource monitor view as well while DDPEval is working.

When done, DDPEval produces an output like this:

If you noticed, it is reporting that space savings will be 99%. But why is this? Let’s take a look at the files on this volume E:

That’s all of it in my test scenario. So how come 99% of these can be saved?… Well, that’s the beauty of deduplication feature in Windows Server 2012. It works below the file system, so even the repetitions inside the same file can be optimized. My files above happens to have all “a” characters in them.

Anyway, now that we have done our assessment, let’s proceed to enable it and see what happens. There is a way to do this in the graphical interface in Server Manager, here:

Wizard looks like below. “Enable” box was unchecked, so I checked it as below:

At this point I’ll proceed with default values. You see the “Set Deduplication Schedule” button above? Here what comes up if you click that:

There are two separate schedules offered here. This would help with scenarios like more aggressive optimization during weekends .vs. shortened one for regular weekdays. For the moment, I will only enable background optimization because I can control when/how idle the volume is and I’ll be able to report to you when it actually kicks in on its own, if ever.

So I clicked OK on the above dialog.

When I did that, following service started:

I can look at the status of deduplication on any of my volumes where deduplication is enabled using the “Get-DedupStatus” command, as in:

<I’ll wait for 30 minutes to see if idle detection timer kick in and do some optimizations>

As you can see, nothing happened on its own. I will inquire as to what specific algorithm is used to determine idle behavior and provide an update if I find anything relevant.

Meanwhile, let’s force it to optimize. Like this:

Hmm.. that happened too quickly – and as you can see, nothing has actually happened. We must be operating below the levels of amount of duplications for system to care… or maybe I’m using the wrong set of command parameters.

My D: volume is much larger, so let me enable deduplication on it. Since you have seen the graphical method above, I’ll show the PowerShell method this time:

This time I decided to test if actually scheduling an optimization would make a difference. So I went to the “Properties” of the volume, clicked on “Set deduplication schedule” button and reached to the following dialog.

What’s interesting here is that the dialog, although it has been accessed from the properties of an individual volume, is referring to the server name. From here we gather that deduplication schedule operates at entire server level. On one hand we can set 2 separate schedules for it to run, on the other hand, it will run against all volumes where deduplication is enabled. Keep this in mind.

After configuring it through the UI, I got to the above position. It was about 5:06pm at the time I configured it to run at 5:08pm

Sure enough, at 5:08pm, the disk activity began. Get-DedupJob is now showing the following:

There are three things I want to explain in above screenshot. First, as soon as time hit 5:08pm, both volume optimization processes kicked in at the same time (parallel) and changed to “Running” state. This parallelism maybe a good thing or a bad thing. I know that optimization activities can be targeted at individual volumes, but perhaps not through the schedule set on graphical interface.

Second, after waiting just a short while (less than 2-3 minutes), E: drive was done. Remember E: drive has 11GB of content with 8GB was showing as recoverable per DDPEval.exe. Despite DDPEval’s estimate no actual bytes were recovered. This may be because we’re flying low on minimum thresholds that deduplication engine is designed to work with. I will research and update this write-up later.

Third, volume D has been going on for a while. After about 4 minutes, it saved “1.34GB” and continuing to run. Disk activity is heavy right now. I’ll wait until it makes more progress and then will report. Pretty much everything on this disk is a duplicate, so I expect a good amount of data footprint reduction.

<wait until optimization finishes>

You see above the finished optimization pass. Level of space saving is indicative of nothing because my test files were simply full of character “a”s in them. Regardless we were able to experience the end-to-end process. Let’s take a look at how Server Manager showing things now:

Although there are multiple places where the deduplication savings are displayed, I am showing the Volumes Overview.

Let’s recap where we are and what we learnt:

• We have established that disk deduplication operates below file level, and can achieve savings even if repetitions are inside the same file. (I should check if duplications across different volumes of the same disk benefit from the deduplication)
• Deduplication runs on a set schedule or as a background task. Simple experimentation showed that what I think “idle” may not be enough for system to kick things off. Until I learn exactly how background optimization kicks in, I will use scheduled optimization.
• Deduplication schedule applies to the service and scheduled optimizations launch simultaneously against the entire server. This may be the behavior of the graphical interface though; because it appears to be possible to launch volume-specific optimizations individually.
• Because this concept is important, let me re-state what I just said. Disk deduplication operates at the disk layer (below file system like NTFS), however called against individual volumes and out of the box scheduled jobs run against entire server.
• There is a threshold that I do not know, that must be crossed before optimization pass actually does anything. Our volume E: experimentation above is a demonstration of this. Implication is that, on very small volumes, even if DDPEval.exe reports space to be gained, it may not be possible to do so. If anyone knows the specific threshold, please drop me a note.

That’s it for the disk deduplication feature review.

Overall I don’t consider my phone scratched much (despite what you might think after looking at the pictures J). Cyan casing itself is holding up really nice. I’ll be showing you the only dent it has from falling.

So first picture is the corner where the headphone socket is. Phone dropped from shoulder height onto asphalt while exiting a car. Keep reading after…

Zooming into the “crater” you can see the tiny pieces of dirt that were able to penetrate the cyan casing. The case is cyan through and through alright; but dent being the dent and impact being to asphalt, it did collect some particles. Entire crater is smaller than the top of a needle, and this “dirt” is barely noticeable.

Ok… moving onto camera lens / below. Keep in mind, the inner glass (not the black-looking-but-actually-silver lining between cyan case and glass) is actually positioned deep. When touched under microscope, I can see it moving around with the push of my finger independent of the lining.

By holding the phone in my hand, I don’t see much dirt or scratches on the glass. However, it’s a different story under microscope. At this point I also started to believe that every one of those really close-up phone/gear photos we see in product marketing materials are rendered. There are just way too many small things going around to keep them pitch-perfect clean. Below image was taken after a good wipe. I am speculating that you’re looking at remains of my dead skin around the glass. At best they are little dust particles from the wipe I used. The lens element is positioned deeper than the silver lining around, so it’s hard to reach to the edges of the glass where you see little dust particles.

As for the silver lining around the glass element. It does come into contact with surfaces when you put the phone down face-up, and naturally gets most of the scratching in the back. Keep reading.

To give you another perspective, here, a photo of “T” in word Tessar 2.2/2.8. Also worth noting that microscope’s own light is coming at an angle and is quite powerful. Phone must have easily been put down 3000+ times over the course of 6-7 months. It’s always with me, always placed face-up on a table somewhere. Sometimes it’s concrete, sometimes wooden desk. I rarely keep it in pocket while sitting.

I’ll let you guess what these below are. Mind you, depth of field in photos like this changes everything. There is a protective cover on which there are dust particles. I decided to focus on what’s underneath. This also tells you how unimportant those dust particles in front of the camera lens above are. Camera will be focusing to objects far away – few dust particles will only change the amount of light coming in by a certain percentage. But that’s about all the impact it will have.

You know there is a protective edge around the display of Lumia 900, so you can safely put the phone face-down. On a flat surface display doesn’t touch down thanks to this feature. What you’re seeing below is me holding the phone vertically under the microscope, focusing on the edge. In the background (supposed to be white) you are seeing the microscope’s white plate. Horizontally, upper half of the black line is actually mirror image of the edge reflecting of off Lumia’s display. I wanted to include this to show you the texture of that barely recognizable edging.

Next one is classic – but I wanted to include it anyway. You’re looking at a portion of letter “O” of Outlook on the main display of Lumia 900. Exposure time here was something like 20 seconds at ISO 100 with no external light.

That’s it. I like the material Nokia used in Lumia line. It is holding up nicely – despite repeat falls and me not using any additional case, it scratched only on extreme situations. I would say that the metal element in the back needs better protection. It perhaps shouldn’t have been the lowest point of the camera when placed face-up. Looking forward to 920 and 820 models soon.

• Part 1: Introduction and Lab Environment Preparation
  
• Part 2
  
  • Physical Disk Pull
    
  • Introduce the Pulled Disk Back into the System
    
• Part 3
  
  • Extend Thinly Provisioned Virtual Disk and Observe Behavior at Limits
    
  • Bonus: Detecting and Replacing Physical Disk Failures
    
• Part 4
  
  • Removing a Disk from the Storage Pool
    
• Part 5
  
  • Reclaim Unused Space on Thin Provisioned Disks
    
  • Bonus: Defragmentation Attempt and Observations
    
• Part 6 (You’re here)
  
  • Understanding Hot-Spare Behavior
    
• Part 7
  
  • Evaluating and Enabling Data Deduplication
    

Understanding Hot-Spare Behavior

Let’s take a look at hot-spare feature in Storage Spaces. Most of the storage administrators have experience with array controllers and SAN/NAS devices, and accustomed to a certain behavior with hot-spares. My curiosity is around how similar the hot-spare functionality in Windows Server 2012 relative to traditional hot-spare. For example, will it automatically become active? What will happen to the disk that it replaced? Keep reading to see as I experiment with this.

Here’s where we were last time in Part 5:

I’m going to add 5^th disk as hot-spare. Here’s how it’s done:

…adding the disk takes just a second. Then you see the hot-spare disk like below:

Before we go any further, keep in mind this very important terminology distinction. The disks are added to the Storage Pool object, not to “virtual disks”. You carve out virtual disks out of storage pools. In my example, there is only one virtual disk. However, to continue my tests, I will create another virtual disk – just to ensure you fully understand disks are part of the pool, not the virtual disk. In other words, spare could serve any of the virtual disks within. They are not assigned to individual virtual disks.

For that reason, here’s our TestVirtualDisk2, also thin provisioned and parity protected. I also created an NTFS volume within, loaded some data on it as well. Here’s how things look like now. Look at the Allocated column on each disk as well. This is a great example of how we can over-subscribe the underlying storage.

Something else worth noting. In the pool, I have 4 disks with usage attribute set to “Automatic”. I copied just one 8GB file to E: volume (hosted on TestVirtualDisk2 that I just created). It ended up getting distributed across all disks. Through experimentation in earlier parts of this blog post, we had seen that pool was distributing the data among multiple disks, and it’s surely expected behavior – however, we didn’t know if it was spreading the data over as many disks as it has at the time, .vs. just 3. It is now confirmed that all disks are being utilized, which is very good and consistent with other storage solutions out there.

Ok – time has come to test how this hot-spare works. I will go ahead and remove one of the disks. I will do this by physically pulling it out. As a reminder, neither my disks nor my eSATA enclosure support hot-swap; therefore this is truly fatal operation that I normally wouldn’t do. That said, purpose is to simulate the loss of a disk – therefore it’s real-enough.

One of the difficulties here is matching physical disks to the disks you see in the management console. In a large disk set, this could be seriously challenging task that you really cannot afford to make a mistake. For this reason, Storage Spaces management console gives you “Toggle Disk Light” option when you right-click on any physical disk. However, your controller and disks need to support that feature. Sadly, my test gear doesn’t support it:

At any rate,… I’m proceeding to just pull the disk.

Action: Physically remove PhysicalDisk5 from the eSATA enclosure.

After I removed the disk, and after I refresh the management console UI, here’s what I see.

So normally hot-spare means “hot” spare. So it should have kicked-in. But so far as I can see, it has not. Data is still available, however each virtual disk is in degraded state (because both of them had data on Disk5). None of the physical disks are doing anything right now. They are happily idling away.

I would have expected hot-spare to kick-in and system to bring everything to healthy state on its own. But this is not happening.

After some research, here’s what I found. Let’s take a look at the properties of my storage pool. Pay special attention to current “degraded” status and the default setting of “Auto” on the “RetireMissingPhysicalDisks” property.

Here’s the behavior of RetireMissingPhysicalDisks under various settings:

• Enabled:        If just a disk is missing, meaning its enclosure is still present, then treat the missing disk as failed.
  
• Disabled:    When a disk is missing, wait for either the disk to reconnect or for admin action.
  
• Auto:        If the pool has a hot spare, then follow the Enabled logic.  Otherwise, follow the Disabled logic.
  

Since we have “hot-spare” in the pool, it should behave as if it’s set to “Enabled”. But it’s not doing that.

More research and more findings:

• Storage Spaces will wait for 5 minutes before taking any action on the hot-spare disk. In my case, we’re past 5 minutes already and nothing is happening.
  
• Storage Spaces will not do anything unless there is a write failure. Who knows maybe this is why…
  

Let me attempt to save a file onto one of those disks and see what happens:

Action: Copy some 4GB worth of files to TestVolume2 (E:)

Nope. There is nothing written to the hot-spare disk. Usage designation of the disk hasn’t changed immediately either. But let me see if 5 minute count is starting after I made a write attempt… So I’ll wait a little.

<5 mins later>

Sure enough, physical disk LEDs have gone crazy. Something is finally happening, let’s check the Usage designations of the disks. Remember, PhysicalDisk4 was set as hot-spare (see earlier screenshots above)

Finally, Windows decided to change hot-spare disk to Automatic, and apparently initiated a repair. But there is something very interesting going on here. The repair activity was only for the disk where I have made the write request on (TestVirtualDisk2).

After waiting just a short while, disk activity has ended – everything is seemingly idle and look at where we are:

Apparently it repaired only the disk where I had a write operation.

If what I’m observing is true, a read-only NTFS volume (think file share for distribution of deployment packages) might not be able to benefit from hot-spare and could be vulnerable to loss of another disk. The possibility that this is not happening automatically is concerning. So I’ll attempt to write something to that drive D: and see if auto-repair kicks in then.

Action: Copy a tiny file to drive D (which sits on TestVirtualDisk1)

Time: 4:48pm

<nothing is happening for now. Will wait>

Time: 4:52pm

<nothing is happening for now. Will wait some more>

Time: 4:55pm

Nothing happened.

So even if I write something to the drive, auto-repair is not kicking in. This is strange. Maybe the size of the file matters for some reason. Let me copy a large file.

Action: Copy 8GB file to drive D:

After file copy operation finished, disk activity is continuing – I’m assuming some sort of repair is in progress. Strange that a small file write didn’t trigger this; whereas a big one seemingly did. Here how things look like:

More importantly, the allocation of TestVirtualDisk1

Couple things to note here. Physical disk activity is very heavily going on right now. Health status, as can be seen from above, is still “Warning”. Also, missing disk is not showing as allocated, whereas Disk4 is now showing as being used. Strangely, allocation level of Disk4 is very high. It has only been about 15-20minutes, and free space is down to 19.8GB. It would appear to me that the repair process is promptly reserving final footprint as “used” on the physical disk and then filling it in. Interesting.

I have not done anything with the “missing disk”. It’s still showing missing. I will play with it (such as insert it back after a while, as well as attempt to re-purpose – stay tuned for those).

For now, I’m waiting for repair process to complete. Due to data set on this disk, I expect it to take several hours.

<Several hours later>

Repair has been completed and the virtual disk is reporting healthy. At this point pool can lose another disk and still maintain data integrity.

So what did we learn thus far?

• Hot-spare drive, unlike on traditional SAN/NAS systems, does NOT get activated as soon as a failure is logged. Rather, it happens 5 minutes after a write operation is made to any of the volumes inside a virtual disk. If a virtual disk does not have any volume that receives write activity, it does not get repaired and remains in degraded state. Bottom-line: If you’ll use hot-spare, trust it only if you have continuous read/write activity to at least one volume in each of your virtual disks. Otherwise, you will need to monitor the logs constantly and raise alerts for an administrator to perform the change. For an admin-initiated operation, following has to occur:
  
  • Change Usage property of the hot-spare disk to “Automatic”
    
  • Initiate “Repair” on each of the virtual disks that are in degraded state.
    

Next, we want to see what happens when the missing disk is made available back to the system again.

Action: Insert the previously removed disk back in (PhysicalDisk5) and reboot the computer (I do reboot on re-inserts not because it’s a must but because my eSATA enclosure doesn’t officially support hot-swap. It’s OK to pull a disk to properly simulate a failure but opposite is not a good practice)

Disk showed up and maintained “Retired” status. Compare below screen with the one above. Because it’s set to Retired, we know from earlier parts of this blog, that it will never be used for write operations.

At this point I want to mark that disk (PhysicalDisk5) as hot-spare. I could not find a way change “Usage” property from the user interface. So this is what I did instead:

Quick refresh on Server Manager UI shows that the change has been reflected properly. (Compare with above where Usage is showing Retired)

That’s all I have for hot-spare feature. My conclusion of hot-spare feature is this:

• New, useful feature that works slightly differently from traditional storage systems.
  
• Allows flexibility in that you could potentially leverage a hot-spare that is different in size than the other disks in the pool.
  
• Hot-spare services multiple virtual disks. Read this one more time. Not every storage solution allows you to use a single spare disk to potentially service any of the arrays. Often times you are required to assign dedicated spares to each. Windows Server 2012 allows you to build parity, mirror or no protection virtual disks across varying size of physical disks, allows you to assign any size disk or disks as hot-spare. Nice flexibility that I have not seen at this cost level personally.
  
• It does require administrators to learn it properly. The behavior that cause hot-spare(s) to not auto-activate due to lack of write requests, could catch someone by surprise. Experiment with it and learn how it works.
  

Next up, we will look at Disk Deduplication. Read it on Part 7