February 25, 2015 at 11:37 am
Has anyone seen this error?
I received it when attempting to run defrag analysis (defrag S: -a -v) on a 64K file allocation size configured SAN disk. My sysadmin is telling me that his testing resulted in the error unless he used a 4k file allocation size.
This seems to be an issue with file allocation sizes > 4K on Windows Server 2012 R2. Can anyone confirm?
All I was able to find that seemed related on the interwebs was this:
http://blogs.msdn.com/b/clustering/archive/2014/01/02/10486462.aspx
February 26, 2015 at 12:26 am
Is this a windows server failover cluster?
Are you using cluster shared volumes?
Can you provide more detail around this particular volume itself, I.e. How it was formatted, etc
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 26, 2015 at 9:07 am
Sorry the sysadmin set it up, not me. It is a cluster and it is NetApp SAN attached storage with a 64K file allocation size.
February 26, 2015 at 9:46 am
this looks pretty good and mentions netapp specifically
http://blogs.msdn.com/b/clustering/archive/2010/05/23/10015174.aspx?PageIndex=57
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 26, 2015 at 10:15 am
Thanks for looking, I previously read a similar article that had the same sort of reply, "Contact NetApp about OptimalUnmapGranularity".
I was hoping to see if anyone else had similar issues. What's weird is Windows native defrag chokes but Diskeeper 12 seems to work without issue.
Methinks it's a bug with windows disk defrag utility on 2012 R2 and 64-K file allocations. I'm hoping someone else has a similar setup and can test.
I'm checking with the sysadmin to see if the disks are thin provisioned, maybe there's something there...
February 26, 2015 at 10:23 am
slab and trim are more to do with the storage that sits underneath the volume, seems to be a storage system configuration issue
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 26, 2015 at 10:36 am
Well, well, well...
It works with PowerShell's Optimize-Volume, but not defrag.exe
Optimize-Volume -DriveLetter L -Analyze -Defrag -Verbose
(Drives are thin-provisioned)
February 26, 2015 at 10:57 am
February 26, 2015 at 11:05 am
Well, the plot thickens. defrag L: -v works, it's the analysis part (-a) that fails.
Optimize-Volume -DriveLetter L -Analyze -Defrag -Verbose is actually running defrag (-Defrag).
Optimize-Volume analysis only fails too (Optimize-Volume -DriveLetter L -Analyze -Verbose).
November 22, 2017 at 8:54 am
Did you happen to ever get it working via the GUI or just the through PowerShell? In the GUI, mine says 'Optimization not available' but can run it via the command you posted.
Optimize-Volume -DriveLetter L -Analyze -Defrag -Verbose
<the funny thing is that is just existing drives and when I add new 64K drives, they work just fine.
November 22, 2017 at 9:40 am
chad.fisette - Wednesday, November 22, 2017 8:54 AMDid you happen to ever get it working via the GUI or just the through PowerShell? In the GUI, mine says 'Optimization not available' but can run it via the command you posted.Optimize-Volume -DriveLetter L -Analyze -Defrag -Verbose
<the funny thing is that is just existing drives and when I add new 64K drives, they work just fine.
It's been a couple of years and I honestly don't remember 100%. I think it was an issue with the way the drives were mounted and that the sysadmin/storage team remounted the drives in order to get this to work.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply