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 Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs