BJJ

A few criticisms and notes:

Jon: Roll like there's two feet of water on the floor.  Roll less jerky, flow, let the jiu jitsu do what it wants.  Don't lay a web.

Me: Don't wait when someone passes your guard: get the underhook.  Don't turtle - it's a transition, not a position.  Watch your ankles.  Work on spider.  Work on de la riva.  Look for seminars at gracie barra.  

Tournament Recap

Notes:

• Work on stand up.
• Work on attacks from guard (sweep, choke) and how to attack someone who's stalling.
• Work on balance from side control.
• Work on getting out of turtle.  
• Elevator sweep technique.

BJJ Tournament 3

I'm a few days away from my third tournament.  Tournament 1 I tried blue belt NAGA @199, lost twice in a row to the same guy - I wasn't tight enough or patient enough.  Tournament 2 @210, I went 7-3 in white belt and absolute (all belts) - I did great against most people, but got gassed at the end because my competitors hadn't done as many matches as me.

Tournament 3 is going to be @199 again, and I'm cutting weight from 208.  The over-hydrate process hasn't been too bad, but here's a few notes:

Nutrition Plan:
32 ounces = 1 quart
4 quarts = 1 gallon
256 ounces = 2 gallons
Aiming for 1500 calories/day, 1 banana per day.

My plan:
Day T-5: no carbs, 1.5 gallons of water.  Sodium.
Day T-4: no carbs, 2 gallons of water.  Sodium.
Day T-3: no carbs, 2 gallons of water.  (only got  210 ounces) Sodium.
Day T-2: no carbs, 2 gallons of water.  Sodium.
Day T-1: no carbs, 1 gallon of water before 6pm, no eating/drinking after.  Basketball game at 7pm to get a sweat in.  no sodium.
Weigh-in Day: no meals/drinking til weigh ins at 6pm.  2 energy bars allowed during the day to keep functioning at work.  Sauna option if my weight isn't down far enough.  No sodium.

Pro Tips:
- Gum helps fight dry mouth.
- Drinking a ton of water sucks.  Pee as often as you can (teaches your body to process quickly), and I use crystal light to make the water palatable.
- Your body can process about 32 ounces/hour AT MAX, and sustaining that rate is dangerous.  Be disciplined, spread that liquid out over the day.
- Don't drink water in the last couple hours before bed - it'll keep you up all night!
- Processing this much cold water during the winter can lower your body temperature.  Just keep this in mind.

Fight game plan:
- Aggression
- Go for leg triangles as the end game every time, but don't telegraph it.  Do the opposite.
- Fake leg submissions to get them out of position.
- Fight like hell to get out of side control when I get into it.
- Roll from turtle
- AVOID LEG LOCKS by keeping tabs on my ankles.

I'm feeling a lot more confident in my ability to pull off arm triangles and armbars right now, and my omoplata is coming along.  If I get an omoplata, I'll look to set up a triangle rather than sweep/submit.

From guard, I'll pull him in and look for rubber guard, kimoras (fake the guillotine), and bump sweeps.  From his guard, I'll look at the sky and use the ankle break.  From his back, I'll focus on RNC but consider armbars and especially bow and arrow.  In guard pass, I'll focus on sucking his legs in, keeping my head down, and controlling his hips.  

ONTAP 8.1: What you care about.

DATA ONTAP 8.1: What's new that you care about.

• Hugely improved parallel processing software.  You should see big improvements in what your CPU's are capable of. 
• In-place, online 32-64 bit aggregate conversion. Woot!
• 160TB aggregate limits on 3200 and 6200 series.
• Support for SnapMirror across clusters.
• Support for SAS shelves in 7-mode metrocluster.
• Cluster mode support for NFSv4.
• Cluster-mode support for dedupe, 7-mode and Cluster-mode support for compression.
• Cluster-mode support for SAN (FC and iSCSI).
• Cluster-mode support for non-disruptive OS upgrades.
• Cluster-mode support for FlashCache.
• Cluster-mode support for SnapMirror?
• Cluster-mode support for up to 24 nodes (only 4 if SAN).

Interesting: compression runs before dedupe.  

AT&T and iPhone

Since my AT&T contract is up, I'm considering upgrading my iPhone 3GS.  The rep told me I could save money on my plan by going to a 2GB data limit ($25 instead of $45).  I need to keep text and voice as unlimited - my experience is that you'll end up going over and spending that money anyway, so you might as well use it.

Last time I checked, I never used anywhere near 2GB/month...so I checked again, and here's what I found: 

Credit: Me and AT&T

My data usage on the same 3GS I've always had has shot through the roof.  That may be my job (switched in April), that may be a change in my behavior, that may be software eating up data passively.  I don't know - I need to break this down further.

I went to their website | wireless | usage & recent activity | "more details" under "Data" | Selected "Filter Data Usage by: Internet/MEdia Net" and then sorted by transmission size.  I found 0.833GB in November from 32 entries in 18 days of usage.  I have a great wireless connection at home, so I'll try to utilize that better for the next 12 days and see what the results are.

NetApp Insights: Sequential Reads

In the spirit of customizing NetApp technology for your workload and needs, one thing to talk about is sequential reads. The vast majority of customers don't have to worry about this because WAFL is designed to meet 99% of normal use cases, but in some unique situations it pays to optimize.


 For example, if your workload is 20 minutes of random writes followed by 20 minutes of sequential reads, and you don’t use any reallocate technology, you will likely see declining performance on your NetApp system over time. Who has this workload?  Basically nobody.  But for less extreme cases, you may find performance boosts through customizing your volume for sequential reads like this guy, who got a 6% throughput increase.  


Here are a couple steps you can take:

• set vol option read_realloc.
• option wafl.optimize-write-once=false. 
• schedule a regular reallocate scan.

About read reallocation (Quote)


    For workloads that perform a mixture of random writes and large and multiple sequential reads, read reallocation improves the file's layout and sequential read performance. When you enable read reallocation, Data ONTAP analyzes the parts of the file that are read sequentially. If the associated blocks are not already largely contiguous, Data ONTAP updates the file's layout by rewriting those blocks to another location on disk. The rewrite improves the file's layout, thus improving the sequential read performance the next time that section of the file is read. However, read reallocation might result in a higher load on the storage system. 


   Also, unless you set vol options vol-name read_realloc to space_optimized, read reallocation might result in more storage use if Snapshot copies are used. If you want to enable read reallocation but storage space is a concern, you can enable read reallocation on FlexVol volumes by setting vol options vol-name read_realloc to space_optimized (instead of on). Setting the option to space_optimized conserves space but results in degraded read performance through the Snapshot copies. Therefore, if fast read performance through Snapshot copies is a high priority to you, do not use space_optimized. 


   Read reallocation might conflict with deduplication by adding new blocks that were previously consolidated during the deduplication process. A deduplication scan might also consolidate blocks that were previously rearranged by the read reallocation process, thus separating chains of blocks that were sequentially laid out on disk. Therefore, since read reallocation does not predictably improve the file layout and the sequential read performance when used on deduplicated volumes, performing read reallocation on deduplicated volumes is not recommended. Instead, for files to benefit from read reallocation, they should be stored on volumes that are not enabled for deduplication. The read reallocation function is not supported on FlexCache volumes. 


If file fragmentation is a concern, enable the read reallocation function on the original server volume.  (/Quote)


More reading here.  Interesting quote from this additional reading: "For write-intensive, high-performance workloads we recommend leaving available approximately 10% of the usable space for this optimization process."  Luckily that 10% includes any white space, including unused space carved out for thick provisioned LUN's.

NetApp Insights: RAID Group and Aggregate Setup

 Since I'm always looking out for the underdog, I'm aware that many customers can't afford to buy 20 shelves of disks at a time.  And even though they are smaller customers, getting in at a ground floor with great technology and earning loyalty from a customer is a big priority for any smart company.

If you've just invested in a small NetApp deployment, here are the questions you should be asking yourself:
1.  How can I get the most usable space out of my investment?
2.  How can I ensure full redundancy and data protection?
3.  What configuration will squeeze the most performance out of this system?
4.  Where are my performance bottlenecks today in #3's configuration?
5.  How long will it take to saturate that bottleneck, and what will be my plans to expand?

I'm going to discuss the configuration options that will both maximize your initial investment and set you up for success in the long term.  Be aware that this is a textbook study of tradeoffs between stability, scalability, space, and performance.

A few basics: 
1.  Each controller needs to put its root volume somewhere.  Where yo put it makes a big difference when working with <100 disks.
       a. For an enterprise user, the recommended configuration is to create a 3 disk aggregate whose only responsibility is to hold this root volume, which requires no more than a few GB's of space.  If you only purchased 24 or 48 disks, you could understandably consider this to be pretty wasteful.
     The rational behind this setup is that you isolate these three OS disks from other IO, making your base OS more secure.  More importantly, if you ever have to recover the OS due to corruption, the checkdisk process will only have to run against 3 disks rather than several dozen.  Lastly, if your root vol ever runs out of space, expect a system panic.  By creating a 3 disk aggregate, you protect it from being crowded out by expanding snapshots.
       b.  For a smaller deployment, another option would be to create an aggregate spanning those 24-48 disks and have the root volume reside there.  This is a valid option that is taken by many customers.

2.  Each RAID Group (RG) has 2 disks dedicated to parity.  Consider this when looking at space utilization.

3.  You typically want to avoid having a mixed ownership loop/stack.  What this means is within a stack of shelves, do your best to have the disks only owned by a single controller.  This is not always achievable right away, but could be after an expansion.
4.  Before creating a RG plan for any SAN, one should read TR-3437 and understand it thoroughly.  It covers everything you need to know.

Scenario:  You purchase a FAS3100 series cluster with 2 shelves of SAS 450GB, no FlashCache.  Here are a few of the options available.  Note: these IOP numbers are not meant to be accurate, just illustrate the relative merits of each configuration.
1.  Create two stacks of 1 shelf.  Create two RG's per shelf of 11 and 12 disks each, combined in one aggregate. Leave one spare disk per shelf.  Results:
Usable space: 12.89TB
IOPS the disks can support: 175 IOPS/disk * 19 data disks = 3325 IOPS each controller.
Advantages: Easily expandable (existing RG's will be expanded onto new shelves, improving stability), full controller CPU utilization available, volumes on each controller are shielded in terms of performance from volumes on the other controller.
Disadvantages: Lower usable space, lower IOPS available for any one volume, no RG dedicated to root volume.

2.  Create two stacks of 1 shelf.  Create 1 RG per shelf of 23 disks each, combined in one aggregate.  Leave one spare disk per shelf.  Results:
Usable space: 14.26TB
IOPS the disks can support: 175 IOPS/disk * 21 data disks = 3675 IOPS each controller.
Advantages:  Higher usable space, lower IOPS available for any one volume, full controller CPU utilization available, volumes on each controller are shielded in terms of performance from volumes on the other controller.
Disadvantages: Lower IOPS available for any one volume, no RG dedicated to root volume, lower data protection because of the large RG size, lower stability when expanded because the entire RG is located in one shelf.

3.  Create 1 stack of 2 shelves for an active/passive config.  Create 4 RG's (14, 14, 15, 3), with the large RG's combined in one aggregate and the 3 disk RG in another.  Leave one spare disk per shelf.  Results:
Usable space: 12.39TB
IOPS the disks can support: 175 IOPS/disk * 37 data disks = 6475 IOPS for only the active controller.
Advantages:  High IOPS available for any one volume, volumes on each controller are shielded in terms of performance from volumes on the other controller, expandable (existing RG's will be expanded onto new shelves, improving stability).
Disadvantages: Lower usable space,  no RG dedicated to active controller root volume, only half the CPU power of the cluster used.

4.  Create 1 stack of 2 shelves for an active/passive config.  Create 3 RG's (22, 21, 3), with the two largest in one aggregate and the 3 disk RG in another.  Leave one spare disk per shelf.  Results:
Usable space: 13.08TB
IOPS the disks can support: 175 IOPS/disk * 39 data disks = 6825 IOPS for only the active controller.
Advantages:  Highest IOPS available for any one volume.
Disadvantages:  Lower usable space, no RG dedicated to root volume on active controller, lower data protection because of the large RG size, lower stability when expanded because the entire RG's are located in two shelves, only half the CPU power of the cluster used.

5.  Create 1 stack of 2 shelves for an active/passive config.  Create 4 RG's (20, 20, 3, 3), with the two largest in one aggregate and two root aggregates of 3 disks..  Leave one spare disk per shelf.  Results:
Usable space: 11.89TB
IOPS the disks can support: 175 IOPS/disk * 36 data disks = 6300 IOPS for only the active controller.
Advantages:  RG dedicated to root volumes, high IOPS for active controller.
Disadvantages:  Lower usable space, lower data protection because of the large RG size, lower stability when expanded because the entire RG's are located in two shelves, only half the CPU power of the cluster used.

Here's the break down:

Credit: Me!

This post is long enough already so I'll keep the conclusion short: understand the requirements of your application, and use the examples above to help customize NetApp systems to meet those specs at a low price.