Sorry for the delay in this summary, but this got lost under a pile of
mail. Early last October, I asked about transferring files from one
disk to another. This was my original message:
Hello,
I plan on upgrading a 327 MB disk to a 1.2 GB disk pretty soon. The files
contained on the disk are applications served to all suns in our department,
and are continuously mounted read-only. I was wondering how I should go about
transferring the files to the new disk with minimum impact on the client
machines. Normally, it is not a problem when the server crashes, because the
clients start working again soon after the server comes up. However, I am
concerned that the new files, created by dump -> restore or tar -> tar,
will not jive with what the clients expect. As far as the machines are
concerned, all I want them to think is that the server went down for a while,
and it's business as usual. Will I get things like stale NFS file handles
and other nasty messages on the clients with the new server disk? Any help or
advice would be appreciated.
Thanks,
Bill Eggers
ws_eggers@pnl.gov
I received 9 responses to my query. Most agreed with me and said I
couldn't avoid file handle errors unless at least the filesystem is
remounted. Hal Stern gave one of the best replies, which I show here:
-----------------
From: stern%sunne.East.sun.com@Sun.COM
Subject: Re: transferring files to new disk
you're going to have to unmount the filesystem or reboot the clients.
when you load the files onto the new disk, you have 2 choices:
(a) do an image copy with dd. don't do this -- the disks aren't
identical, and you'll either trash the filesystem or
get really poor performance (a 327M disk isn't laid out like
a 1.3G byte disk)
(b) use tar or restore. when either program creates the files on
the new disk, they are bound to have different inode numbers.
furthermore, building the new filesystem on the new disk
sets the generation number in each inode to a random number
(for security reasons).
an NFS file handle is a disk id # (devid), an inode number and
a generation number. if any of them are no longer valid, the file
handle is stale -- so you're pretty much guaranteed to invalidate
all client file handles when you rebuild a server.
--hal
My ultimate solution was wait for a scheduled power outage this weekend. The
disks can be switched then, and I'll use dump -> restore, so that pretty much
solves any problems with stale file handles.
Thanks to the following people who responded:
Loki Jorgenson <loki@nazgul.physics.mcgill.ca>
admin%esrg@hub.ucsb.edu
mike@fionn.lbl.gov
mike%trdlnk.uucp@BCLVXF
poffen@sj.ate.slb.co
Matt Crawford <matt@oddjob.uchicago.edu>
kpc!kpc.com!cdr@uunet.UU.NET
stern%sunne.East.sun.com@Sun.COM
etnibsd!vsh@uunet.UU.NET
Bill Eggers
ws_eggers@pnl.gov
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:16 CDT