Re: tar's default block size shoe-shinning
[EMAIL PROTECTED] a écrit sur 19/06/2006 18:09:58 : Actually with AMANDA it might be a really good idea esp. with the faster drives because there's no way you can keep them streaming over the network. Erm, I think you missed the bit where he said he's only backing up disks local to the backup server (and thus the tape drive). No network involved. Indeed, I have only one, big, local, 1TB filesystem to back up. Joshua, I will reply to your previous question over my exact hardware configuration in a moment. Thanks all for taking all this time. Cyrille
Re: tar's default block size shoe-shinning
Joshua Baker-LePain [EMAIL PROTECTED] a écrit sur 19/06/2006 16:59:58 : On Mon, 19 Jun 2006 at 4:31pm, Cyrille Bollu wrote But, when we purchased the backup server I agreed to follow my boss' solution (it's always him you known ;-p) to buy that cheaper server with maximum 1,5TB RAID5 (6*300GB) instead of that nice DAS with up to 3,9TB RAID5. So, to save space I created one big volume containing both the OS and the data. What type of drives, and what RAID card? What OS/distro are we talking, and what SCSI card for the tape drive? The server is a Dell PowerEdge 2850 with 2 Intel Xeon 3GHz processors and 8GB RAM. I have one big RAID5 array made of 6 Seagate Cheetah ST337LC 10Krpm 300GB (http://support.euro.dell.com/support/edocs/storage/p76311sc/intro.htm). All connected to channel 0 of a Dell PowerEdge Expandable RAID Controller 4e/Di (http://support.euro.dell.com/support/edocs/storage/RAID/perc4e/en/ug/index.htm). See hereunder for more info. I'm running Linux RedHat ES 3.3. Nothing is running (except OpenManage (noweb)) when Amanda runs. Does this speak to you? Cyrille [EMAIL PROTECTED] scsi]# lspci 00:00.0 Host bridge: Intel Corp. Server Memory Controller Hub (rev 09) 00:02.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port A0 (rev 09) 00:04.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port B0 (rev 09) 00:05.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port B1 (rev 09) 00:06.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port C0 (rev 09) 00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 (rev 02) 00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2 (rev 02) 00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02) 00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB/ER Hub interface to PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 Storage Controller (rev 02) 01:00.0 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 06) 01:00.2 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 06) 02:0e.0 RAID bus controller: Dell PowerEdge Expandable RAID controller 4 (rev 06) 05:00.0 PCI bridge: Intel Corp. PCI Bridge Hub A (rev 09) 05:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09) 06:07.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller (rev 05) 07:08.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller (rev 05) 08:00.0 PCI bridge: Intel Corp. PCI Bridge Hub A (rev 09) 08:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09) 09:04.0 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m (rev 01) 09:04.1 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m (rev 01) 0a:03.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 0a:03.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 0b:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] [EMAIL PROTECTED] scsi]# [EMAIL PROTECTED] scsi]# cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: IBM Model: ULTRIUM-TD3 Rev: 5480 Type: Sequential-Access ANSI SCSI revision: 03 Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: MegaRAID Model: LD 0 RAID5 1430G Rev: 521S Type: Direct-Access ANSI SCSI revision: 02 Host: scsi2 Channel: 04 Id: 06 Lun: 00 Vendor: PE/PV Model: 1x6 SCSI BP Rev: 1.0 Type: Processor ANSI SCSI revision: 02 [EMAIL PROTECTED] scsi]# [EMAIL PROTECTED] scsi]#dmesg *snip* SCSI subsystem driver Revision: 1.00 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 Adaptec 3960D Ultra160 SCSI adapter aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 Adaptec 3960D Ultra160 SCSI adapter aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs blk: queue f77c5618, I/O limit 524287Mb (mask 0x7f) (scsi0:A:6): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit) Vendor: IBMModel: ULTRIUM-TD3 Rev: 5480 Type: Sequential-Access ANSI SCSI revision: 03 blk: queue f77c5418, I/O limit 524287Mb (mask 0x7f) megaraid: v2.10.6-RH1 (Release Date: Fri May 14 08:36:49 EDT 2004) megaraid: found 0x1028:0x0013:bus 2:slot 14:func 0 scsi2:Found MegaRAID controller at 0xf8873000, IRQ:38 megaraid: [521S:H430] detected 1 logical drives. megaraid: supports extended CDBs. megaraid: channel[0] is raid. megaraid: channel[1] is scsi. scsi2 : LSI Logic MegaRAID 521S 254 commands 16 targs 5 chans 7 luns scsi2: scanning scsi channel 0 for logical drives. Vendor: MegaRAID Model: LD 0 RAID5 1430G Rev: 521S Type:
Re: tar's default block size shoe-shinning
On Tue, 20 Jun 2006 at 9:47am, Cyrille Bollu wrote The server is a Dell PowerEdge 2850 with 2 Intel Xeon 3GHz processors and 8GB RAM. I have one big RAID5 array made of 6 Seagate Cheetah ST337LC 10Krpm 300GB (http://support.euro.dell.com/support/edocs/storage/p76311sc/intro.htm). All connected to channel 0 of a Dell PowerEdge Expandable RAID Controller 4e/Di (h ttp://support.euro.dell.com/support/edocs/storage/RAID/perc4e/en/ug/index.htm). See hereunder for more info. How much benchmarking/optimization have you done with the array? I'm running Linux RedHat ES 3.3. That's an awfully old point release. Any reason for that? scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 Adaptec 3960D Ultra160 SCSI adapter aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 Adaptec 3960D Ultra160 SCSI adapter aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs blk: queue f77c5618, I/O limit 524287Mb (mask 0x7f) (scsi0:A:6): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit) Vendor: IBM Model: ULTRIUM-TD3 Rev: 5480 Type: Sequential-Access ANSI SCSI revision: 03 So you're tape drive is on a U160 adapter rather than a U320 one. I think the problem is in the array though, not the tape drive. I'd look hard at optimizing the array (although if it's in production, that may be tough). -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: tar's default block size shoe-shinning
Joshua Baker-LePain [EMAIL PROTECTED] a écrit sur 20/06/2006 14:07:58 : On Tue, 20 Jun 2006 at 9:47am, Cyrille Bollu wrote The server is a Dell PowerEdge 2850 with 2 Intel Xeon 3GHz processors and 8GB RAM. I have one big RAID5 array made of 6 Seagate Cheetah ST337LC 10Krpm 300GB (http://support.euro.dell.com/support/edocs/storage/p76311sc/intro.htm). All connected to channel 0 of a Dell PowerEdge Expandable RAID Controller 4e/Di (h ttp://support.euro.dell. com/support/edocs/storage/RAID/perc4e/en/ug/index.htm). See hereunder for more info. How much benchmarking/optimization have you done with the array? Almost none... That's the first time I'm working with such a big filesystem. I ran hdparm -t -T when I received the server and got a transfer rate of around 40MB/s from the array. That satisfied me at that time. But now I'm experiencing a transfer rate of less than half the expected speed. And a tape drive that's shoe-shinning... (BTW is this still so bad for the drive? I could not find anything like this in Dell's documentation. They basically just say It will be a lot slower). My idea is to buy that Dell PowerVault 220S (http://support.euro.dell.com/support/edocs/stor%2Dsys/spv22xs/en/ug/index.htm) and move all the data on a RAID50 or RAID5 (whatever gives me the best cost/performance ratio) array that I would create there. That would also separate my OS from my data. I was also wondering if I would use a reiserFS filesystem or if a tuned ext3fs would do the trick. Do you have any hint of what I could do to optimize/benchmark my config? Could you eventually point me to some interesting readings? Ho yes, I also noticed that my processors are waiting for I/O most of their time. But couldn't definitively figure out why. Maybe you will have an idea... Here's a typical output of top when I run du -sh on a 20GB folder: 14:50:54 up 19 days, 22:14, 2 users, load average: 0.20, 0.19, 0.10 206 processes: 204 sleeping, 1 running, 1 zombie, 0 stopped CPU states: cpu user nice system irq softirq iowait idle total 0.0% 0.0% 0.8% 0.0% 0.0% 198.8% 200.0% cpu00 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0% cpu01 0.0% 0.0% 0.9% 0.0% 0.0% 99.0% 0.0% cpu02 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0% cpu03 0.0% 0.0% 0.0% 0.0% 0.0% 100.0% 0.0% Mem: 8203432k av, 8183652k used, 19780k free,0k shrd, 230488k buff 6302676k actv, 1224260k in_d, 172712k in_c Swap: 4192956k av, 452468k used, 3740488k free 7548476k cached And here's a typical output of top when I run tar -cf on the same folder: 14:56:55 up 19 days, 22:20, 2 users, load average: 0.53, 0.50, 0.27 206 processes: 204 sleeping, 1 running, 1 zombie, 0 stopped CPU states: cpu user nice system irq softirq iowait idle total 2.0% 0.0% 18.0% 2.8% 2.0% 182.0% 191.6% cpu00 0.1% 0.0% 6.7% 0.0% 0.3% 74.1% 18.4% cpu01 1.5% 0.0% 2.5% 2.1% 1.5% 13.3% 78.6% cpu02 0.0% 0.0% 4.3% 0.9% 0.1% 78.2% 16.1% cpu03 0.5% 0.0% 4.3% 0.0% 0.0% 16.3% 78.6% Mem: 8203432k av, 8184556k used, 18876k free,0k shrd, 274300k buff 6317820k actv, 1214636k in_d, 182772k in_c Swap: 4192956k av, 517748k used, 3675208k free 7477412k cached PID USER PRI NI PAGEIN SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 31885 root 16 0 146 604 604 532 D 13.3 0.0 0:03 tar 11 root 15 0 0 0 0 0 SW 2.9 0.0 121:36 kswapd 27650 domino 15 0 7110 198M 191M 190M S 1.5 2.3 5:26 server 31886 domino 21 0 252 1004 1000 892 S 0.5 0.0 0:00 Y0090751.s 685 root 15 0 0 0 0 0 SW 0.3 0.0 14:32 kjourna I'm running Linux RedHat ES 3.3. That's an awfully old point release. Any reason for that? a too large to do list perhaps? ;-) Yes, going to kernel 2.6 (and the new megaraid_mbox driver!) was also on my possible-improvement list.
Re: tar's default block size shoe-shinning
[EMAIL PROTECTED] a écrit sur 20/06/2006 15:39:01 : There are ext3 mount options you can play with, as well as options in the RAID controller. All of that can be non-destructive. There are also some mke2fs options one can play with. You're thinking about noatime, aren't you? What else? block-size at filesystem creation? bytes-per-inodes? I think the options of my RAID controller are rights. Except maybe that its read-policy mode is set to adaptive instead of read-ahead only. And I could also increase the strip size from 64k to 128k. However, I doubt that only tweaking these parameters will give me the performance boost I need. Regards, Cyrille
Re: tar's default block size shoe-shinning
On Tue, 20 Jun 2006 at 5:54pm, Cyrille Bollu wrote There are ext3 mount options you can play with, as well as options in the RAID controller. All of that can be non-destructive. There are also some mke2fs options one can play with. You're thinking about noatime, aren't you? noatime can help. Also, at some point there was a problem with the reservation code in ext3, so 'noreservation' helped, but I'm pretty sure that was RHEL4 only. What else? block-size at filesystem creation? bytes-per-inodes? The one I was thinking of was '-E stride=', which attempts to align writes with your RAID stripes. I think the options of my RAID controller are rights. Except maybe that its read-policy mode is set to adaptive instead of read-ahead only. And I could also increase the strip size from 64k to 128k. For my megaraid in RAID1 mode (2 disks only), I found (through a lot of trial and error) that the best setup was read-ahead (not adaptive), CachedIO, and WriteBack (it's got a BBU). However, I doubt that only tweaking these parameters will give me the performance boost I need. Actually, I do recall a signifcant amount of performance difference tweaking the controller parameters, and that with only 2 disks. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: tar's default block size shoe-shinning
On Mon, 19 Jun 2006 at 10:05am, Cyrille Bollu wrote Could someone tell me if there are any possibilities to change the block size tar is using when backuping with amanda? I'm asking this because we have recently bought an IBM ULTRIUM-TD3 LTO3 drive here and Amanda reports an average write rate of only 17MB/s (when the maximum speed should be 40 MB/s uncompressed). Which most probably means that the drive is shoe-shinning... Actually, native speed of LTO3 is 80MB/s, but it can throttle back to 1/2 that without shoeshining. So 40MB/s is the slowest you want to see. I think, tar's default block size of 10k is the most limiting factor since the constructor recommends a block size of 64kb and tests with dd reported a transfer speed of 33MB/s with bs=64k and only reports a 25MB/s with bs=10k. Amanda doesn't 'tar' directly to tape, so it's not tar's blocksize you need to change. Amanda does its writing to tape with a default blocksize of 32KiB. To change that, you'll need to recompile amanda and specify the --with-maxtapeblocksize option to configure. With my LTO3 drive, I compile amanda with --with-maxtapeblocksize=2048. After recompiling amanda, you can change the blocksize in the tapetype. Mine says blocksize 2048, for a 2MiB blocksize. My backups generally tape at 60MiB/s. bs time (sec) calculated speed (MB/s) === 64k 95 33,7 32k 100 32 10k 130 24,6 4k 173 18,5 1k 4097,8 (results from the command time dd if=/dev/sda2 of=/dev/nst0 bs=var1 count=var2. Where var2 is calculated so that var1*var2=3200MB) *All* of those speeds are too slow, so you probably want to look at bigger blocksizes. Also note that there's no way a single disk can both accept backups from over the network *and* keep an LTO3 drive streaming. I drive my LTO3 drive with a 4-disk RAID0, and I'm looking at going bigger so I can use the 2nd drive in my library simultaneously. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: tar's default block size shoe-shinning
Does anybody knows about the --with-maxtapeblocksize used by RedHat ES 3.3? Cyrille Joshua Baker-LePain [EMAIL PROTECTED] Envoyé par : [EMAIL PROTECTED] 19/06/2006 11:02 A Cyrille Bollu [EMAIL PROTECTED] cc amanda-users@amanda.org Objet Re: tar's default block size shoe-shinning On Mon, 19 Jun 2006 at 10:05am, Cyrille Bollu wrote Could someone tell me if there are any possibilities to change the block size tar is using when backuping with amanda? I'm asking this because we have recently bought an IBM ULTRIUM-TD3 LTO3 drive here and Amanda reports an average write rate of only 17MB/s (when the maximum speed should be 40 MB/s uncompressed). Which most probably means that the drive is shoe-shinning... Actually, native speed of LTO3 is 80MB/s, but it can throttle back to 1/2 that without shoeshining. So 40MB/s is the slowest you want to see. I think, tar's default block size of 10k is the most limiting factor since the constructor recommends a block size of 64kb and tests with dd reported a transfer speed of 33MB/s with bs=64k and only reports a 25MB/s with bs=10k. Amanda doesn't 'tar' directly to tape, so it's not tar's blocksize you need to change. Amanda does its writing to tape with a default blocksize of 32KiB. To change that, you'll need to recompile amanda and specify the --with-maxtapeblocksize option to configure. With my LTO3 drive, I compile amanda with --with-maxtapeblocksize=2048. After recompiling amanda, you can change the blocksize in the tapetype. Mine says blocksize 2048, for a 2MiB blocksize. My backups generally tape at 60MiB/s. bs time (sec) calculated speed (MB/s) === 64k 95 33,7 32k 100 32 10k 130 24,6 4k 173 18,5 1k 409 7,8 (results from the command time dd if=/dev/sda2 of=/dev/nst0 bs=var1 count=var2. Where var2 is calculated so that var1*var2=3200MB) *All* of those speeds are too slow, so you probably want to look at bigger blocksizes. Also note that there's no way a single disk can both accept backups from over the network *and* keep an LTO3 drive streaming. I drive my LTO3 drive with a 4-disk RAID0, and I'm looking at going bigger so I can use the 2nd drive in my library simultaneously. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: tar's default block size shoe-shinning
On Mon, 19 Jun 2006 at 2:40pm, Cyrille Bollu wrote Does anybody knows about the --with-maxtapeblocksize used by RedHat ES 3.3? I doubt it's used, but it's easy enough to find out -- download the SRPM and look in the spec file. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: tar's default block size shoe-shinning
On 2006-06-19 14:43, Joshua Baker-LePain wrote: On Mon, 19 Jun 2006 at 2:40pm, Cyrille Bollu wrote Does anybody knows about the --with-maxtapeblocksize used by RedHat ES 3.3? I doubt it's used, but it's easy enough to find out -- download the SRPM and look in the spec file. or: $ amadmin xx version and you see the build command line. -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... Are you sure? ... YES ... Phew ... I'm out * ***
Re: tar's default block size shoe-shinning
indeed... Thank you for your answers Joshua, I will try a dd with bs=2048k. Then probably I will compile amanda... Bouh I don't like to do that in a production environment Cyrille Joshua Baker-LePain [EMAIL PROTECTED] 19/06/2006 14:43 A Cyrille Bollu [EMAIL PROTECTED] cc amanda-users@amanda.org Objet Re: tar's default block size shoe-shinning On Mon, 19 Jun 2006 at 2:40pm, Cyrille Bollu wrote Does anybody knows about the --with-maxtapeblocksize used by RedHat ES 3.3? I doubt it's used, but it's easy enough to find out -- download the SRPM and look in the spec file. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: tar's default block size shoe-shinning
On Mon, Jun 19, 2006 at 02:59:16PM +0200, Cyrille Bollu enlightened us: indeed... Thank you for your answers Joshua, I will try a dd with bs=2048k. Then probably I will compile amanda... Bouh I don't like to do that in a production environment Understandable. I have some tips at http://www.math.ohiou.edu/~hyclak/casit/amanda/ for using Amanda on RPM based systems. I recommend you rebuild the SRPM anyway, to get rid of necessary but bad default compilation settings. Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263
Re: tar's default block size shoe-shinning
ouch I just ran the test and the speed sank to about 6MB/s... I guess I'm stretching another component... grrr... Cyrille Bollu [EMAIL PROTECTED] Envoyé par : [EMAIL PROTECTED] 19/06/2006 14:59 A Joshua Baker-LePain [EMAIL PROTECTED] cc amanda-users@amanda.org Objet Re: tar's default block size shoe-shinning indeed... Thank you for your answers Joshua, I will try a dd with bs=2048k. Then probably I will compile amanda... Bouh I don't like to do that in a production environment Cyrille Joshua Baker-LePain [EMAIL PROTECTED] 19/06/2006 14:43 A Cyrille Bollu [EMAIL PROTECTED] cc amanda-users@amanda.org Objet Re: tar's default block size shoe-shinning On Mon, 19 Jun 2006 at 2:40pm, Cyrille Bollu wrote Does anybody knows about the --with-maxtapeblocksize used by RedHat ES 3.3? I doubt it's used, but it's easy enough to find out -- download the SRPM and look in the spec file. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: tar's default block size shoe-shinning
Wow...That's better: [EMAIL PROTECTED] cron.d]# time dd if=/dev/zero of=/dev/nst0 bs=2048k count=1024 1024+0 records in 1024+0 records out real 0m27.593s user 0m0.000s sys 0m0.660s speed is 75MB/s! What a poor hardware configuration I have here Cyrille Bollu/FHQ/USERS/FEDASIL 19/06/2006 15:56 A Cyrille Bollu [EMAIL PROTECTED] cc amanda-users@amanda.org, Joshua Baker-LePain [EMAIL PROTECTED], [EMAIL PROTECTED] Objet Re: tar's default block size shoe-shinningLien ouch I just ran the test and the speed sank to about 6MB/s... I guess I'm stretching another component... grrr... Cyrille Bollu [EMAIL PROTECTED] Envoyé par : [EMAIL PROTECTED] 19/06/2006 14:59 A Joshua Baker-LePain [EMAIL PROTECTED] cc amanda-users@amanda.org Objet Re: tar's default block size shoe-shinning indeed... Thank you for your answers Joshua, I will try a dd with bs=2048k. Then probably I will compile amanda... Bouh I don't like to do that in a production environment Cyrille Joshua Baker-LePain [EMAIL PROTECTED] 19/06/2006 14:43 A Cyrille Bollu [EMAIL PROTECTED] cc amanda-users@amanda.org Objet Re: tar's default block size shoe-shinning On Mon, 19 Jun 2006 at 2:40pm, Cyrille Bollu wrote Does anybody knows about the --with-maxtapeblocksize used by RedHat ES 3.3? I doubt it's used, but it's easy enough to find out -- download the SRPM and look in the spec file. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: tar's default block size shoe-shinning
On Mon, 19 Jun 2006 at 3:56pm, Cyrille Bollu wrote ouch I just ran the test and the speed sank to about 6MB/s... I guess I'm stretching another component... What SCSI card do you have the drive hooked to? Is (are) your hard drive(s) on the same card and/or the same chain? You may want to to 'dd if=/dev/zero' to take the HDD out of the equation. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: tar's default block size shoe-shinning
On Mon, 19 Jun 2006 at 3:59pm, Cyrille Bollu wrote Wow...That's better: [EMAIL PROTECTED] cron.d]# time dd if=/dev/zero of=/dev/nst0 bs=2048k ^^^ Great idea! ;) (cf my previous email) count=1024 1024+0 records in 1024+0 records out real0m27.593s user0m0.000s sys 0m0.660s speed is 75MB/s! What a poor hardware configuration I have here Indeed. What *is* your SCSI config. In general, you probably want the tape drive at least on its own channel, if not its own card. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: tar's default block size shoe-shinning
On Mon, 19 Jun 2006 at 10:03am, Jon LaBadie wrote I used stinit to specify block sizes for my new to me LTO-1. Some of the resulting devices at 32K, others at 128., or 256K. Surprise to me, when I ran amtapetype, specifying a matching blocksize, the transfer rate was slower than at 32K. About twenty percent if I recall correctly. Any idea what might be the cause of that? Erm, no, but I usually leave the tape drive in variable blocksize mode (generally via setting the blocksize to 0), and then you can change the blocksize on a per-application basis without needing tons of *st* devices. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: tar's default block size shoe-shinning
On Mon, Jun 19, 2006 at 08:43:04AM -0400, Joshua Baker-LePain wrote: On Mon, 19 Jun 2006 at 2:40pm, Cyrille Bollu wrote Does anybody knows about the --with-maxtapeblocksize used by RedHat ES 3.3? I doubt it's used, but it's easy enough to find out -- download the SRPM and look in the spec file. I think amandad prints out the list of configure options at the start of its debug file. Maybe it is in there. Slightly off-topic but still on blocksize. I used stinit to specify block sizes for my new to me LTO-1. Some of the resulting devices at 32K, others at 128., or 256K. Surprise to me, when I ran amtapetype, specifying a matching blocksize, the transfer rate was slower than at 32K. About twenty percent if I recall correctly. Any idea what might be the cause of that? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: tar's default block size shoe-shinning
What a poor hardware configuration I have here Indeed. What *is* your SCSI config. In general, you probably want the tape drive at least on its own channel, if not its own card. It is BAD! OK at least my tape drive is on its own card. But, when we purchased the backup server I agreed to follow my boss' solution (it's always him you known ;-p) to buy that cheaper server with maximum 1,5TB RAID5 (6*300GB) instead of that nice DAS with up to 3,9TB RAID5. So, to save space I created one big volume containing both the OS and the data. I guess that's the reason why I have so poor performances with dd if=/dev/sda2 ... bs=2048k (where /dev/sda2 is the OS). So, I think I will have to go into a complete hardware configuration change... BTW, in order to finally have a good configuration, I have started another thread about holding disk. But it seems the list cannot keep the pace with me sending so much requests :-). The question was simple (the answer maybe not but...): In a configuration where amanda only backup local (SCSI) drives, are there any benefits from using a holding disk? Best regards, Cyrille
Re: tar's default block size shoe-shinning
On Mon, 19 Jun 2006 at 4:31pm, Cyrille Bollu wrote But, when we purchased the backup server I agreed to follow my boss' solution (it's always him you known ;-p) to buy that cheaper server with maximum 1,5TB RAID5 (6*300GB) instead of that nice DAS with up to 3,9TB RAID5. So, to save space I created one big volume containing both the OS and the data. What type of drives, and what RAID card? What OS/distro are we talking, and what SCSI card for the tape drive? In a configuration where amanda only backup local (SCSI) drives, are there any benefits from using a holding disk? Not that I can think of. And especially with an LTO3 drive, it's really only going to hurt you. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: tar's default block size shoe-shinning
--On June 19, 2006 10:59:58 AM -0400 Joshua Baker-LePain [EMAIL PROTECTED] wrote: On Mon, 19 Jun 2006 at 4:31pm, Cyrille Bollu wrote But, when we purchased the backup server I agreed to follow my boss' solution (it's always him you known ;-p) to buy that cheaper server with maximum 1,5TB RAID5 (6*300GB) instead of that nice DAS with up to 3,9TB RAID5. So, to save space I created one big volume containing both the OS and the data. What type of drives, and what RAID card? What OS/distro are we talking, and what SCSI card for the tape drive? In a configuration where amanda only backup local (SCSI) drives, are there any benefits from using a holding disk? Not that I can think of. And especially with an LTO3 drive, it's really only going to hurt you. Actually with AMANDA it might be a really good idea esp. with the faster drives because there's no way you can keep them streaming over the network. The problem becomes getting a holding area fast enoughRAID0 with 4-8 decently fast SCSI driveslike 9 or 18Gb 10k RPM or 15k RPM split over a couple of channels. AMANDA doesn't interleave onto tape like a lot of the other software does. Several commercial packages interleave blocks from everyone currently backing up while they're writing to tape, whereas AMANDA does not. This causes AMANDA to slow down significantly when you get one slow or slowerish host. This also will cause excessive shoe-shining since the network then gets in the way of the tape streaming too.
Re: tar's default block size shoe-shinning
--On June 19, 2006 12:09:58 PM -0400 Joshua Baker-LePain [EMAIL PROTECTED] wrote: Erm, I think you missed the bit where he said he's only backing up disks local to the backup server (and thus the tape drive). No network involved. You're right, I did, my bad! :D Going back to my hole now :D
