Thanks Dan. Clearly it's not a process lock as I have rebooted the host. If the only other way, really, is that curiously named "heartbeat region" (sounds a lot like a cache to me) then I guess that must be it. Doesn't feel right though. As you say, curious that it only affected the vswp files across 4 or more VMs.
At the moment, I have 4 VM directories that contain all the original files plus the untouchable vswp files. I will delete almost everything in those once I'm convinced the rebuilt VMs are fine. I am even able to rename these directories, so it doesn't sound like software that used the fully qualified filespec to identify the file - it's probably at more of a hardware level that has identified the file by block number address on the platter (so maybe your heartbeat theory is right). If those deletes go OK I won't even bother to find ways to delete the corrupted vswp files.
The interesting thing to note is that these files have length = -1 bytes and a datetime stamp of 1 second before time zero which was Jan.1 1970. It's as though the file header in the table of contents has been overlaid with FFFFFFFF. In that state I cannot touch them - mv, cp, rm and ls all report that the file or directory does not exist. They're there, but they're not there. In Windows I bet a chkdsk would clean up the indexes - is there something like that in *nix?
In my shutdowns I have shutdown all machines but not usually gone to maintenance mode before power cycling the host. I'll try to remember that.
Regards - Glen
Regards - Glen
