Thanks to:
Knut.Hellebo_at_nho.hydro.com
Mitch Bertone <mbertone_at_gtech.com>
Petri Kallberg <kallu_at_islay.fno.dec.com>
The solution was:
>From duv32cas00002-19970516.README :
(available from
ftp://ftp.service.digital.com/public/dunix/v3.2c/)
PROBLEM: (QAR 35611) (Patch ID: OSF350-094)
********
Utilities that traverse the / mount point may not distinguish /proc as
a mount point. Example utilities include vdump, find, DECnsr, etc.
vdump example:
vdump of / complains about backing up /proc. It should ignore
this area.
root_at_soak2> vdump -0uf /dev/rmt1h /
path : /
dev/fset : root_domain#root
type : advfs
advfs id : 0x0c3a0248.fffffc00.e17f340
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories
vdump: error reading extend attributes for directory <./proc>
vdump: Dumping 1308099525 bytes, 284 directories, 1977 files
vdump: Dumping regular files
vdump: error reading extend attributes for directory <./proc>
vdump: error reading extend attributes for file <./proc/00000>
vdump: unable to read file <./proc/00000>; [22] Invalid argument
vdump: error reading extend attributes for file <./proc/00001>
vdump: unable to read file <./proc/00001>; [22] Invalid argument
vdump: error reading extend attributes for file <./proc/00015>
My problem:
> Today we had to restore our root directory on DU 3.2C
> It's an ADVFS file system and we used the command,
>
> vrestore -iv
>
> It worked fine until the root file system filled up and there wasn't
> enough room for temporary files to complete the restore.
> Investigating
> showed a heap of files named like 00134 ... 00296 ... Deleting these
> from another session before answering "n" not to abort the restore
> allowed things to be restored OK. I imagine if we'd linked /tmp
> to another filesystem with enough free space before restoring things
> may have gone fine. But where do these files come from?
>
> I suspect they were in /proc when vdump ran. We tried the restore
> again excluding /proc from the list of files to restore but the
> result was the same. ls in vrestore didn't list them.
>
> The vdump command was,
>
> /sbin/vdump -0 -u -N -f /dev/nrmt0h /
>
> Here's an extract of the vdump log,
>
> vdump: Dumping regular files
> vdump: unable to read file <./proc/00000>; [22] Invalid argument
> vdump: unable to read file <./proc/00001>; [22] Invalid argument
> vdump: unable to read file <./proc/00003>; [22] Invalid argument
> vdump: unable to read file <./proc/00025>; [22] Invalid argument
> vdump: unable to read file <./proc/00134>; [22] Invalid argument
> vdump: unable to read file <./proc/00137>; [22] Invalid argument
> vdump: unable to read file <./proc/00189>; [22] Invalid argument
> vdump: unable to read file <./proc/00234>; [22] Invalid argument
> ...
>
> QUESTIONS
>
> How do we exclude these files during the vdump of the / file systems?
>
> Failing this, how do we stop them from being restored to / during
> vrestore?
>
> +--------
Received on Wed Aug 06 1997 - 08:00:53 NZST