ZFS Undelete open file backed by ZFS

[scotia]

Hi,
I have a file on a ZFS filesystem that is currently open - I deleted it with rm but because the file is open it's not quite unliked (yet).
The file is being held open by SAMBA as the file is open on a SAMBA client.
Does anyone know if I can keep/preserve the file?
Thanks

 

[olli@]

In what kind of program is the file open on the SMB client? If that program has a “save as” function, that would probably be your best bet. Apart from that, if you’re lucky, the directory entry might be cached on the client. If it’s still visible there, you may try to copy it.

Otherwise, probably the only way is to look at the raw blocks of the file system, gather the block addresses of the file data, and piece it all together. This requires intimate knowledge of ZFS’ on-disk data structures. There might be tools to assist in that, but I really don’t know because I’ve only done things like that with UFS before, but not with ZFS.

 

[scotia]

It's a .dmg open on a Mac. So it's still open and readable. I'm not overly fussed to lose the file.
I just recall somewhere that until the directory entry is no longer referenced then the data is still there. smbstatus on the server (where the file resides) says the file is held open and the .dmg reads fine.
Anyway I'm about to pull the plug which will mean the file will be unlinked. c'est la vie.

 

[dcrosstech]

Wouldn't deleting the filehandle then free it to the filesystem to release to the filesystem to be reclaimed?

But yes, scotia, the file is sill there, blocks are still reserved and taking up space until the reference count on it goes to zero (last close), and then it is all swept away. Unlink really just means that..unlink the file. Deletion is a side effect when the 'link count' goes to zero and nobody is left holding open the file. Now until those blocks are recycled the data is still physically there, there's just no way to get to it other than reading the raw disk and bypassing the filesystem.

 

[ralphbsz]

In theory, using zdb you should be able to find the inode-like structure that describes the file. In theory, using byte-patching you might be able to create a new directory entry that points at the inode, and increment the link count of the file. You'd have to be super careful to make sure that the one you have just created isn't immediately overwritten by something that's in memory. If you are super sure of what you're doing, you could crash the system immediately, then what you just wrote on disk becomes the truth on the next reboot. The only thing with ZFS is: it relies heavily on logs, so you'd also have to create fake log entries to match. A real ZFS expert might be able to do this; I've done it on other file systems, and it is NOT fun, and on complex modern file systems, very tedious (hours or days of work).