Hidden SAN fragmentation

  • Evil Kraig F

    SSC Guru

    Points: 100851

    Hey folks, a quickie question about the drive space assignment mechanics.

    We'll simplify things. Working on a single drive in a LUN, said drive is a 1Tera drive. I need 300 gigs, so I get a nice simple 300 gig LUN assignment off the single spindle, leaving 700 of it free.

    I will eventually need all the space, but for now I drop 50 gigs into my LUN. The 700 gigs eventually gets assigned to something else, and it sporadically writes to the drive.

    As I add files (or grow my .mdf), I use up more and more of my 300 gigs.

    My 300 gigs looks contiguous from the perspective of the OS which can see into the LUN... however, is the physical spindle still contiguous, or does it interleave with the other 700 gigs assigned to a different LUN?

    - Craig Farrell

    Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

    For better assistance in answering your questions[/url] | Forum Netiquette
    For index/tuning help, follow these directions.[/url] |Tally Tables[/url]

    Twitter: @AnyWayDBA

  • GSquared

    SSC Guru

    Points: 260824

    I'm pretty sure I've always seen them as single blocks of spaces on a drive, not fragmented all over. But that might be an artifact of how they're set up as opposed to a "natural law" kind of thing.

    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • alen teplitsky


    Points: 30014

    this will depend on the vendor. i believe with EMC you can assign specific drives as you want. Netapp everything is a RAID5 or 6 or something similar and you get chunks of disk space

  • Nadrek


    Points: 20039

    Ask your SAN expert about whether or not your LUN is assigned up front in a contiguous block, or as you write to it.

  • chudman


    Points: 2422

    Just read a sales pitch from Condusiv Technology, who now owns Diskeeper. Lots of mention of performance degradation due to fragmentation on SAN storage.


    and no, I do not work for these guys, but I am trying to track some vm performance problems that nobody wants to own, and it has led me here.


    Jeff Bennett

  • EdVassie

    SSC Guru

    Points: 60270

    It is now very rare for a SAN to assign a LUN from contiguous disk space. Most SANS work with some form of track vector mapping. You should find out how the LUNS are assigned that you use for SQL Server.

    With this approach, you only ever write and read a given track in the SAN. You never update anything.

    When you want to update a track, the SAN gets a track from the free space pool and writes to that. When the write is complete, pointers are updated so that future reads use the new track instead of the old track.

    If you have a SAN Snapshot in operation, the old track remains in the snapshot until the snapshot is deleted. When the track is no longer in use, it is put into a garbage pool for eventual recycling into the free space pool.

    This approach is also what SSD drives do, but at the block level instead of the track level.

    It makes very little difference to performance if your LUN is carved from contiguous space in te SAN or from vectorised storage - either can perform equally as well. However, vectorised storage can facilitate other operations, such as fast snapshots, fast file-level differential backups, etc, so it is the most widely used approach.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • hvermaak

    SSChasing Mays

    Points: 642

    It all depends on the startegy that is being follow by your SAN team.

    If they are using thin or thick provisioning.

    With thin provisioning the disk is allocated as 100Gb but in reality it is only 10Gb on disk when the threshold is reached that disk will either alert the SAN admin or will auto grow.

    The problem that arises is the sectors that it will grow are not contigous.

    This will affect the performance of the drives as the drive head will need to skip to a new location reducing the effectiveness of read/write operations.

    I would do an IOmeter test on the server and ask SAN management to investigate.

    How fragementation affects IO response see below


  • liteswitch


    Points: 1764

    As hveermak mentioned, the first thing would be to check whether your SAN storage is using thick or thin provisioning for the volumes, as once you know that you have a starting point to work with.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply