[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amanda-users
Subject:    Re: /dev/vgxxx under HP-UX? [solved]
From:       "Adrian T. Filipi-Martin" <atf3r () cs ! virginia ! edu>
Date:       1997-10-31 18:02:57
[Download RAW message or body]

On 31 Oct 1997, Alexandre Oliva wrote:

> Adrian T Filipi-Martin writes:
> 
> > 	Recently, I created a volume group and went with the boring
> > /dev/vgNN naming scheme, where NN is a number.  Previously I used names
> > like /dev/vghome, etc.  Now the hard links to the block devices behave
> > badly under dump.  When I try to dump from the link to the block device, 
> > e.g. /dev/dsk/home, dump insists on trying to open /dev/dsk/rhome as if 
> > /dev/dsk were the volume group directory.
> 
> Perhaps it's a typo in /etc/fstab, /etc/vfstab or whatever you use to
> list filesystems.  If there's a column in that file that should
> contain the raw device name, and it refers to the block device, amanda
> and/or dump may fail.
> 
> If there's no such column, forgive me for wasting the bandwidth.
> 
> > Can newer versions of Amanda deal with disklist entries in different
> > directories?
> 
> Amanda 2.4.0b3 or a patched 2.3.0.4 allow you to specify full
> pathnames for devices.

	Naw.  There was no problem with the /etc/fstab entries.  However,
I did discover the problem shortly after posting by using trace(1).  My
_new_ fstab entries refered to my hard links, whereas my _old_ fstab
entries refered to the original device files, i.e. the ones under a
/dev/vgxx directory.  The problem is caused by undocumented fstab usage by
dump(1M). 

	dump apparently uses the fstab to decide which way to look for 
the raw device file when passed a block device file, i.e. is it in rdsk 
or in vgxx?  It does this even when it doesn't need the raw device!  All 
I needed to do was rename the block device file!  

	See below for a longish example of the problem in action:

    # fstab contains:
        /dev/dsk/psych /psycharchive hfs defaults 0 3

	# dump 0f - /dev/dsk/psych > /dev/null
	  DUMP: Date of this level 0 dump: Fri Oct 31 12:24:27 1997
	  DUMP: Date of last level 0 dump: the epoch
	  DUMP: Dumping /dev/dsk/rpsych (/psycharchive) to standard output
	  DUMP: Cannot open /dev/dsk/rpsych
	#
    Here the block device was transformed bogusly!
	
	
	# mv /dev/dsk/psych /dev/dsk/psychx
	# dump 0f - /dev/dsk/psychx > /dev/null
	  DUMP: Date of this level 0 dump: Fri Oct 31 12:25:10 1997
	  DUMP: Date of last level 0 dump: the epoch
	  DUMP: Dumping /dev/dsk/psychx to standard output
	  DUMP: This is an HP long file name filesystem
	  DUMP: mapping (Pass I) [regular files]
	^C
	  DUMP: Interrupt received.
	  DUMP: NEEDS ATTENTION: Do you want to abort dump?: ("yes" or "no") yes
	  DUMP: The ENTIRE dump is aborted.
	#
    Works after renaming the device!  No device name change!
	

    fstab contains:
         /dev/vg04/psych /psycharchive hfs defaults 0 3
	
	# mv /dev/dsk/psychx /dev/dsk/psych
	# dump 0f - /dev/dsk/psych > /dev/null
	  DUMP: Date of this level 0 dump: Fri Oct 31 12:26:15 1997
	  DUMP: Date of last level 0 dump: the epoch
	  DUMP: Dumping /dev/dsk/psych to standard output
	  DUMP: This is an HP long file name filesystem
	  DUMP: mapping (Pass I) [regular files]
	^C
	  DUMP: Interrupt received.
	  DUMP: NEEDS ATTENTION: Do you want to abort dump?: ("yes" or "no") yes
	  DUMP: The ENTIRE dump is aborted.
	#
    Now it accepts the given device without question.


	Adrian
--
adrian@virginia.edu        ---->>>>| If I were stranded on a desert island, and
System Administrator         --->>>| I could only have one OS for my computer,
Neurosurgical Visualzation Lab -->>| it would be FreeBSD.  Think about it.....
http://www.nvl.virginia.edu/     ->|      http://www.freebsd.org/

[prev in list] [next in list] [prev in thread] [next in thread]