Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZFS file system id is not persistent #888

Closed
imp opened this issue Aug 24, 2012 · 3 comments
Closed

ZFS file system id is not persistent #888

imp opened this issue Aug 24, 2012 · 3 comments
Milestone

Comments

@imp
Copy link
Contributor

imp commented Aug 24, 2012

When moving zpool between different hosts the file system id of a given filesystem is not persistent. If this procedure is used for NFS servers failover NFS clients have little chance to survive as their NFS handles become stale.

Apparently commit SHA: 53cf50e introduced the next code in fs_statvfs()

        statp->f_fsid.val[0] = dentry->d_sb->s_dev;
        statp->f_fsid.val[1] = 0;

d_sb->s_dev may be different on different hosts, since it comes from (if I am not mistaken) mount_nodev()/get_sb_nodev().

@imp
Copy link
Contributor Author

imp commented Aug 24, 2012

I have experimented with a quick patch that makes f_fsid.val to be zfs dataset guid and it appears to work quite well.

@behlendorf
Copy link
Contributor

Yes, I can see how that would be a problem. d_sb->s_dev may differ between hosts. It looks like internally OpenSolaris is also using the guid for the fsid so that's a good choice.

usr/src/uts/common/fs/zfs/zfs_vfsops.c:zfs_domount()
...

    /*
     * The fsid is 64 bits, composed of an 8-bit fs type, which
     * separates our fsid from any other filesystem types, and a
     * 56-bit objset unique ID.  The objset unique ID is unique to
     * all objsets open on this system, provided by unique_create().
     * The 8-bit fs type must be put in the low bits of fsid[1]
     * because that's where other Solaris filesystems put it.
     */
    fsid_guid = dmu_objset_fsid_guid(zfsvfs->z_os);
    ASSERT((fsid_guid & ~((1ULL<<56)-1)) == 0);
    vfsp->vfs_fsid.val[0] = fsid_guid;
    vfsp->vfs_fsid.val[1] = ((fsid_guid>>32) << 8) |
        zfsfstype & 0xFF;

My only issue with the patch is that we should probably ensure a known byte ordering so this doesn't change between little/big endian systems. The ext4_statfs() function has one reasonable example of this.

@imp
Copy link
Contributor Author

imp commented Sep 5, 2012

I've spent some time looking through the code that uses f_fsid.val and it is my understanding that it is used as a value, rather than as a byte array. Since GUID itself is endian-neutral it wan't change between little/big endian systems. Unfortunately I lack access to any Linux capable big endian machine in order ot prove it.

Illumos/OpenSolaris, by the way does the same - the code doesn't do anything special for little/big endian systems.

If, however, I have missed something obvious I'll be glad to stand corrected.

imp added a commit to imp/zfs that referenced this issue Sep 6, 2012
Use ZFS dataset fsid guid as a unique file system id, similar to what is
done on Illumos/OpenSolaris.

Issue openzfs#888

Signed-off-by: Cyril Plisko <cyril.plisko@mountall.com>
pcd1193182 pushed a commit to pcd1193182/zfs that referenced this issue Sep 26, 2023
…zfs#888)

Bumps [linux-raw-sys](https://github.com/sunfishcode/linux-raw-sys) from 0.3.6 to 0.3.8.
- [Commits](sunfishcode/linux-raw-sys@v0.3.6...v0.3.8)

---
updated-dependencies:
- dependency-name: linux-raw-sys
  dependency-type: indirect
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants