VMware Cloud Community
Lost_Steak
Enthusiast
Enthusiast

Difference between VMFS 5.58, 5.60 and 5.61

What is the difference between the different versions of VMFS - 5.58 of ESXi 5.1, 5.6 of ESXi 5.5 and 5.61 of ESXi 6.0?

There doesn't seem to be any change logs that I can find, and there doesn't seem to be any recommendations for upgrade, or if it is necessary when upgrading vSphere.

The only thing that I could find is (Upgrading VMFS datastores after migrating to vSphere 6? | Settlersoman - A settler in the SDDC world...) which mentions that higher versions of VMFS are compatible with earlier versions of ESXi. The article does mention that to upgrade requires that you need to reformat the datastore.

So I'm thinking that with so much effort, what are the benefits? and is it even worth it?

0 Kudos
6 Replies
SavkoorSuhas
Expert
Expert

I believe there's minor performance improvements as to how data is handled in the blocks.

Good question though. Need a concrete answer.

Suhas

If you found this or any other answer useful please consider the use of the Helpful or Correct buttons to award points.

Don't Backup. Go Forward!
Rubrik

0 Kudos
Lost_Steak
Enthusiast
Enthusiast

Thanks for the reply.

Do you have any documentation about the minor performance improvements? I'm still looking for a concrete answer,

Thanks

0 Kudos
guy314567
Enthusiast
Enthusiast

Hi did you received any documentation ?


thanks

0 Kudos
continuum
Immortal
Immortal

I noticed one important difference between those VMFS-versions and that is the treatment of deleted files.
- ESXi 5.1 and earlier: if a flat.vmdk gets deleted through a user-mistake or problem with a Datastorebrowseroperation there is a quite good chance to recover the file with little effort
- ESXi 5.5 and later: to recover a deleted flat.vmdk it is now required to search the raw-volume - recovering thin provisioned vmdks like that is next to impossible unless you are way more skilled than me.

Problem:
moving vmdks from one datastore to another has become more dangerous - if the action fails for whatever reasons the result can be that both the original and the copy are no longer recoverable.
Just had a case recently: user uses datastorebrowser to move a vmdk from one datastore to another. After half a day the operation finished with success message: actually datastorebrowser showed just the descriptor on the target datastore - the flat.vmdk was lost.It was pure luck that I could recover the flat.vmdk after 2 days of scanning - lucky conditions : empty target datastore plus thick provisioning.
Tip:

- avoid moving vmdks with anything else but vmkfstools -i on ESXi 5.5 and later
- be more careful with deleting vmdks on ESXi 5.5 and later
If anybody has useful links to documentation about the changed delete-operation please let me know - I am not aware of any docs that even mention a change at all.

Ulli


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

0 Kudos
NavalgundRaj
Enthusiast
Enthusiast

Hi Tom,

As we have newer file systems, so we have plenty of new features and more robust for infrastructure of VM environment.

Please find below some of new features along with versions increments.

file versions.PNG

Note: If you found this correct or answer useful please consider the use of the Correct buttons to award points. Regards Basavaraj.R Navalgund
0 Kudos
continuum
Immortal
Immortal

> and more robust for infrastructure of VM environment.
Do you have any link with some more background information to verify such a claim ?
I rather get the impression that the switch from 2tb maxsize-per-vmdk to 62tb produces large vmdks that are less robust than the earlier versions.

.Most noticeable effect is the often ridiculous high fragmentation rate of vmdks larger than 2tb

Ulli


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

0 Kudos