[Bug 656358] [NEW] st module - dump of ext4 with block size >= 1024k fails

[blabj]

Public bug reported:

Binary package hint: linux-image-2.6.32-25-generic-pae

When dumping an ext4 to an LTO-4 tape drive and specifying a block size
of 1024K, dump fails - kernel reports "st0: Can't allocate 1048576 byte
tape buffer".

dump -0uf /dev/nst0 -b 1024 /boot

  DUMP: Date of this level 0 dump: Thu Oct  7 00:03:43 2010
  DUMP: Dumping /dev/sda1 (/boot) to /dev/nst0
  DUMP: Label: none
  DUMP: Writing 1024 Kilobyte records
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 76708 blocks.
  DUMP: Volume 1 started with block 1 at: Thu Oct  7 00:03:46 2010
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: 1.33% done, finished in 0:00
  DUMP: write error 2048 blocks into volume 1: Value too large for defined data type
  DUMP: fopen on /dev/tty fails: No such device or address
  DUMP: The ENTIRE dump is aborted.

NOTE: Strangely, dumping an ext3 file system to the same drive, using
1024K block size works fine.

After this failure - the st module is confused - an "mt -f /dev/st0
status" reports "Tape block size 13121963 bytes. Density code 0x0
(default)." - whereas tape has variable block size - so should be zero.
All subsequent attempts to read or write to the drive generate a failure
: "st0: Write not multiple of tape block size."

If I unload st and reload it, then do "mt -f /dev/st0 status", then its
back to normal: "Tape block size 0 bytes. Density code 0x46 (LTO-4)."

I can successfully dump ext4 to tape using 512k block size.

  DUMP: Date of this level 0 dump: Thu Oct  7 10:59:20 2010
  DUMP: Dumping /dev/sda1 (/boot) to /dev/nst0
  DUMP: Label: none
  DUMP: Writing 512 Kilobyte records
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 76196 blocks.
  DUMP: Volume 1 started with block 1 at: Thu Oct  7 10:59:21 2010
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: 0.67% done, finished in 0:00
  DUMP: Closing /dev/nst0
  DUMP: Volume 1 completed at: Thu Oct  7 10:59:27 2010
  DUMP: Volume 1 75776 blocks (74.00MB)
  DUMP: Volume 1 took 0:00:06
  DUMP: Volume 1 transfer rate: 12629 kB/s
  DUMP: 75776 blocks (74.00MB) on 1 volume(s)
  DUMP: finished in 1 seconds, throughput 75776 kBytes/sec
  DUMP: Date of this level 0 dump: Thu Oct  7 10:59:20 2010
  DUMP: Date this dump completed:  Thu Oct  7 10:59:27 2010
  DUMP: Average transfer rate: 12629 kB/s
  DUMP: DUMP IS DONE

Device detection details is as follows:

[   11.583885] scsi 2:0:0:0: Sequential-Access IBM      ULT3580-HH4      89B1 PQ: 0 ANSI: 3
[   11.586457] scsi 2:0:0:0: Attached scsi generic sg0 type 1
[   11.589235] scsi 2:0:0:1: Medium Changer    IBM      3573-TL          8.50 PQ: 0 ANSI: 5
[   11.590793] st: Version 20081215, fixed bufsize 32768, s/g segs 256
[   11.591059] st 2:0:0:0: Attached scsi tape st0
[   11.591123] st 2:0:0:0: st0: try direct i/o: yes (alignment 4 B)
[   11.593079] osst :I: Tape driver with OnStream support version 0.99.4
[   11.593080] osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $
[   11.626528] scsi 2:0:0:1: Attached scsi generic sg1 type 8
[   11.628485] SCSI Media Changer driver v0.25 

This is on an IBM BladeCenter S - HS21 blade server running ubuntu lucid
(32-bit PAE), with a TS3100 Tape Library.

The problem may lie with dump - but the fact that the st module needs
reloading points to the module itself.

** Affects: linux (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: dump ext4 st

-- 
st module - dump of ext4 with block size >= 1024k fails
https://bugs.launchpad.net/bugs/656358
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to linux in ubuntu.