Attn: lopoetve - Why not use extents?

[SpaceHonkey]

lopoetve -

In another thread you spoke adamantly against using extents, just curious as to why. If you hadn't mentioned it I'd be tempted to use them...

 

[lopoetve]

bah. Stupid forum keeps eating my posts.

Extents are in many ways like a software RAID0 span, minus the performance - You now have multiple points of failure for your datastore, you cannot undo the operation, you double the number of reservation requests that have to be issued and increase IO contention, it's possible to recreate lost partition tables (and they happen decently often as a result of other problems) but you may not be able to recreate the extent portion of the metadata, making it almost impossible to recover - it's simply less reliable. They're there for specific emergencies and uses, but not something I'd recommend for production.

The worst thing to do is use them on an expanded lun - VMFS does not like expanding luns at this point, and if you add an extent for free space on an expanded lun, you'll need to know the EXACT BLOCK where the first partition ends and the second begins to ever hope to rebuild it - and even then it's non-trivial. Oh, and you might corrupt everything anyway...

 

[SpaceHonkey]

Wow, extents = bad!

 

[sabregen]

In the VCP class, they make no mention of this dilemma (adding extents on an expanded LUN). This is good information. I decided a few weeks ago, as I expanded our existing volume group on the SAN due to new larger drives, that I was just going to keep the existing VMFS3 volume for production VM files, and move the ISO repository off to the new volume. Yes, I have two VMFS3 volumes, but I avoided the particular complication that would have come with the extents.

 

[Thuleman]

In the VCP class, they make no mention of this dilemma (adding extents on an expanded LUN).

Probably depends on your instructor. In the ESX:IAC class I took the instructor emphasized that extents are a last resort temporary stop gap measure and should not be used in production. We did go over how to add extents in a lab (iirc), at which time this issue was mentioned.

Edit: I just had another look at the Student Manual, and on page 142-143 it covers the creation of extents, though it only cautions that if the master is lost, all is lost. It also mentions that the I/O needs to be quesced on all disks involved in the extent in order for it to work safely.

 

[lopoetve]

In the VCP class, they make no mention of this dilemma (adding extents on an expanded LUN). This is good information. I decided a few weeks ago, as I expanded our existing volume group on the SAN due to new larger drives, that I was just going to keep the existing VMFS3 volume for production VM files, and move the ISO repository off to the new volume. Yes, I have two VMFS3 volumes, but I avoided the particular complication that would have come with the extents.

Definitely avoid it. People expect that filesystems will be able to handle it, but VMFS uses a back-to-forward journaling system that relies on the end block to build the journal - should the end block change, you're off into totally unexpected land and there's ~no~ guarantee of what will happen. I've seen it corrupt filesystems, or work fine, or anything in between (some hosts can read, some can't, etc). One thing is for certain though - you eat that metadata, and it happens, and don't know the block where the filesystem was extented? You get to start guessing where it was and shooting in the dark. On production data to boot

Extents also like to fail unless you add them with zero active IO.

Probably depends on your instructor. In the ESX:IAC class I took the instructor emphasized that extents are a last resort temporary stop gap measure and should not be used in production. We did go over how to add extents in a lab (iirc), at which time this issue was mentioned.

Bingo. It's for "oh crap, we have to commit this snapshot chain, have no room, must commit in place..."

 

[sabregen]

Edit: I just had another look at the Student Manual, and on page 142-143 it covers the creation of extents, though it only cautions that if the master is lost, all is lost. It also mentions that the I/O needs to be quesced on all disks involved in the extent in order for it to work safely.

That part I did recall, and was a partial basis for my decision. The other was really that our ESX environment is my personal responsibility, and I like things to be orderly.