1368074305 Q * FIChTe Read error: Connection reset by peer
1368074318 J * fichte` ~fichte@bashpipe.de
1368076067 Q * marcel__ Ping timeout: 480 seconds
1368076649 J * marcel__ ~marcel@pd95c7474.dip0.t-ipconnect.de
1368076875 M * Bertl off to bed now ... have a good one everyone!
1368076880 N * Bertl Bertl_zZ
1368081826 Q * Kabaka Max SendQ exceeded
1368081922 J * Kabaka ~Kabaka@equine.vacantminded.com
1368082730 Q * Kabaka Max SendQ exceeded
1368082808 J * Kabaka kabaka@equine.vacantminded.com
1368089011 J * Arach ~arach@9KCAACMWM.tor-irc.dnsbl.oftc.net
1368089118 J * bonbons ~bonbons@2001:a18:20a:9d01:8d30:3a3:8171:4388
1368089955 J * BenG_ ~bengreen@host-92-27-135-217.static.as13285.net
1368094039 J * Ghislain ~aqueos@adsl1.aqueos.com
1368094149 Q * BenG_ Ping timeout: 480 seconds
1368094880 J * BenG_ ~bengreen@host-92-27-135-217.static.as13285.net
1368095238 N * l0kit Guest4775
1368095244 J * l0kit ~1oxT@0001b54e.user.oftc.net
1368095650 Q * Guest4775 Ping timeout: 480 seconds
1368096000 Q * BenG_ Quit: I Leave
1368097844 Q * ircuser-1 Ping timeout: 480 seconds
1368099433 Q * PowerKe Quit: leaving
1368102595 Q * Aiken Remote host closed the connection
1368106286 N * Bertl_zZ Bertl
1368106290 M * Bertl morning folks!
1368107956 M * Ghislain hello bertl :)
1368108166 M * karasz Bertl: the last patch for 3.4.x applies to 3.4.44 also
1368108514 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net
1368108562 M * Bertl karasz: tx
1368110610 Q * nlm Remote host closed the connection
1368111317 M * Bertl off for now ... bbl
1368111321 N * Bertl Bertl_oO
1368121149 J * PowerKe ~tom@94-227-30-112.access.telenet.be
1368121154 Q * PowerKe 
1368121286 J * PowerKe ~tom@94-227-30-112.access.telenet.be
1368124758 J * hijacker_ ~hijacker@cable-84-43-134-121.mnet.bg
1368124765 J * csh-harmful ~unknown@pulsar.viking.by.vps.neolocation.net
1368124853 M * csh-harmful Hi! Does anyone avare if there is a mirror of beng debian packages? Main server is realy slow. Or perhaps there is rsync available to sync it ?
1368125108 M * _are_ csh-harmful: I am not aware of a mirror, but if you just want to test some recent debian-vserver kernel, you can use the lihas kernels (3.4-series, currently up to 3.4.40)
1368125188 M * csh-harmful where is the repo ?
1368125223 M * csh-harmful I see http://www.lihas.de/anleitungen-und-service/linux-vserver-kernel-fuer-debian/linux-vserver-kernel-english
1368125237 M * _are_ httdeb     http://ftp.lihas.de/lihas-kernel/ stable main
1368125271 M * _are_ 'htt' is wrong obviously, started typing then continued with c&p
1368125366 M * csh-harmful pretty sad that Debian does not ship vserver kernel anymore
1368125451 M * _are_ well, I am not that sad about it. I like and use Debian, but VServer kernels in Debian had been of poor quality and I am not exactly a friend of debian kernels at all.
1368125549 M * _are_ the 2.6.32-series had performance issues with hardware raid controllers, now they run on 3.2 with serious perfromance improovements done only in later versions if I recall correctly. So in most cases I have to replace the kernel anyway
1368125605 M * csh-harmful Agree about controllers, and that is why I'm trying to avoid 'hardware' raids.
1368125681 M * Bertl_oO yeah, well, the debian Linux-VServer kernels had some quite unfortunate picks (i.e. which kernel what patch, what fix/update) so we are still haunted by debian Linux-VServer kernels today
1368125715 M * Bertl_oO IMHO repos like beng or lately the lihas one are the way to go
1368125744 M * _are_ csh-harmful: well, for quite some time i avoided hardware raid controllers. But nowadays I need their now decent performance as I mix severals VServers + KVM guests. HW-RAID with write cache really helps there.
1368125811 M * Bertl_oO what controllers do you use, if you don't mind me asking?
1368125815 N * Bertl_oO Bertl
1368125832 M * _are_ Bertl: LSI mostly now
1368125850 M * Bertl and how much battery buffered cache do they have?
1368125861 M * _are_ 512-1024MB
1368125876 M * _are_ depending on the model.
1368125909 M * Bertl what throughput do you get to/from the controller?
1368125929 M * _are_ a system with 12 600GB SAS2 15kRPM disks does a DRBD (network raid 1) resync on 10GBit/s network with 1GB/s, that is streaming, obviously
1368125982 M * Bertl so you saturate the 10Gbit network and this is the actual write/read throughput to the controller, yes?
1368125986 M * _are_ with 12 7200RPM, 2TB nearline SAS a similar system syncs DRBD with ~350MB/s, 10GBit-Links as well
1368126003 M * _are_ I saturate the network and never tested any further
1368126018 M * _are_ it is only 10 7200RPM disks
1368126072 M * _are_ however, if I don't actually create new DRBDs, it is mostly database load and the users on the system are qzuite happy with the prformance
1368126105 M * _are_ and database is random access with many small requests
1368126115 M * Bertl well, I'm not convinced that a hardware controller with 1GB cache will outperform a software raid on a recent (32GB machine) with a similar controller just doing BOD
1368126142 M * Bertl but of course, it frees up CPU and allows for redundancy
1368126159 M * Bertl (think multipath, dual controller, etc)
1368126162 M * _are_ well, RAID6 here and it outperformes it in my szenario because of the lower latenzy for writes
1368126278 M * Bertl I think that is because of the way you measure
1368126279 M * _are_ I mostly live on redundant servers, DRBD with protocol C returns a sync write as soon as it is 'written to disk' on the other node. You always add the network latenzy,m but you don't need to wait for the actualy disks to write out the data, controller cache is good enough
1368126317 M * Bertl i.e. on the linux host, you probably measure 'sync' speed, while on the controller you measure write to cache
1368126322 M * _are_ well, I measure what my setups actually do, no generic benchmark
1368126327 M * _are_ yes i do
1368126333 M * Bertl don't forget, on the linux machine, the entire memory is the write cache
1368126364 M * _are_ yes, and if one host of my redundant clusters dies and the data is only in memory and not on the other side I loose data
1368126383 M * Bertl same as with the controller
1368126411 M * Bertl but yeah, I know what you mean and as I said, it sounds like a good solution
1368126416 M * _are_ controller has a BBU, with DRBD and protocol C I am sure the other side really has the data
1368126447 M * Bertl the only thing I'd be worried about is the on-disc format, but for lsi it is mostly known
1368126449 M * _are_ it is write heavy database setups. for other setups they choice of hardware might be completly different
1368126467 M * _are_ well, I don't worry to much, 5 years on-site nextday support
1368126496 M * _are_ and as I have clusters of 2 + working backups I sould be fine
1368126755 M * Bertl what did you pay for the controller and what do you pay for the support? (no problem if that's a secret :)
1368126998 M * _are_ the support is for the whole server and depends on the type of server, let me find a sample
1368127564 M * _are_ 4HE server, up 2 32 3.5" disks (24 front, 12 back), supermicro X9DRi-F, 4GB RAM, 1*E5-2603, 1*500GB disk, LSI MegaRAID 9271-8i + BBU 3.364EUR. Obviously that configuration doesn't suit the controller. controller+BBU accounts for 710EUR of those. 5 year express exchange would add 840, 5 year on-site next business day  1343, they offer Same business day as well as 24x7x4
1368127609 M * _are_ the service stays the same, no matter if you order a bigger CPU or 32 SAS2 disks, this is why I just took the base system
1368127651 M * Bertl okay, thanks for the info
1368127808 M * _are_ 5 year support seems expensive atm, they reevalkuate that one now and then and seems they raised the rate. However, the option is to use 3 years only at about 1/3 and they offer the extension when the 3 years are almost over. I think the last system I sold there had <1000EUR for 5 years onsite support
1368128037 M * _are_ unfortunately we had to test the support now and then, fortunately they kept their promise so far. Most issues are disks, a controller never died on me. and with a 2 clustered raid6, you can loose minimum 5 disks before you risk loss of data, 3 on one side, 2 on the other.
1368128399 Q * hijacker_ Quit: Leaving
1368130168 Q * csh-harmful Quit: leaving
1368130480 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1368131551 J * xy_trolo ~xy_trolo@p4FE11BD6.dip0.t-ipconnect.de
1368131904 Q * xy_trolo Quit: Blub
1368137389 Q * imachine Quit: leaving
1368137455 J * imachine ~imachine@robot.greenhost24.pl
1368137935 J * Ghislain1 ~aqueos@adsl1.aqueos.com
1368137936 Q * Ghislain Read error: Connection reset by peer
1368138386 Q * bonbons Quit: Leaving