xfs
[Top] [All Lists]

Re: xfsdump problem (blocksize)

To: List Account <listac@xxxxxxxxxxxxxxxx>
Subject: Re: xfsdump problem (blocksize)
From: Timothy Shimmin <tes@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 14 Aug 2001 10:40:56 +1000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <3B782E95.10205@xxxxxxxxxxxxxxxx>; from listac@xxxxxxxxxxxxxxxx on Mon, Aug 13, 2001 at 09:46:29PM +0200
References: <11189.997683854@xxxxxxxxxxxxxxxxxxxxxx> <3B782E95.10205@xxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
Hi there,

On Mon, Aug 13, 2001 at 09:46:29PM +0200, List Account wrote:
> Hi,
> 
> I have run into a slight problem with xfsdump - though it is more of 
> general nature, I hope it not too of topic.  
Not at all.

> That is, how do I determine 
> the correct block size for my tape drive  (Exabyte exb-8900 mammoth). 
> Using "mt setblk 0" works (and is recommended) for tar, but not for 
> xfsdump. Setting no blocksize at all does not work, either.

"mt setblk 0" puts the scsitape driver into variable blocksize mode. 
I'd recommend this for xfsdump/xfsrestore also since it easily allows
the program to choose the blocksize it wants - and I've generally
found that there are less hassles.
xfsdump uses a default blocksize of 1Mb.
(xfsdump on IRIX typically uses a default blocksize of 2Mb - more
 notes about this can be found in cmd/xfsdump/doc/README.xfsdump)


> Below is the output, first for no blocksize set and second for variable 
> blocksize:
> 
> xfsdump: preparing drive
> xfsdump: fixed block size tape drive at /dev/tape
> xfsdump: unable to set block size to 1048576
> root@kaperfahrt:~/bin#
> 
> syslog:
> 
> Aug 13 21:22:55 kaperfahrt kernel: st0: Block limits 1 - 245760 bytes.
                                                           ^^^^^^
> Aug 13 21:22:55 kaperfahrt kernel: st0: Illegal block size.
> 
>From this you can see that your blocksize limit is 245760 bytes (240K)
for your tape drive.
Unfortunately, the scsi tape driver does not export this upper limit
(only writes it into syslog).
Otherwise xfsdump/xfsrestore would be using it (as it does in IRIX).
So you can see from xfsdump that it tries to set the block-size
to its 1Mb default but this fails since it is greater than 240K.

Tar would be fine as it typically uses a small blocksize 
(something like 10K - I can't remember exactly).


> --------------
>  >mt setblk 0
> 
> root@kaperfahrt:~/bin# xfsdump -o -l 0 -v trace -F -L test -M test -f 
> /dev/tape /dev/hdg1
> xfsdump: preparing drive
> xfsdump: variable block size tape drive at /dev/tape
> xfsdump: WARNING: media may contain data. Overwrite option specified
> xfsdump: dump size (non-dir files) : 0 bytes
> xfsdump: NOTE: dump interrupted: 0 seconds elapsed: may resume later 
> using -R option
> root@kaperfahrt:~/bin#
> 
Not too sure why you didn't get an error msg here.

Anyway, the correct thing to do here would be to explicitly
set the blocksize to 240K for xfsdump and xfsrestore using
the -b option.
e.g.
    # xfsdump -o -b 245760 -l 0 -v trace -F -L test -M test \
    -f /dev/tape /dev/hdg1

And on the question of what the smallest block size that
xfsdump/xfsrestore likes - I'm not too sure.
Certainly 240K will work; some source comments indicate it is the
minimum supported blocksize (except for QIC tapes which
are special cased) and it is used as the default blocksize 
for remote tapes. 
So I know 240K should work but some auditing of the code
and some experiments would be needed to see if one can
go lower.
Anyway, in your case it looks like 240K is supported by
your tape drive.

Cheers,
Tim.


<Prev in Thread] Current Thread [Next in Thread>