Hi,
thank you for the two answers I got from
Rainer Freis <freis_at_santix.de.
Dr. Tom Blinn <tpb_at_zk3.dec.com>
Rainer, suggested that existing links would have been resolved
causing allocation of real files. (In most cases I am sure that no
links existed)
My question was incomplete not showing the environemt, as Tom
pointed out. I copied
from A to B
D-Unix v3.2g D-Unix V4.0D
local advfs (4GB disk) advfs 2GB disk (mounted via nfs on A)
Alphastation 4/233 Alphastation 4000-300
vdump|vrestore executed here
The explanation of Tom is:
The underlying system (you didn't indicate what system is exporting the NFS
file system, but it doesn't really matter) probably supports "sparse" files,
that is, files that logically have all pages present, but physically have
one or more pages that are all "null" content (binary zeros) and that are
not actually allocated to the file. Most UNIX systems support this; but not
every file system is capable of doing it. As far as I know, NFS does not
have support for sparse files; so on export, any request for a page that is
not actually present in the underlying file in the underlying file system
will be delivered to the client as a page full of zero data, and on writes,
as far as I know, any attempt to write into a page beyond the current extent
of the file will cause all the intermediate pages to come into existence; in
any case, vdump also has no support for sparse files except when reading
from a local AdvFS file system (in which case it knows how to read the file
system metadata and figure out that a file is sparse, just as dump knows how
to read a UFS file system's metadata to figure out the same thing; there is
no common virtual file system operation that works on all UNIX file systems
to find out what file pages actually exist).
There is some information on sparse files in the V4.0D release notes that
may shed some additional light on this topic.
Tom
Dr. Thomas P. Blinn + UNIX Software Group + Compaq Computer Corporation
The original question was:
> Hi all,
>
> I do a
>
> #vdump -0f - -D /dir | vrestore -xf - -D /user_4/dir
>
> /user_4 nfs mounted.
>
> The result is that on the target disk more blocks are allocated
> then in the original directory tree (I could understand this in
> VMS if the target disk would be much larger i.e. has a greater
> cluster factor, but here I copy the tree from a 4GB disk to a 2GB
> disk)
>
> #du /user_4/dir e.g. several directory trees
>
> Source Ziel
> 1. 560726 578454
> 2. 1024418 1058130
> 3. 15844 17012
>
> What is the reason for that? (Of course it is always better to
> have more instead of less blocks in the target tree...)
>
> Regards
>
> Otto
>
> -------------------------------------------------------------------------
> | Dr. Otto Titze, Kernphysik TU, Schlossgartenstr. 9, D-64289 Darmstadt |
> | titze_at_ikp.tu-darmstadt.de Tel: +49(6151)16-2916,FAX:16-4321|
> -------------------------------------------------------------------------
Regards
Otto
Received on Thu Jul 16 1998 - 11:29:24 NZST