gordon@prls.UUCP (Gordon Vickers) (02/20/88)
To aid in the speady customization of Ultrix2.0, prior to
doing the installation, I decided to free up an RA80 for awhile
and just backup my system disk by copying one filesystem to another.
For some reason, my backup filesystems are about 10Mbytes larger
than the originals. Prior to doing the backup, I used 'newfs' and
then 'df' to verify that the new filesystem was empty (except for
an empty lost+found directory).
Seems that the backup filesystems contain partial referances to
files that have been deleted. Anyone know how I can circumvent this
problem without using tape and why I am having the problem ?
The backups were made using the all familiar, straight from the
book (restore(1) example) :
dump 0f - /usr | ( cd /v12/usr; restore xf -)
I am running Ultrix 1.2 on an VAX 11/750 . I was the only user and
in multiuser mode and operating as root.
Here is what I ended up with ( df(1) ):
Filesystem total kbytes kbytes percent inodes inodes percent
node kbytes used free used used free used Mounted on
/dev/ra0g 40095 27210 8875 75% 3756 2900 56% /a
/dev/ra1g 40156 36424 0 101% 3755 1621 70% /A
/dev/ra0d 60335 39165 15136 72% 4854 2890 63% /usr
/dev/ra1h 51860 49804 0 107% 4854 1290 79% /v12/usr
using du(1) :
|--- /usr |--- /v12/usr
v V
8 ./lost+found 8
1 ./adm/crash 4
181 ./adm/old 212
2 ./adm/bin/data 8
29 ./adm/bin 44
28 ./adm/lib 32
580 ./adm 644
2653 ./bin 2832
29 ./dict/papers 40
ls -al /usr/adm/crash :
total 2
drwxrwxr-x 2 root 512 Dec 9 14:34 .
drwxrwxr-x 6 root 1024 Dec 11 15:26 ..
ls -al /v12/usr/adm/crash :
total 8
drwxrwxr-x 2 root 512 Dec 9 14:34 .
drwxrwxr-x 6 root 1024 Dec 11 15:26 ..
Similar findings found for each of the other directories.
Using the public domain utility xod to inspect the directory file
proper shows that the directories restored contains entries to deleted
files.
Dump: /usr/adm
Offset: 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00000000: c0 02 00 00 0c 00 01 00 2e 00 00 00 02 00 00 00 | ................ |
00000010: 0c 00 02 00 2e 2e 00 00 80 05 00 00 10 00 05 00 | ................ |
00000020: 63 72 61 73 68 00 6f 75 c1 02 00 00 10 00 04 00 | crash.ou........ |
00000030: 61 63 63 74 00 00 6f 75 c2 02 00 00 10 00 06 00 | acct..ou........ |
00000040: 61 63 75 6c 6f 67 00 75 c3 02 00 00 10 00 07 00 | aculog.u........ |
00000050: 6c 61 73 74 6c 6f 67 00 c4 02 00 00 14 00 08 00 | lastlog......... |
00000060: 6d 65 73 73 61 67 65 73 00 64 00 00 c5 02 00 00 | messages.d...... |
00000070: 10 00 07 00 6c 70 32 61 63 63 74 00 c6 02 00 00 | ....lp2acct..... |
00000080: 10 00 06 00 6d 73 67 62 75 66 00 00 c7 02 00 00 | ....msgbuf...... |
Dump: /v12/usr/adm
Offset: 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00000000: 80 01 00 00 0c 00 01 00 2e 00 00 00 02 00 00 00 | ................ |
00000010: 0c 00 02 00 2e 2e 00 00 00 03 00 00 10 00 05 00 | ................ |
00000020: 63 72 61 73 68 00 6f 75 80 04 00 00 0c 00 03 00 | crash.ou........ |
00000030: 6f 6c 64 00 00 06 00 00 0c 00 03 00 62 69 6e 00 | old.........bin. |
00000040: 00 09 00 00 0c 00 03 00 6c 69 62 00 8a 01 00 00 | ........lib..... |
00000050: 10 00 04 00 61 63 63 74 00 66 2e 73 8b 01 00 00 | ....acct.f.s.... |
00000060: 10 00 06 00 61 63 75 6c 6f 67 00 73 8c 01 00 00 | ....aculog.s.... |
00000070: 10 00 07 00 6c 61 73 74 6c 6f 67 00 8d 01 00 00 | ....lastlog..... |
00000080: 14 00 08 00 6d 65 73 73 61 67 65 73 00 64 61 74 | ....messages.dat |
What's going on here ? I haven't noticed this problem when using tape.
Thank you very much for any assistance.
Gordon P. Vickers, (408) 991-5370, Signetics Corp. PO Box 3409 M/S 69
Sunnyvale, California, USA 94086
{pyramid, philabs}!prls!gordon
"Of all the things I haven't got, I like gold the best"
- Elmer Fudd in _The_Wacky_Wabbit_grr@cbmvax.UUCP (George Robbins) (03/01/88)
In article <22152@felix.UUCP> gordon@prls.UUCP (Gordon Vickers) writes: > > To aid in the speady customization of Ultrix2.0, prior to > doing the installation, I decided to free up an RA80 for awhile > and just backup my system disk by copying one filesystem to another. > > For some reason, my backup filesystems are about 10Mbytes larger > than the originals. Prior to doing the backup, I used 'newfs' and > then 'df' to verify that the new filesystem was empty (except for > an empty lost+found directory). I'd check the parmameters used in /etc/disktab to newfs/mkfs the file system. Different partitions on the RA80/RA81 have different fragment and block sizes defined, which would create different "waste" factors when loading the filesystem. There are also some classes of files, notably those managed by the 'dbm' routines that are sparsely allocated and will expand to full size when copied sequentially. The most commom expample for a usenet system is the news history file. It's a bit confusing, you mention freeing up an RA80, but your information shows you copying from a 'd' partition, while the /etc/disktab info for the RA80 doesn't list a 'd' partition. ----- For the Gentleman from Australia that asked about using a Fujitsu Eagle with Ultrix - the Eagle should work with the standard ultrix drivers. Depending on the emulation proms included with the controller and the switch settings you can either emulate some arrangement of DEC drives or use the eagle entry in /etc/fstab. Check with Emulex to make sure...
richl@penguin.USS.TEK.COM (Rick Lindsley) (03/05/88)
In article <22152@felix.UUCP> gordon@prls.UUCP (Gordon Vickers) writes:
For some reason, my backup filesystems are about 10Mbytes larger
than the originals. Prior to doing the backup, I used 'newfs' and
then 'df' to verify that the new filesystem was empty (except for
an empty lost+found directory).
The du output and ls -l's are very telling ... could you have dumped
from a file system with a small block size, like 1024, and restored to
one with a much larger size, like 4096 or 8192?
If you did this, then small files (or directories) might be using
more of the disk than before, due to larger "basic building blocks".
Try both "dumpfs /dev/ra0d" and "dumpfs /dev/ra1h" and look for "bsize"
and "fsize" in the output. If they aren't the same, then perhaps that
is the problem. Some of the problem may result from your doing dumps on
an active system -- a lot of file system information may not have been
written out to disk when you did your dump. A growth of 10 Mb, though,
seems unreasonable for both scenarios, so I can't believe this is the
only answer. (Of course, if /usr/spool/news is on /usr, you WILL find
lots of small files there ....)
Rick