manipulating device numbers to prevent stale NFS handles?

manipulating device numbers to prevent stale NFS handles?

Post by Dan Strombe » Wed, 22 Dec 1999 04:00:00



I believe it to be the case that in order to prevent stale NFS handles
(say, after an upgrade), it is necessary to preserve the inode numbers
and the device number of the disk, both.

Preserving the inode numbers is easy if you're using external devices
- IE, you don't have a bunch of files in /export/home or something.
Additionally, I think it might be possible to create a script that
fixes the inode numbers, if you have a list of what they used to be.

However, we've not found a way to preserve the device numbers.  They
almost seem to change at random.

Has anyone found a way of changing the device number at which a device
appears?  Or of keeping them constant across upgrades?

Here's a script I use to check the device number and inode number of a
file.  I've been calling it "devino":

#!/usr/local/bin/python

import sys
import stat
import posix

for file in sys.argv[1:]:
    s = posix.lstat(file)
    print file,hex(s[stat.ST_DEV]),s[stat.ST_INO]

Usage is like "devino file1 file2 file3"

Thanks for any suggestions you might have.

 
 
 

manipulating device numbers to prevent stale NFS handles?

Post by Casper H.S. Dik - Network Security Engine » Wed, 22 Dec 1999 04:00:00


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>I believe it to be the case that in order to prevent stale NFS handles
>(say, after an upgrade), it is necessary to preserve the inode numbers
>and the device number of the disk, both.

And the inode generation number too.  (This is a random number assigned when
the disk is newfs'ed and increased on each reallocation of the inode)

If the filesystems are preserved, the inodes will remain the same and
the generation numbers too.

Quote:>Preserving the inode numbers is easy if you're using external devices
>- IE, you don't have a bunch of files in /export/home or something.
>Additionally, I think it might be possible to create a script that
>fixes the inode numbers, if you have a list of what they used to be.

Preserving inodes when moving files is really hard; preserving
generation numbers is easier (you can write the generation number back
in the on-disk inode; getting the same inode back requires moving
inodes around on disk)

Only if you move the disks are copy the bits, you have a chance.

Quote:>However, we've not found a way to preserve the device numbers.  They
>almost seem to change at random.

Depends very much on your configuration; controllers and disks
should not be renumbered on an upgrade.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

manipulating device numbers to prevent stale NFS handles?

Post by Dan Strombe » Thu, 23 Dec 1999 04:00:00




<[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
<>However, we've not found a way to preserve the device numbers.  They
<>almost seem to change at random.
<
<Depends very much on your configuration; controllers and disks
<should not be renumbered on an upgrade.

Why we're wondering:

We have two systems, A and B.

A is an existing NFS server with a high uptime requirement.

B is a scratch system we're just fiddling with.

A can't be down long enough to do a normal upgrade, and is running 2.5.1.

We installed B with 2.6.

A and B both have an identical wide scsi controller on sbus.

After the install of B, we used the "devino" script to check the
device number of a file on a filesystem on each of A and B - each on
the same device name in /dev.

These device numbers came up different.

Based on this, can we conclude that we will probably have stale
handles when we pull the OS disk out of B and put it in A?

 
 
 

manipulating device numbers to prevent stale NFS handles?

Post by Casper H.S. Dik - Network Security Engine » Thu, 23 Dec 1999 04:00:00


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>We have two systems, A and B.
>A is an existing NFS server with a high uptime requirement.
>B is a scratch system we're just fiddling with.
>A can't be down long enough to do a normal upgrade, and is running 2.5.1.
>We installed B with 2.6.
>A and B both have an identical wide scsi controller on sbus.
>After the install of B, we used the "devino" script to check the
>device number of a file on a filesystem on each of A and B - each on
>the same device name in /dev.
>These device numbers came up different.
>Based on this, can we conclude that we will probably have stale
>handles when we pull the OS disk out of B and put it in A?

No.  Because teh device will have the same number when returned to A.

However, since you've started witha disk with all different inodes (unless
you made a bit for bit copy of a disk in A and then upgraded it in B),
you will have stale filehandles everywhere.

(Bit for bit: using dd, not tar, cpio, ufsdump/ufsrestore)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.