It is not possible to restore file from a mounted snapshot using a hardlink

DISCUSSION dexen deVries 2 participants 4 messages Feb 27, 2011 1 message not in the archive NILFS2 filesystem

lore

Share & tools

lore

dexen deVries

author

2011-02-27 13:20 UTC #0 lore raw

Hello,

The following is more of a feature request than problem report, actually.

I've mounted an older snapshot and tried to restore (add it to the current filesystem state) by creating a hardlink.
Roughly like:
mount /dev/sdb3 ~/current
mount.nilfs2 /dev/sdb3 ~/old -o ro,cp=1234
cd ~/current
ln ~/old/file.bin ./restored-file.bin

The ln' returned Invalid cross-device link'.

I expected such hardlink to have semantics of re-using all the data blocks & metadata of file.bin from snapshot as restored-file.bin, so no duplication of data blocks happens.

Regards,

Signature · 7 lines

dexen deVries

``One can't proceed from the informal to the formal by formal means.''
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 201102271420.57110.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Jérôme Poulin

2011-02-27 15:56 UTC #2 lore raw

In fact, hard links are not supposed to work but cp --reflink *should* work but it does not seem to. cp --reflink is what you would need to achieve what you want.

Envoyé de mon appareil mobile.

Jérôme Poulin
Solutions G.A.

Quoted 24 lines · dexen deVries

Hello,
The following is more of a feature request than problem report, actually.
I've mounted an older snapshot and tried to restore (add it to the current filesystem state) by creating a hardlink.
Roughly like:
mount /dev/sdb3 ~/current
mount.nilfs2 /dev/sdb3 ~/old -o ro,cp=1234
cd ~/current
ln ~/old/file.bin ./restored-file.bin
The ln' returned Invalid cross-device link'.
I expected such hardlink to have semantics of re-using all the data blocks & metadata of file.bin from snapshot as restored-file.bin, so no duplication of data blocks happens.
Regards,
--
dexen deVries

Quoted 5 lines

``One can't proceed from the informal to the formal by formal means.'' --
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

dexen deVries

author

2011-02-27 17:08 UTC #3 lore raw

Quoted 3 lines · On Sunday 27 of February 2011 16:56:25 you wrote:

In fact, hard links are not supposed to work but cp --reflink *should* work but it does not seem to. cp --reflink is what you would need to achieve what you want.

I'm much surprised why hardlink shouldn't work.

I used the `stat' command on a file that's both in snapshot and (uchanged) in current filesystem state and both inode and device fields (st_ino and st_dev) are the same. Thus I don't get why Linux would consider that a cross-device hardlink. After all, it's the same filesystem, just different views of it. Perhaps Linux' VFS is to blame...