Thanx for helping ;)

here are the outputs of the machine:

...at EEPROM prompt....

ok

ok probe-scsi-all
/[EMAIL PROTECTED],600000/SUNW,[EMAIL PROTECTED]
LiD HA LUN  --- Port WWN ---  ----- Disk description -----
 0   0   0  2100000c50259807  SEAGATE ST373307FC      0006

/[EMAIL PROTECTED],700000/[EMAIL PROTECTED],1

/[EMAIL PROTECTED],700000/[EMAIL PROTECTED]
Target 5
  Unit 0   Removable Tape     CERTANCEULTRIUM 2       1703

/[EMAIL PROTECTED],700000/[EMAIL PROTECTED],1

/[EMAIL PROTECTED],700000/[EMAIL PROTECTED]
Target 6
  Unit 0   Removable Read Only device    TOSHIBA DVD-ROM SD-M14011009

ok


...........then after boot.................

# mt -f /dev/rmt/0 status
Unconfigured Drive: Vendor 'CERTANCE' Product 'ULTRIUM 2      ' tape drive:
   sense key(0x6)= Unit Attention   residual= 0   retries= 0
   file no= 0   block no= 0
#

# ./tapeinfo -f /dev/rmt/0
Product Type: Disk Drive
Vendor ID: 'CERTANCE'
Product ID: 'ULTRIUM 2       '
Revision: '1703'
Attached Changer: No
SerialNumber: 'JK00GSX'
MinBlock:1
MaxBlock:16777215
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x0
BlockSize: 0
DataCompEnabled: no
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
#

....as you can see, still "Disk Drive" instead of "Tape Drive"....


Gabriele Bulfon - Sonicle S.r.l.
Tel +39 028246016 Int. 30 - Fax +39 028243880
Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY
http://www.sonicle.com



----------------------------------------------------------------------------------

Da: James Ray <[EMAIL PROTECTED]>
A: Gabriele Bulfon <[EMAIL PROTECTED]>
Cc: bacula-users@lists.sourceforge.net
Data: 14 maggio 2006 18.48.18 CEST
Oggetto: Re: [Bacula-users] Bacula on SunFire280R / SPARC

Gabriele Bulfon wrote:
> Hello,
> I have bacula running on both recent Sun v20z / AMD64 and SunFire280R /
> SPARC.
> I recently discovered a different Bacula behaviour on the two platforms,
> with same OS, same Bacula version and same SCSI tape devices.
> - On v20z machines, the throughput of backups is generally around
> 4000-8000KB/s.
> - On 280R machines, the throughput of backups is much slower: around
> 2000KB/s on self backup (same SD/Director machine as the FD), 6000KB/s
> when backing up other Solaris FD machines, 100-400KB/s when backing up
> other Windows FD Machines!
>
> The low throughput happening when backing up the windows machines,
> causes the nightly jobs to finish too late (around 11AM) when these
> machines have a lot of GB of data.
> So I checked for differences between the v20z and the 280R
> configurations, and discovered this strange thing:
> - if I run "tapeinfo -f /dev/rmt/0" on a v20z, the first line shows
> "Product Type: Tape Drive".
> - if I run "tapeinfo -f /dev/rmt/0" on a 280R, the first line shows
> "Product Type: Disk Drive".
> How comes that the 280R returns such a wrong information?
> May the slow throughput be a consequence of this wrong setting?
> If not, what can be causing this slow throughput?
>

bash-2.05# ./tapeinfo -f /dev/rmt/0
Product Type: Tape Drive

Have you tried rebooting and running a probe-scsi-all from the OBP?

Though on my Sun E220R I see only around 2000Kb/sec for a local backup
due to the rather poor IO speeds. I see around 5000Kb/sec from slower
machine across the network. The IO Speed on my 220R is only 40Mb/sec
across the SCSI controller so take this into account.



Reply via email to